Blind Wiki
Register

This page will try to explain how the accessibility & usability of Mediawiki based Wikis could be improved for screen reader users. These Wikis are excellent platforms for information and collaboration and fortunately they are almost accessible for blind users. On this page you will find information about remaining problems. You can discuss them on the Talk page. Don't worry, the following topics are just suggestions. Blindness and Accessibility should not be negative buzz words for Mediawiki developers. You can learn more about the suggested development project for a MediaWiki/Wikipedia screen reader skin at the about page.

CAPTCHA[]

Captchas with visual verification are unsolvable problems for some groups of users on the internet. They often prevent the users (who also can be customers) from using online services or contact/comment forms. The Carnegie Mellon University provides a MediaWiki extension for reCAPTCHA, which also includes an alternative audio CAPTCHA. Unfortunately, this solution can't be used for Wikipedia/MediaWiki at the moment. Why? Please see this post on the Wikitech-l mailing list for example. Brion, the chief MediaWiki developer: "The only thing stopping us from having an audio captcha is that nobody's put the work into implementing it yet." [1]

It would be great if the reCAPTCHA developers or someone else could provide an additional extension just for an audio solution. This would make many blind and visually impaired users around the world very happy and could make them more independent of seeing help.

Resources:

Section title and edit link[]

The section edit links should be right next to the section title headings. This will make navigation on Wiki pages much easier for blind readers. The German Wikipedia, this Blind Wiki and a few Wikimedia projects already have this improvement. In 2006 this problem was firstly mentioned at the Mediawiki developers mailing list and since 2007 this problem is known as Bug 11555. If this bug cannot be fixed, the only chance would be this proposal for a gadget. Unfortunately, this would just be the second best solution because most blind users are only readers of Wikipedia articles. They have no account and thereby no chance to activate such a gadget in the preferences. The CAPTCHA problem prevent them from just creating an account. Another question in June 2008 about Bug 11555 at Wikitech-l was also not successfully. Please read the thread.

As it seems, this usability problem for blind readers on Mediawiki pages such as articles at the English language Wikipedia is solvable.

For screen reader users it takes quite long to walk through the headlines. At every single headline we hear "left bracket edit right bracket link" first instead of the real section title. The problem could be solved by making the edit-section-link come second in the rendered page and making the section title come first. This means moving the section edit links right next to the headings as they are here or in the German or French language Wikipedia. It makes it much easier to navigate by headings for screen reader users, as the link "[Edit]" is spoken after the section name instead of before it. Some sighted users must like it as well because a few Mediawiki projects already use it.

If you have an account on the English language Wikipedia, you can use a piece of java script for solving this navigation problem. Unfortunately, this is not possible for blind Wikipedia readers without a Wikipedia account. This is the reason why bug 11555 will hopefully be fixed soon.

Special pages[]

The following points are desirable improvements for a special skin or gadget for screen reader users. As it seems, some problems are not solvable.

  • All layout brackets should be removed from special pages.
  • Special pages need headings to improve navigation for screen reader users which can easily "jump" from heading to heading.
  • on the search page the line "Search in namespaces" should have a heading format. Wikia's search page provides the lines Article title matches, Page text matches, No page title matches and No page text matches with a heading format (h2). This is very helpful for efficient navigation.
  • On pages such as Recent changes, History, User contributions or the personal Watch list the order of elements should be changed and one heading for every entry should be added for faster navigation and thereby for a huge increase in usability. The order of elements depends on several thoughts which will be explained later.
  • The Tab Index is another small problem. Tabbing index defines the order in which elements will receive focus when navigated by the user via the keyboard. Normally a tab key press will bring you to the next element but on special pages such as recent changes or watch list this don't work because the diff links are prioritized. At the moment, users can solve this problem by navigating with the cursor keys. You can learn more about Tab index at the WAC Blog.
  • A solution for the diff page has low priority because it seems to be the hardest problem and it's not good to waste development resources for that at the beginning.
  • Read more about an optimized watch list in German language.

Jump_to links[]

Enable "jump to" accessibility links (preferences/misc) can be deactivated by default. For screen reader users this feature is fortunately no longer necessary. These two hidden navigation links (which produce 3 unnecessary lines with a screen reader software) could also be deactivated by default for the whole MediaWiki software. If a single user really need this feature, it can be individually activated in the preferences.

Comment: This is false. First, the whole point is to use HTML5 nav element instead. Second, it's not supported by most assistive technologies yet. And when the latest versions will support it, we will have to wait a few years: since assistive technologies are very expensive, their users don't update very often. Third, HTML5 is not yet a standard.

An appropriate reference about skip links would be: "Skip Navigation" Links, WebAIM, and Future Web Accessibility: HTML5 Semantic Elements in section "The <nav> Element". Note that webaim.org contains detailed and easy to understand resources about accessibility.

Access keys[]

Access keys are helpful features for quick navigation but they don't work dependably. This is not really a problem because if one combination doesn't work at the moment, another access key will mostly bring you near to the place you want to reach. This is more a screen reader related problem than one of Mediawiki and should have low priority.

Comment: Keyboard shortcuts (access keys) are a complicated matter. This feature, in it's current implementations was temporarily abandoned in WCAG 2.0. Notably because it conflicts with the shortcuts of assistive technologies. Usage of access keys is currently discouraged in the online contents and applications.

But presence of access keys are also an Authoring Tool Accessibility Guidelines (ATAG) requirement - the ATAG approach is particularly relevant in Wikipedia's case - where this matter is looked into thoroughly. In particular, ATAG requires the possibility to customize shortcuts. This should be requested in MediaWiki's bug "bugzilla:477".

Currently, their presence in Wikipedia's interface can be problematic for some users and can be useful for others. But more importantly, it misleads developers into thinking that the interface is keyboard accessible. Requirements that needs to be fulfilled in order to be keyboard accessible are not related to keyboard shortcuts (G90, F42, SCR35, F58, F61).

Screen reader problems[]

While editing contents using a screen reader software such as Jaws, there is a problem. The screen reader speech output mixes parts of the content from outside the input box into the text. This problem increases if there is a Google ads frame. Perhaps this issue is solved in newest screen reader versions but many blind persons can't afford updates because of the expensive prices of these assistive products and so they have to work with older versions.

Information about the capabilities of different screen reader applications and versions regarding CSS and JS is needed. Screen reader vendors should have an interest to provide information and to collaborate because many of their global customers are using Wikipedia and other Wikis for their jobs, e-learning and e-participation/e-inclusion.

Resources[]

Potential human resources[]

The following persons and projects could perhaps provide knowledge and contacts:

You want more information? Please contact Per or use the talk/discuss page of this article.