Accessibility/fr

MediaWiki accessibility is the goal of making MediaWiki sites easier to navigate and read. While this is primarily intended to assist those with disabilities, it can be helpful to all readers.

People and organizations working on MediaWiki accessibility

 * "Access for all" (Swiss foundation for ICT-Accessibility); a step-by-step accessibility analysis according to the Web Accessibility Guidelines (WCAG) 2.0 published by the W3C: http://www.thirdageonline.eu/project-tao-2/software-development/mediawiki-accessibility-enhancements/
 * This analysis was accomplished as part of the "Third Age Online" (TAO) AAL project in collaboration with Kai Nissen of WMDE
 * Most of the mentioned issues are either feature enhancements or theme related, while some requirements can only be met by setting up or redefining the editing guidelines.


 * Lucia Greco, an assistive technologies specialist at UC Berkeley


 * Sami Mubarak from http://mada.org.qa/en/ - the non-profit Qatar Assistive Technology Center - works on the accessibility of MediaWiki for the blind (in Arabic)


 * Katie Filbert, of the Wikimedia DC chapter, is interested in accessibility efforts and helped run an accessibility hackathon: http://www.wikimediadc.org/wiki/Accessibility_hackathon


 * Andrea Zanni is of the Wikimedia Italy chapter. Wikimedia Italy is investing in software development to improve Wikisource usability and accessibility for new users.


 * Adi Kushnir helped lead an accessibility session at Wikimania 2011, during the developer days, discussing what needs fixing.


 * Wikimedia France is interested in working on Wikimedia accessibility, to create an audit of the current situation and a roadmap for future work.


 * Jopparn, who submitted an accessibility project as a Wikimedia fellowship idea.


 * the WikiProject Accessibility participants - on other wikis as well?


 * Maria Schiewe, Danny B. and Rodan Bury had Accessibility Presentation and Workshop at Wikimania 2010.


 * Danny B. and Maria Schiewe started Accessibility initiative.


 * Mark Holmquist is an employee of the WMF who is usually willing to help with accessibility issues.


 * Derk-Jan Hartman (thedj), a software developer working on Accessibility guide for developers.


 * Hoo man (Marius Hoch) is working with WMDE to fix a11y bugs in the summer of 2013.

Feedback from the DZB, June 2010
In June 2010, some people from the German Wikimedia chapter visited the German Central Library for the Blind (Deutsche Zentralbücherei für Blinde, DZB) in Leipzig. One result of the visit was that the DZB agreed to look at Wikipedia's skin (at that point, Vector), and identify any accessibility problems. The first batch of results was then posted and discussed on wikitech (gossamer / pipermail). The conversation was mainly between Maria Schiewe and Simetrical. Here's a quick summary:

a:focus
CSS uses a:hover but is missing a:focus; Thus, there's no highlighting when navigating links with the keyboard. This should be trivial to fix - or are there any problems with this?
 * Special:Code/MediaWiki/70015 should fix this, at least for Vector.

tab order
The tab order is inconvenient. IE8 und FF3.6 show first the search box, then the show/hide toggles from the sidebar, then content, then the top bar, and only then the actual navigation items from the sidebar. This is probably because the toggles get inserted by JS, i guess. Opera 10 goes to searchm then the toggles, then back to search. That's bad.
 * 24581

collapsible menu
Screen readers need some indication that the item is clickable. An onclick event would help, but the only good way is WAI-ARIA.
 * 23428

presentational tables
Tables are used for layout a lot. This is mostly true for content, especially for Infoboxes, Navigation boxes, etc. This is quite bad for screen readers. It's going to be very hard though to get wiki editors to use proper css based code for table layouts.


 * Whenever you read from one cell to another, you usually get information about your position within the table, the reference to the header etc. If you have boxes really displaying data in a tabular way, that's fine. But it's not fine to have tables merely for the sake of layout.
 * Maybe we could remove attributes like cellpadding, cellspacing, align, etc. from the attribute whitelist. That would make it much harder to use presentational tables, wouldn't hurt non-presentational table use much, and would also improve our standards conformance (HTML5 bans them).
 * WAI-ARIA provides a way to say that a table is presentational: the presentation role.
 * The original comment was actually about the box structure on the main page. Which is a presentational table. Infoboxes are, arguabley, "real" tables. Though often it's a real table wrapped in a presentational table, which is pretty 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 a proof of concept for this
 * table-based display is very hard to replicate exactly in CSS. For one thing, table-based display is actually not defined exactly by any standard at all.
 * IE doesn't recognize display: table-*, and without that simulating presentational tables is a nightmare.
 * 24583


 * Special:Code/MediaWiki/68230 is a proof of concept for this
 * table-based display is very hard to replicate exactly in CSS. For one thing, table-based display is actually not defined exactly by any standard at all.
 * IE doesn't recognize display: table-*, and without that simulating presentational tables is a nightmare.
 * 24583


 * Special:Code/MediaWiki/68230 is a proof of concept for this
 * table-based display is very hard to replicate exactly in CSS. For one thing, table-based display is actually not defined exactly by any standard at all.
 * IE doesn't recognize display: table-*, and without that simulating presentational tables is a nightmare.
 * 24583

alt-attributes

 * Special:Code/MediaWiki/68230 is a proof of concept for this
 * table-based display is very hard to replicate exactly in CSS. For one thing, table-based display is actually not defined exactly by any standard at all.
 * IE doesn't recognize display: table-*, and without that simulating presentational tables is a nightmare.
 * 24583


 * Special:Code/MediaWiki/68230 is a proof of concept for this
 * table-based display is very hard to replicate exactly in CSS. For one thing, table-based display is actually not defined exactly by any standard at all.
 * IE doesn't recognize display: table-*, and without that simulating presentational tables is a nightmare.
 * 24583https://www.mediawiki.org/w/index.php?title=Special:Translate&group=page-Accessibility&action=page&filter=&language=fr

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


 * Special:Code/MediaWiki/68230 is a proof of concept for this
 * table-based display is very hard to replicate exactly in CSS. For one thing, table-based display is actually not defined exactly by any standard at all.
 * IE doesn't recognize display: table-*, and without that simulating presentational tables is a nightmare.
 * 24583

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.

akak20001

Voir aussi

 * w:Wikipedia:Manual of Style/Accessibility
 * w:Wikipedia:WikiProject Accessibility
 * Accessibility
 * Accessibility