Accessibility/sco

MediaWiki accessibeelitie is the goal o makin MediaWiki steids easier tae navegate n read. While this is primarilie intendit tae asseest thae wi disabeelities, it can be heelpfu til aw readers.

Fawk n organisations wairkin oan MediaWiki accessibeelitie

 * "Access fer aw" (Swiss foundation for ICT-Accessibility); ae step-bi-step accessibeelitie analisees accordin til the Wab Accessibeelitie Guidelines (WCAG) 2.0 publeeshed bil the W3C: http://www.thirdageonline.eu/project-tao-2/software-development/mediawiki-accessibility-enhancements/
 * This analisees wis accompleeshed aes ae pairt o the "Third Age Online" (TAO) AAL waurk in collaboration wi Kai Nissen o WMDE
 * Maost o the mentioned issues ar either featur enhancemants or theme sib, while some needs can yinlie be met bi settin up or redefinin the eeditin guidelines.


 * Lucia Greco, aen asseesteeve technologies specialist at UC Berkeley


 * Sami Mubarak fae http://mada.org.qa/en/ - the non-profit Qatar Assistive Technology Center - wairks oon the accessibeelitie o MediaWiki fer the blind (in Arabee)


 * Katie Filbert, o the Wikimedia DC chaipter, is interested in accessibeelitie efforts n heelpt tae rin aen accessibeelitie hackathon: http://www.wikimediadc.org/wiki/Accessibility_hackathon


 * Andrea Zanni is o the Wikimedia Italie chaipter. Wikimedia Italie is investin in saffware deveelopmant tae impruiv Wikisource usabeelitie n accessibeelitie fer new uisers.


 * Adi Kushnir heelpt tae lead aen accessibeelitie session at Wikimania 2011, durin the deveeliper days, taukin ower whit needs fixin.


 * Wikimedia France is interested in wairkin oan Wikimedia accessibeelitie, tae cræft aen audit o the situation the nou n ae roadmap fer futur wairk.


 * Jopparn, wha haunit in aen accessibeelitie waur aes ae Wikimedia fellowship idea.


 * the WikiWaurk Accessibeelitie pairteecipants - oan ither wikis ava?


 * Maria Schiewe, Danny B. n Rodan Bury had aen Accessibeelitie Presentation n Wairkshop at Wikimania 2010.


 * Danny B. n Maria Schiewe stairtit the Accessibeelitie ineetiateeve.


 * Mark Holmquist is aen employee o the WMF wha's uissuallie willin tae heelp wi accessibeelitie issues.


 * Derk-Jan Hartman (thedj), ae saffware deveeliper wairkin oan the Accessibeelitie guide fer deveelipers.


 * Hoo man (Marius Hoch) is wairkin wi the WMDE tae fix a11y bugs in the simmer o 2013.

Feedback fae the DZB, Juin 2010
In Juin 2010, some fawk fae the German Wikimedia chaipter veesitit the German Central Librie fer the Blind (Deutsche Zentralbücherei für Blinde, DZB) in Leipzig. yin ootcome o the veesit wis that the DZB agreed tae luik at Wikipædia's skin (at that point, Vector), n identifie onie accessibeelitie proablems. The first batch o ootcomes wis than posted n taukt ower oan wikitech (gossamer / pipermail). The conversation wis mainlie atween Maria Schiewe n Simetrical. Here's ae quick ootline:

a:focus
CSS uises a:hover bit is missin a:focus; Thus, thaur's nae heilichtin whan naveegatin airtins wi the keybuird. This shid be trivial tae fix - or ar thaur onie proablems wi this?
 * Special:Code/MediaWiki/70015 shid fix this, at least fer Vector.

tab order
The tab order is onconveeneeant. IE8 n FF3.6 shaw first the rakekist, than the shaw/skauk toggles fae the sidebaur, than content, than the tap baur, n yinlie than the actual naveegation eetems fae the sidebaur. This is proablie cause the toggles get inserted bi JS, ah guess. Opera 10 gaes til rakem than the toggles, than back til rake. That's bad.
 * 24581

collapsible menu
Screen readers need some indeecation that the eetem is clapable. Aen onclap event wid heelp, bit the yinlie guid waa is WAI-ARIA.
 * 23428

