Accessibility and Wikis

From Blind Wiki

Jump to: navigation, search

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 shall not become 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.


Contents

[edit] CAPTCHA

Captchas with visual verification are unsolvable problems for some groups of users on the internet. They often prevent the users (which 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:

[edit] Section title and edit link

The edit link should appear after or below the section title heading. This will make navigation on Wiki pages more easier for blind readers. The German Wikipedia and this Blind Wiki already have this improvement. It would be an important part of a desirable Mediawiki skin or gadget for screen reader users. An option for this feature could also be implemented in the preferences. Resources:

[edit] 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.
  • All layout brackets should be removed.
  • 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.


[edit] 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.


[edit] 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.


[edit] 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 assestive 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.


[edit] Resources

[edit] 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.

Retrieved from "http://blind.wikia.com/wiki/Accessibility_and_Wikis"
Personal tools
Content Navigation
.