Page MenuHomePhabricator

Several markup accessibility issues
Closed, ResolvedPublic

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.) See T2369: '' should be interpreted as <i>, not <em>
  2. ''' 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.). See T2370: ''' should be interpreted as <b>, not <strong>
  3. 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.)
  4. 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. See T2368: Image syntax shouldn't use caption as alt= text
  5. 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. See T2371: Image enlargement icon should have alt="", not alt="Enlarge"
  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.


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

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 6:54 PM
bzimport set Reference to bz367.
bzimport added a subscriber: Unknown Object (MLST).

mpt wrote:

(Apologies for stuffing up the dependencies + nomenclature .)

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/

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

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

dunc_harris wrote:

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

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.

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

Points 1 & 2 have been resolved since this task was originally filed.

@bzimport This is some decades old, request converting to a project instead?

@Liuxinyu970226: The bot will not answer you, and why do you propose to convert this into a tag, instead of proposing to archive this task?

We already have a tag for this ( Accessibility ). I would actually recommend this task get closed with new tasks opened for each of the bullets in the original, as appropriate.

Also, ensure all the children are marked with the tag and disconnect the open ones.

Aklapper renamed this task from Markup accessibility issues (tracking) to Several markup accessibility issues.May 13 2019, 12:16 PM
Aklapper removed a project: Tracking-Neverending.

(not a Tracking-Neverending task by definition, just unfortunately several issues listed in one ticket, which should be retested)

Change 555772 had a related patch set uploaded (by Apap04; owner: Apap04):
[mediawiki/core@master] histlegend: use html instead of wikimarkup

https://gerrit.wikimedia.org/r/555772

Aklapper updated the task description. (Show Details)
Aklapper removed subtasks: T25238: Add tabindex to Special:Upload, T45562: Special pages and other forms with initial focus of input nowhere or no tab order/tabindex set (tracking), T69195: Accessibility for keyboard users and screen readers in CPB, T67473: OOjs UI: Dialogs are not accessible, T67474: VisualEditor: Template editor is missing accessibility features, T64923: MultiMediaViewer: Accessibility for keyboard users and screen readers, T56453: Don't override site authors' styles by using inline style in UniversalLanguageSelector, T52047: VisualEditor: Dialog/flyout buttons cannot be activated with Tab key, T40141: Cite back links miss accessibility properties, T48336: Tabbing from LQT editor's summary/textarea fields should not go to the search box in Vector skin, T36754: Collapsible navigation toggle should be a link, T36750: Accessibility for embedded images, T36753: Add label to CAPTCHA input field, 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, T4443: Image alt text should be compulsory, T2658: Table of contents shouldn't be a <table>, T2648: link-text disappears from image alt/title attributes, T2642: Expanded URLs should not be generated at server, T2499: Numeric entity references in alt text, T2542: Link text shouldn't be duplicated in title attributes, T2532: Images used in the user interface should have alt text, T2457: Clean up use of header tags in MonoBook & Vector skin UI elements.Dec 9 2019, 1:28 PM
Volker_E claimed this task.

Resolved as much as this ancient collection is able to be resolved.

Change 555772 abandoned by Apap04:
histlegend: use html instead of wikimarkup

Reason:
new branch, new change

https://gerrit.wikimedia.org/r/555772