Markup accessibility issues (tracking)
OpenPublic

Assigned To
None
Priority
Low
Author
bzimport
Blocks
T4007: Tracking bug (tracking)
Blocked By
T69195: Accessibility for keyboard users and screen readers
T67474: VisualEditor: Template editor is missing accessibility features
T67473: OOjs UI: Dialogs are not accessible
T64923: MultiMediaViewer: Accessibility for keyboard users and screen readers
T56453: Don't override site authors' styles by using inline style in UniversalLanguageSelector
T50717: Issues related to section edit links (tracking)
T52047: VisualEditor: Dialog/flyout buttons cannot be activated with Tab key
T40141: Cite back links miss accessibility properties
T48336: Tabbing from summary/textarea field should not go to the search box (vector)
T36754: Collapsible navigation toggle should be a link
T36753: Add label to CAPTCHA input field
T36750: Accessibility for embedded images
T25428: Headers of collapsible (sub)menus in sidebar not accesible via keyboard
T28519: place styles _inside_ HTML tags
T28415: add <I> to AllPages redirects
T26544: Watchlist tab empty (no alternative text) when loading images is off
T26500: Do not output empty portlets
T16649: Wrap user interface messages in tags with lang & xml:lang if site language != user language
T16597: central-auth ALT message for browsers with images disabled
T28035: make sure 'empty' sections are also empty on text browsers
T13039: issues getting to move protection box with screen reader JAWS in English Wikipedia and form labels
T12467: Use semantic HTML (tracking)
T7051: Accesskeys should not require Javascript
T19101: Wikimedia badge alt text should match image text
T19099: "Discussion" tab should have indication of nonexistent target page (other than color)
T6901: lang and hreflang attributes for interwiki links
T3221: Allow configurable |thumb size.
T13374: Red .diffchange text in the green 'added' area may be hard to read for color-blind users
T3037: Language files have inconsistent mark-up
T2912: Search box hard to reach in text browsers (lynx, links)
T2777: Color Blind people have a hard time comparing differences between revisions
T2648: link-text disappears from image alt/title attributes
T4443: Image alt text should be compulsory
T2658: Table of contents shouldn't be a <table>
T2642: Expanded URLs should not be generated at server
T2542: Link text shouldn't be duplicated in title attributes
T2532: Images used in the user interface should have alt text
T2499: Numeric entity references in alt text
T2457: Clean up use of header tags in MonoBook & Vector skin UI elements
T2368: Image syntax shouldn't use caption as alt= text
T2370: ''' should be interpreted as <b>, not <strong>
T2369: '' should be interpreted as <i>, not <em>
T2371: Image enlargement icon should have alt="", not alt="Enlarge"
Subscribers
Danny_B, Volker_E, jayvdb and 4 others
Projects
Reference
bz367
Description

Author: mpt

Description:
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.)
  1. 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.)
  1. 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.
  1. 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.
  1. ''' 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.)
  1. 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.


Version: unspecified
Severity: normal
URL: http://en.wikipedia.org/w/wiki.phtml?title=Hamburg&oldid=5364113

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz367.
bzimport created this task.Via LegacySep 3 2004, 1:15 PM
bzimport added a comment.Via ConduitSep 3 2004, 1:56 PM

mpt wrote:

(Apologies for stuffing up the dependencies + nomenclature .)

bzimport added a comment.Via ConduitSep 6 2004, 7:21 PM

michael wrote:

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/

bzimport added a comment.Via ConduitSep 7 2004, 8:42 AM

mpt wrote:

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.)

bzimport added a comment.Via ConduitOct 7 2004, 8:32 PM

tom wrote:

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.

attachment TOC.patch ignored as obsolete

bzimport added a comment.Via ConduitOct 14 2006, 3:46 PM

dunc_harris wrote:

Does using {{dablink}} with its <div class="dablink"> fix this?

bzimport added a comment.Via ConduitJan 22 2007, 10:23 PM

jfoliot wrote:

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.

werdna added a comment.Via ConduitJul 29 2009, 4:38 PM

Adding 'tracking' keyword.

Peachey88 added a comment.Via ConduitApr 30 2011, 12:09 AM

*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*

Volker_E added a subscriber: Volker_E.Via WebMay 17 2015, 10:37 PM

Add Comment