Wikipedia:WikiProject Accessibility/MediaWiki accessibility specification#Keyboard Navigation

Ensure that every interaction can be used by both the keyboard and the mouse. This is especially relevant for JavaScript and AJAX events. To test keyboard navigation, use the TAB key to access the interaction, and ENTER to use it. Depending on the nature of the interaction, keyboard arrows might be used too (move up and down in a SELECT element).

If HTML elements meant to be used for interaction are used according to their W3C specification, it should work naturally. For example, if a clickable drop-down menu is made with a link (A element) or Button element it will be keyboard accessible. Because buttons and links are made to be interactive elements according to specification. Problems arise when elements not meant for interactive content (such as a DIV element) are used for interaction (trough javascript for example).

Other issues might arise through the use of mouse event handlers. Mouse event handlers should be accompanied by redundant keyboard event handlers. Only "Onclick" is universal.

TABINDEX should be used with caution as it is difficult to use correctly and is annoying to update. The tabulation order should be natural, following the order in the HTML. TABINDEX="0" make the element keyboard focusable, and add it in the tabbing list in the natural order. The search box might be an exception where we want a TABINDEX set to "1". Reference : [http://webaim.org/techniques/keyboard/tabindex Keyboard Accessibility - Tabindex], WebAIM.

• [http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G90 G90]: Providing keyboard-triggered event handlers
• [http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/SCR2.html SCR2]: Using redundant keyboard and mouse event handlers
• [http://www.w3.org/TR/WCAG-TECHS/SCR35.html SCR35]: Making actions keyboard accessible by using the onclick event of anchors and buttons
• [http://www.w3.org/TR/WCAG-TECHS/SCR20.html SCR20]: Using both keyboard and other device-specific functions

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 [http://recaptcha.net/plugins/mediawiki/ 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 [https://lists.wikimedia.org/pipermail/wikitech-l/2008-April/037317.html 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." [https://lists.wikimedia.org/pipermail/wikitech-l/2008-April/037327.html wikitech-l/2008-April]

Since then, discussions were focused on the potentially lower level of security that audio captcha can provide. This is a valid and important concern, but it's not likely to be solved anytime soon. There is a choice to make.

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
• [http://blog.blindaccessjournal.com/search/label/CAPTCHA Blind Access Journal], entries with tag CAPTCHA
• [http://www.mediawiki.org/wiki/Extension:ReCAPTCHA reCAPTCHA extension for Mediawiki], info on MediaWiki.org
• [http://mobilespace.wordpress.com/2008/03/05/open-signed-online-not-accessible-to-the-visually-impaired/ Online petition at Mobile Space Blog], an attempt of self-help, addressed to Nokia/Symbian

Status: Under construction. May be outdated.

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 [http://lists.wikimedia.org/pipermail/wikitech-l/2006-October/027130.html 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 [http://en.wikipedia.org/wiki/Wikipedia:Gadget/proposals/Archive_1#Gadget_to_move_the_section_edit_links_right_next_to_the_headings 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 [http://lists.wikimedia.org/pipermail/wikitech-l/2008-June/038417.html 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 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.

Status: Under construction, but already fairly complete.

Keyboard shortcuts (access keys) are a complicated matter. This feature, in its 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 ([http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G90 G90], [http://www.w3.org/TR/WCAG-TECHS/F42.html F42], [http://www.w3.org/TR/WCAG-TECHS/SCR35.html SCR35], [http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F58 F58], [http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F61 F61]).

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

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 [http://www.rnib.org.uk/wacblog/articles/too-much-accessibility/too-much-accessibility-tabindex/ 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 [http://de.wikipedia.org/wiki/Wikipedia:BIENE/Screenreader/Beobachtungsliste optimized watch list in German language].

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_hidden {
position: absolute;
left: 0;
top: -5000px;
width: 1px;
height: 1px;
overflow: hidden;
}
/**
* Direct access link for keyboard navigation
*/
addOnloadHook(OptimizedNavigAdmin);
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='jump_to_nav_hidden';
skip_links.onfocus=function() {
jump_to_nav.className='';
}
}
addOnloadHook(showSkipLinks);

Resources and expected behaviour:

• [http://webaim.org/techniques/skipnav/#focus Skip Navigation Links], Links that become visible with keyboard focus, WebAIM
• [http://webaim.org/techniques/css/invisiblecontent/ CSS in Action: Invisible Content Just for Screen Reader Users], WebAIM

{{hidden

| style = border:1px solid black; width: 50%;

| headerstyle = background: #ccccff; font-size: 110%;

| 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;
}

}}

{{hidden

| style = border:1px solid black; width: 50%;

| headerstyle = background: #ccccff; font-size: 110%;

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

}}

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 {{t|Sortname}}, {{t|Number table sorting}} and {{t|Sort}} generate hidden data in the table. That data contains sort keys hidden in every cell instead of standard metadata.[http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G115 {{lang|en|G115: Using semantic elements to mark up structure}}], A accessibility level. It makes the cell's content unintelligible for users with CSS styles disabled or unavailable. See also [http://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style_(accessibility)&oldid=379786633#Hidden_rows_in_tables this issue report].

Instead, these table cells should use the 'data-sort-value' attribute, to specify a sortvalue.

Most of this information was taken from [http://blind.wikia.com/wiki/Mediawiki_and_Accessibility Mediawiki and Accessibility] at blind.wikia.com, a website made by a screen reader user.

{{Reflist}}

MediaWiki accessibility specification