Last modified: 2014-11-04 22:53:27 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.
(Apologies for stuffing up the dependencies + nomenclature .)
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/
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.)
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.
Does using {{dablink}} with its <div class="dablink"> fix this?
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.
Adding 'tracking' keyword.
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*