presentational buirds
Buirdss ar uised fer layoot ae lot. This is maistlie true fer content, especiallie fer Infokists, Naveegation kists, etc. This is quite bad fer screen readers. It's gaun tae be fair haurd thooch tae get wiki eediters tae uise proper css based code fer buird layoots.


 * Whanever ye read fae yin cell til anither, ye uissuallie get information aneatt yer poseetion wiin the buird, the referance til the heider etc. Gif ye hae kists reallie displeyin data in ae tabular waa, that's ok. Bit it's na ok tae hae buirds merelie fer the sake o layoot.
 * Perhaps we coud remuiv attreebutes like cellpaddin, cellspacin, align, etc. fae the attreebute whiteleet. That wid mak it muckle haurder tae uise presentational buirds, it widna hurt non-presentational buird uiss ower muckle, n wid impruiv oor staundairts conformance (HTML5 bans thaim) ava.
 * WAI-ARIA provides ae waa tae say that ae buird is presentational: the presentation role.
 * The oreeginal comment wis actuallie aneat the kist structur oan the main page. this is ae presentational buird. Infokists ar, arguablie, "real" buirds. Thooch aften it's ae real buird wrapt in ae presentational buird, n this is awfa bad.

Perhaps it would be possible to make {|...|} generate a div-based layout using some magic word or option? This would be so easy with a real parser :) But doTableStuff looks fairly sane, so perhaps it could be done.


 * Special:Code/MediaWiki/68230 is ae pruif o concept fer this
 * buird-based displey is fair haurd tae repleecate exactlie in CSS. Fer the ae thing, buird-based displey isna actuallie defined exactlie bi onie staundairt at aw.
 * IE disna recognise displey: buird-*, n wioot that simulatin presentational buirds is ae nichtmare.
 * 24583

"zoom"-links
In eemage thummnail kists, the "zoom" airtin is afore the caption, sae fawk hae tae skip ower it ilka time. Perhaps it coud be muived efter the caption.
 * 24584

alt-attributes
Image thumbnails have an empty alt attribute. This seems like a bug to me - was it always like this? I suggest to use the image's file name in the alt-attribute of the img tag, and also as the title of the link that wraps the thumbnail. After all, the target of that link is indeed the description of the image file. Could we just implement this, or are there any problems I didn't think of?


 * might be a bug, Special:Code/MediaWiki/41837 changed the way alt attributes are handled.
 * We discussed this some weeks ago in the German Wikipedia. The preferred solution would be:
 * If ... is given, use this text for the alt attribute.
 * If no alt text is given, use the text given as the thumb caption.
 * wouldn't that result in the screen reader reading the text twice?
 * If no alt text or thumb caption exists, use the file name (without px data added, without file extension, without _ for blanks).
 * why is this preferred to just not providing an alt attribute?
 * WAI-ARIA: aria-describedby. Drawback: That is currently only valid in HTML 5.
 * If ... is given, use this text for the alt attribute.
 * If no alt text exists, use the "simplified" file name.
 * Add aria-describedby="ImageCaption" to the img tag. (With ImageCaption being the id of the caption.)
 * handling of alt text currently differs depending on whether you use thumb, frameless or pixel w:de:Benutzer:Raymond/alt. Should be consistent.
 * This is for historical reasons. The unnamed parameter is used for a caption if there's a caption, and used for alt text if there's not.
 * This is what HTML5 currently recommends: "As a last resort, implementors should either set the alt attribute to the empty string, under the assumption that the image is a purely decorative image that doesn't add any information but is still specific to the surrounding content, or omit the alt attribute altogether, under the assumption that the image is a key part of the content." and "Markup generators should generally avoid using the image's own file name as the alternative text. Similarly, markup generators should avoid generating alternative text from any content that will be equally available to presentation user agents (e.g. Web browsers)."
 * It would help if we gave people tools to spot bad alt text -- like have a preference that displays alt text in small print under the image, with a clear warning if there's no alt text specified.
 * 24586

Feedback from the DZB, July 2010
As a follow-up to the, we received a second batch of comments. This time, the feedback comes from a blind person actually using a screen reader (JAWS).

history-tab hidden when browser window is small
when the browser window is small (which a blind person would never know), some tabs (like "history") get moved into a drop-down menu, glued to a down-arrow icon. The menu drops down when the mouse is hovered over the icon. This is totally inaccessible to blind people, the icon has no title or any other indication what it does, there is no way to activate the drop-down. There doesn't even seem to be a way to navigate there using the keyboard.
 * 24590, 24298

search suggestions not accessible
the suggestions shown under the search field are not accessible via the screen reader. it's not announced, and it does not get read.
 * 24591

edit buttons not accessible
Alt-Text for edit-buttons are read without spacing between them, they get jammed together. It also does not become clear which elements are buttons, which are links, etc. Blind people would probably not bother with toolbars anyway and use wikitext directly, but they should be able to explore the functionality and find their way around.
 * 24592

Other accessibility-related bugs

 * Bug 11555 - Editsection Links should come after Section Headlines: ideally, the headings could only contain the section title, not the edit link.


 * All bugs tagged with "accessibility" keyword