Last modified: 2014-11-04 22:53:27 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T2367, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 367 - Markup accessibility issues (tracking)
Markup accessibility issues (tracking)
Status: NEW
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
unspecified
All All
: Low normal with 11 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/w/wiki.phtml?...
: accessibility, tracking
Depends on: 4901 semantic-html 17099 24544 34750 46336 editlinks 62923 67195 368 369 370 371 457 499 532 542 642 648 658 777 912 1037 1221 2443 5051 11039 11374 14597 14649 17101 23428 24500 26035 26415 26519 34753 34754 38141 50047 54453 65473 65474
Blocks: tracking
  Show dependency treegraph
 
Reported: 2004-09-03 13:15 UTC by Matthew "mpt" Thomas
Modified: 2014-11-04 22:53 UTC (History)
11 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
ignore, wrong bug (10.88 KB, patch)
2004-10-07 20:32 UTC, Tom Gilder
Details

Description Matthew "mpt" Thomas 2004-09-03 13:15:51 UTC
Steps to reproduce:
1.  Get a screenreader to read you Wikipedia's [[Hamburg]].
    (For reference, this bug uses <http://en.wikipedia.org/
w/wiki.phtml?title=Hamburg&oldid=5364113>.)

What you should hear:
    "HAMBURG. (From Wikipedia, the free encyclopedia.) (For
    other uses, see Hamburg (disambiguation).) Hamburg is
    Germany's second largest city (after Berlin) and its
    principal port. The official name 'Freie und Hansestadt
    Hamburg' recalls its membership in the mediaeval
    Hanseatic League and the fact that Hamburg is a city
    state and one of Germany's sixteen 'Bundesländer' ..."

What you actually hear:
    "HAMBURG. (From Wikipedia, the free encyclopedia.)
    *For* *other* *uses*, *see* *Hamburg*
    *(disambiguation)*. Map of Germany showing Hamburg Map
    of Germany showing Hamburg Hamburg coat of arms Hamburg
    coat of arms Enlarge HAMBURG [apostrophe-hamb-omega-rk]
    is Germany's second largest city (after Berlin) and its
    principal port. The official name *Freie* *und*
    *Hansestadt* *Hamburg* recalls its membership in the
    mediaeval Hanseatic League and the fact that Hamburg is
    a city state and one of Germany's sixteen
    *Bundesländer* ..."

Ugh. What's causing this? In order of appearance (not 
necessarily order of importance):

1.  '' is being interpreted as <em>. But Wikimedia projects
    aren't like most other Web sites; most of our uses of
    italics are for citations of works <cite>, phrases in
    other languages <i lang="de">, taxonomical names <i
    class="taxonomy">, or mathematical variables <var>.
    Very, very few are for emphasized text. Since Wikimedia
    project contributors are unlikely to care about the
    distinction between <em>/<cite>/<var>/<dfn>/etc,
    articles would sound more sensible if '' was
    interpreted as the neutral <i>. (Possibly new syntax
    for emphasis, citations, and variables could be created
    for those thoughtful enough to use it.)

2.  The caption for an image is rendered regardless of
    whether I can see the image. When I can't see images,
    captions lose their context and sound like gibberish.
    Ideally, Wikimedia should auto-generate an image that
    contains both the original image and the caption; that
    way if the image isn't present, the caption won't be
    either. (It may seem counter-intuitive to *hide* text
    for accessibility reasons, but that would produce the
    most sensible-sounding end result.)

3.  In the image syntax, the caption text is doing double
    duty as the image's alternate text. So the
    out-of-context gibberish gets read not once, but twice.

4.  The auto-generated enlargement icon has alt="Enlarge".
    This is needlessly aggravating; if I can't view images,
    a link to a larger version of an image is completely
    useless. So the icon should have alt="", to hide the
    link completely in text-only situations.

5.  ''' is being interpreted as <strong>. But Wikimedia
    projects aren't like most other Web sites; most of our
    uses of bold are for defining instances <dfn>. Very,
    very few are for strong emphasis. Since Wikimedia
    project contributors are unlikely to care about the
    distinction between <dfn>/<strong>/<b class="vector">,
    articles would sound more sensible if ''' was
    interpreted as the neutral <b>. (Possibly new syntax
    for defining instances, strong emphasis and vector
    spaces could be created for those thoughtful enough to
    use it. To increase the number of people using <dfn>
    correctly, the default style sheet could style
    <h1>-<h6> and <dfn> with the same non-black color.)

6.  Pronunciations are ordinary text, instead of being
    hidden from aural user agents. (A screenreader should
    just be pronouncing the term correctly in the first
    place, not pronouncing it incorrectly and then bumbling
    its way through clumps of IPA symbols!) This isn't as
    solvable as the other problems, but a good start would
    be to create markup specially for pronunciations.
    Wikimedia could interpret this markup as <span
    class="pronunciation">, with Wikimedia's default style
    sheets containing "@media aural {.pronunciation
    {display: none}}". (To remind people to use this
    markup, the default style sheets could perhaps also
    include {.pronuncation {background-color: inherit;
    color: brown}} or similar.)

Wikimedia's accessibility is *much* better than that of 
many other Web sites, because articles use logical 
headings, and navigation links are left to the end of the 
page. But these syntax problems really let it down. I know 
they comprise more than one bug, but I'm filing this 
firstly to serve as a tracker bug, and secondly to show the 
cumulative effect of poor markup in a single article.
Comment 1 Matthew "mpt" Thomas 2004-09-03 13:56:21 UTC
(Apologies for stuffing up the dependencies + nomenclature .)
Comment 2 Michael Zajac 2004-09-06 19:21:21 UTC
Wiki-text requires some careful review and revision.  

For inspiration, there are some pretty sophisticated text markup systems out there:

Textile (PHP): http://www.textism.com/tools/textile/
Textile (Perl): http://bradchoate.com/mt-plugins/textile
Smartypants (Perl): http://daringfireball.net/projects/smartypants/
Markdown (Perl): http://daringfireball.net/projects/markdown/
Comment 3 Matthew "mpt" Thomas 2004-09-07 08:42:14 UTC
I was going to file that as a separate RFE, since it 
doesn't seem to be related to accessibility. (Well, except 
for screenreaders saying "dash dash" instead of pausing 
for a genuine em dash.)
Comment 4 Tom Gilder 2004-10-07 20:32:34 UTC
Created attachment 75 [details]
ignore, wrong bug

This needs review to check it doesn't break anything.

Makes the TOC output with decent HTML, with a proper list and no tables. Also
allows skins to style the heading number and heading text differently. CSS is a
little weird, but I think I've covered all the skins I need to.
Comment 5 Duncan Harris 2006-10-14 15:46:28 UTC
Does using {{dablink}} with its <div class="dablink"> fix this?
Comment 6 John Foliot 2007-01-22 22:23:59 UTC
Re: #6. "Pronunciations are ordinary text."
While the suggestion to use aural style sheets (@media aural) to address this
issue would be wonderful, there are currently no mainstream user-agents
(browsers and/or screen readers) that use aural style sheets, so adding this
would be great, but of little practical use.
Comment 7 Andrew Garrett 2009-07-29 16:38:45 UTC
Adding 'tracking' keyword.
Comment 8 p858snake 2011-04-30 00:09:46 UTC
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links