Wikipedia:WikiProject Accessibility/MediaWiki accessibility specification

Note: it's way too early to thoroughly write a MediaWiki accessibility specification, but it's planned. We should pay for an accessibility audit (WCAG 2.0 and ATAG 2.0) by professionals first. Afterward we will have enough information to act.

In the meantime, we can prepare a few specifications here. Once they are reviewed and good enough to be submitted to the MediaWiki developers, we could try to reach MediaWiki developers and get bugs fixed. Here are a few ideas for our first bugs.

Specification for the Vector skin

Skip links

Status: Under construction.

Bug located at:

http://bits.wikimedia.org/skins-1.5/vector/main-ltr.css?283y

line 961

#jump-to-nav {
	display: none;
}

Proposed behaviour:

#jump-to-nav {
position: absolute;
left: 0;
top: -5000px;
width: 1px;
height: 1px;
overflow: hidden;
}

/**
 * Direct access link for keyboard navigation
 */
function showSkipLinks() {
  var jump_to_nav = document.getElementById('jump-to-nav');
  if( !jump_to_nav ) return;
  var skip_links = jump_to_nav.getElementsByTagName('A')[0];
  jump_to_nav.className='hidden';
  skip_links.onfocus=function() {
    jump_to_nav.className='';
  }
}
addOnloadHook(showSkipLinks);

Resources and expected behaviour:

Skip Navigation Links, Links that become visible with keyboard focus, WebAIM
CSS in Action: Invisible Content Just for Screen Reader Users, WebAIM

WebAIM's fix


#jump-to-nav a, #jump-to-nav a:hover, #jump-to-nav a:visited
{
position:absolute;
left:-10000px;
top:auto;
width:1px;
height:1px;
overflow:hidden;
}

#jump-to-nav a:active, #jump-to-nav a:focus
{
position:static;
width:auto;
height:auto;
}

Fix at fr.wikipedia

#jump-to-nav {
display: block;
text-align: right;
}

.hidden {
position: absolute;
left: 0;
top: -5000px;
width: 1px;
height: 1px;
overflow: hidden;
}

/**
 * Direct access link for keyboard navigation
 */
function showSkipLinks() {
  var jump_to_nav = document.getElementById('jump-to-nav');
  if( !jump_to_nav ) return;
  var skip_links = jump_to_nav.getElementsByTagName('A')[0];
  jump_to_nav.className='hidden';
  skip_links.onfocus=function() {
    jump_to_nav.className='';
  }
}
addOnloadHook(showSkipLinks);

Specification for the interface in general

CAPTCHA

Status: Under construction, but already fairly complete.

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." wikitech-l/2008-April

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:

CAPTCHA
Blind Access Journal, entries with tag CAPTCHA
reCAPTCHA extension for Mediawiki, info on MediaWiki.org
Online petition at Mobile Space Blog, an attempt of self-help, addressed to Nokia/Symbian

Section title and edit link

Status: Under construction, but already fairly complete.

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 bugzilla:11555 and bugzilla:11270. 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 throught 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 let the edit-section-link come second in the rendered page and let the section title come first. This means to move 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.

Access keys

Status: Under construction, but already fairly complete.

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

Special pages

Status: Under construction. This is raw feedback from a screen reader user, and should be used with caution.

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.

Specification for specific kinds of contents

Issues with sortable tables

Status: Under construction, but already fairly complete.

Sortable tables should not be avoided because they are very useful. Trying to remove them would only lead to endless and unnecessary debates.

Templates like {{Smn}} and {{Sort}} generate hidden data in the table. That data contains sort keys hidden in every cell instead of standard metadata.^{[WCAG-TECH 1]} It makes the cell's content unintelligible for users with CSS styles disabled or unavailable. See also this issue report.

Example of sortable table using {{Smn}} template
Result shown with CSS enabled	Real content of the table cell shown when CSS are disabled or not supported
Template:Smn 47.15 €	sm=n-47.15 €

Source

Most of this information was taken from Mediawiki and Accessibility at blind.wikia.com, a website made by a screen reader user.
Cite error: There are <ref group=WCAG-TECH> tags on this page, but the references will not show without a {{reflist|group=WCAG-TECH}} template (see the help page).

[WCAG-TECH 1]