Groups/Proposals/Accessibility Tracking

The «Accessibility Tracking» group welcomes everyone to support Wikimedia in bringing forward its accessibility. Members are advised to convince decision-makers/programmers in Wikimedia (the core MediaWiki software as well as the different chapters) to solve known accessibility issues and to promote considering accessibilty when writing articles in the community.

The «Accessibility Tracking» group page will provide the necessary prerequisites to successfully organize and coordinate appropriate actions.

Areas of collaboration

Do awareness raising campaigns concerning accessibility in MediaWiki/Wikipedia
Fixing accessibility problems in the MediaWiki software
Fixing accessibility problems based on settings of the various language versions
Providing tools and instructions on how to write accessible content in Wikipedia

In order to achieve its goals the group must convince active representatives of the MediaWiki/Wikipedia authors and programmers communities.

We are requesting official recognition from the Affiliations Committee for a first period of one year, after which we would become a permanent group.

News

2013-07-17: Launch of the Access-for-all Content Accessibility Checker Software on GitHub. You are invited to contribute!
2013-04-25: Set up of the current proposal
2013-05-15: Proposal announced to wikitech-l.
2013-05-29: Group announced to the Affiliations Commitee

Communication

The official channel of communication of this group is its Discussion page.

Materials provided

Extensive Accessibility Tests on the German Wikipedia (PDF, 1.8MB)
TO-DO list summarizing the MediaWiki accessibility issues (see below)
NEW: Content Accessibility Checker for MediaWiki authors on GitHub. In german. The software is freely available and adaptable under the Creative Commons Licence: Access4all 3.0 Schweiz (CC BY 3.0 CH). We like to encourage everybody to contribute. As for example to translate the installation instructions in English? Thank you!
Accessibility Checklist for authors and publishers (PDF, 414KB)

Related links welcome!

Contributors

MediaWiki groups need at least 3 people to be approved.

Promoters

Barrierefrei (talk) 11:42, 25 April 2013 (UTC)[reply]
I've been involved in web design for more than 16 years and am currently an active campaigner for accessibility on the English Wikipedia. RexxS (talk) 17:46, 16 May 2013 (UTC)[reply]
I have worked on Wikipedia accessibility for 3 years, on French and English wiki (with RexxS notably). I dropped this activity some time ago in favor of real life. But I'm willing to give a hand. If this initiative gets enough momentum and goes forward, I'll make a full comeback. Dodoïste (talk) 09:27, 28 May 2013 (UTC)[reply]
I have been interested in these issues for some time now and as a staff member at WMSE I have tried to add a few Chapter projects that would help make Swedish Wikipedia more accessible. For example one focusing on getting Meaningful alternative texts. In the project the office would help coordinate volunteer efforts and invite new groups. Hopefully we will be able to get funding for this work already next year. As of now we don't have any funding so any involvement will be on my spare time. Hence, I am using my private user account. Cheers, John/Jopparn (talk) 11:39, 3 November 2013 (UTC)[reply]
(((Introduce yourself briefly and sign by using "~~~~".)))
More promoters welcome! (((One is enough, but all the better if you have 2-3.)))

Members

Barrierefrei (talk) 11:42, 25 April 2013 (UTC)[reply]
RexxS (talk) 17:46, 16 May 2013 (UTC)[reply]
Dodoïste (talk) 09:27, 28 May 2013 (UTC)[reply]
I have been working on some issues a while ago. Not much time lately, but I'm still in. :) Kai Nissen (WMDE) (talk) 10:18, 28 May 2013 (UTC)[reply]
Gerardo Capiel (talk) 05:38, 31 August 2013 (UTC) I'm the VP of Engineering at Benetech and I'm interested in image and math accessibility as well as discovery of accessible resources[reply]
Nicereddy (talk) 22:54, 13 February 2014 (UTC) I've been an editor on the English Wikipedia for over a year, dabbling a bit in other Wikimedia projects more recently. I'm very interested in this group, as I feel Wikipedia and its sister projects can be improved a huge amount with improved accessibility. I'm a hobbyist graphic designer, most specifically with regards to user interface and experience.[reply]
–Quiddity (talk) 20:28, 29 October 2014 (UTC) I've been dabbling in this area for years (on Enwiki and elsewhere).[reply]
(((Add your name and sign by using "~~~~". All the better if you Introduce yourself briefly.)))

Other endorsements

Beat Estermann (talk) 10:06, 15 May 2013 (UTC)[reply]
Pbsouthwood (talk) 07:47, 17 May 2013 (UTC)[reply]
Sounds like a good idea to me. Sharihareswara (WMF) (talk) 18:41, 22 May 2013 (UTC)[reply]
I work on Language Engineering tools for internationalization and localization support for all Wikimedia websites. I think this is an excellent initiative. Let me know how I can help. Alolita Sharma (talk) 20:15, 29 May 2013 (UTC)[reply]
(((Other people not planning to be members of this group can also express public support))).

Accessibility Tracking in German Wikipedia

This is a TO-DO tracking table summarizing the accessibity issues identified in the extensive study on accessibility (PDF, 1.8MB) of the german Wikipedia chapter as part of the Third Age Online Project.

The table is organized according to the international Web Content Accessibility Guidelines 2.0. It provides information on the problems and examples on where they have been found on the German Wikipedia.

Icons/templates in column 2 allow to assign problems to the appropriate problem solvers: as there is the Wikimedia Foundation for deep programming issues, the German chapter of Wikimedia for their specific programming issues and the Wikipedia community as a whole for accessibility issues adressing editors and authors. Please feel free to change the respective templates.

Note that the existing template is exemplar for the German Wikipedia chapter. We are sure that in most Wikipedia chapters, or whereever MediaWiki is in service accessibility problems are similar or equal.

1.Perceivable

1.1. Text Alternatives

1.1.1. Non-text Content (Level A)

There is a meaningful and equivalent alternative for all non-text content, such as images, graphics, objects, graphic controls in forms and hotspots in image maps.
If the alternative text is not sufficient for the text alternative, a long description is prepared and is referred to in the alternative text.
Decorative graphics or layout graphics have empty alt attributes or they are concealed from assistive technologies (e.g., screen readers) in some other way.
There are no graphic CAPTCHAs or an alternative is present.

Problems 1-3: Linked graphics

In process by Wikimedia (German chapter)

Linked graphics must contain the link purpose within the alt-attribute

Example: Symbolic images for the different portals (main page)

Problem 4: Meaningful alternative texts

Problem identified, can be tackled by Wikipedia Community!

Alternative texts of informative graphics shall be short and clearly inform of what can be seen on graphic.

This issue must be considered by every single Wikipedia author. Accessibility Checklist for authors and publishers (PDF, 414KB) and Content Accessibility Checker for MediaWiki authors

Problem 5: CAPTCHAs

Problem identified!

The CAPTCHAs now present for opening new user accounts are not accessible for blind and visually impaired people.

Possible alternatives: email-assistance, honeypot method, Re-CAPTCHA, Audio-CAPTCHA, …

Problem 6: Unicode symbols

Problem identified!

Some Unicode symbols are not correctly read by screenreaders.

Example: http://de.wikipedia.org/wiki/Poker#Kombinationen.

1.3. Adaptable: Create content that can be presented in different ways (for example simpler layout) without losing information or structure.

1.3.1 Info and Relationship (Level A):

A. Headings

Headings make the structure of the document clear.
Headings are marked up using the heading element (h1, h2, ... , h6).

B. Lists

Listed information is formatted as a list (ul, ol, dl).

C. Forms

In forms with multiple parts, the parts are grouped by content into information blocks.
Labels and related form input fields are logically linked.

D. Data tables

Data tables are formatted with the necessary markup, e.g., headings for columns; rows and tables are clearly labeled, and headings and summaries are present.
Data tables can be read serially and are not used for layout purposes.

Problem A 1,3: Heading structure: software generated pages

Solved by Wikimedia Foundation (USA)!

Visually perceivable headings must also be tagged as headings in html. Semantics and visual perception must be in accordance. Headings levels must be semantically correct and no headings level must be skipped.

Beispiel: "Anmelden/ Benuterkonto einrichten" (“Login/ create account”)

Problem A 2,3: Heading structure: authors

Problem identified, can be tackled by Wikipedia Community!

Visually perceivable headings must also be tagged as headings in html. Semantics and visual perception must be in accordance. Headings levels must be semantically correct and no headings level must be skipped.

This issue must be considered by every single Wikipedia author. Accessibility Checklist for authors and publishers (PDF, 414KB) and Content Accessibility Checker for MediaWiki authors.

Problem B 1a: Listings and lists: authors

Problem identified, can be tackled by Wikipedia Community!

Wherever two or more elements are listed, they must be marked up as lists. Especially for links and other interactive elements. Screenreader users must know how many list items they have to expect: four to five or thousands?

Example: Especially the Wikipedia home- and portal-pages come with many unstructured listings of links. This issue must be considered by every single Wikipedia author. Accessibility Checklist for authors and publishers (PDF, 414KB) and Content Accessibility Checker for MediaWiki authors.

Problem B 1b: Listings and lists: CSS-class

Problem identified, can be tackled by Wikimedia Foundation (USA)!

In order to be able to mark up listings displayed horizontally as lists, some CSS classes should be developed within the MediaWiki syntax.

The final implementation of these classes must be accomplished by the authors: Accessibility Checklist for authors and publishers (PDF, 414KB)

Problem B 2: Listings and lists, Lists with one item only

Solved by Wikimedia (German chapter)!

Lists (ul, ol, dl) with one single item must be avoided

Example: "Benutzerkonto anlegen" (create account) is now a list with two links. Solved

Problem C 1: form-labels

Solved by Wikimedia (German chapter)!

All form fields must be linked correctly to their respective labels by "for" and "id".

Example: CAPTCHA in "Benutzerkonto anlegen" (Create account)

Problem D 1: Semantically correct markup - layout tables:

Problem identified!

The use of tables (in html) for layout purposes is highly deprecated. Actually a NO-GO.

Examples: Main page, positioning of tables of content. Problem: MediaWiki seems not to come with adequate CSS-classes that can be accessed from the Wiki–Editor.

Problem D 2: Semantically correct markup - layout tables in forms:

Solved by Wikimedia Foundation (USA)!

Tables must not be used for layout purposes. Neither in forms.

Example: "Anmelden/Benutzerkonto erstellen" (Log in / create account)

Problem D 3: Semantically correct markup - data tables

Problem identified!

Often data tables do not come with semantically correct syntax: column- and row-headers must be implemented in html with the TH element. Complex data tables must come with scope-attributes.

We suggest starting a concerted action by the community to get this issue fixed. For new tables, this issue must be considered by every single Wikipedia author. Accessibility Checklist for authors and publishers (PDF, 414KB) and Content Accessibility Checker for MediaWiki authors.

Problem D 4: Semantically correct markup - data tables: captions and summaries:

Problem identified, can be tackled by Wikipedia Community!

Large and complex tables should come with captions and summaries.

We suggest starting a concerted action by the community to get this issue fixed. For new tables, this issue must be considered by every single Wikipedia author. Accessibility Checklist for authors and publishers (PDF, 414KB) and Content Accessibility Checker for MediaWiki authors.

1.3.2 Meaningful Sequence (Level A)

The logical order is retained for screen readers and when CSS is turned off.
Contents in tables are correctly linearized and no empty cells are used to create space in the layout.
No character spaces are used to create space in the layout; CSS is used instead.
There is no contextual confusion caused by content positioned with CSS.

Problem 1: Extensible headings

Solved by Wikimedia (German chapter)!

The links in left page column are implemented by CSS. They are tagged as H5 in html.

Screenreader users are not informed of the fact that these H5 are links. Examples: All except Main page

Problem 2: Arbitrary blank lines

Problem identified!

In many Wikipedia articles screenreaders arbitrarily read blank lines in front of links.

Possible cause: the respective links are associated to certain HTML classes

2.Operable

2.1. Keyboard Accessible: Make all functionality available from a keyboard

2.1.1. Keyboard (Level A)

The following can be navigated and operated using the keyboard (tab key):

All page functions and elements.
All form input fields, controls and switches.
No particular timing of individual keystrokes is needed for operation.

Problem 1: Extensible headings

Solved by Wikimedia (German chapter)!

When operating with keyboards, collapsed link lists are skipped. Screenreader users will not know about their existence.

Refer to 1.3.2. Problem 1.

Problem 2: Audio-Player

In process by Wikimedia (German chapter)

The implemented audio-players are not accessible by keyboard

Example: http://de.wikipedia.org/wiki/Wikipedia:Gesprochene_Wikipedia

Problem 3: Editor

Solved by Wikimedia (German chapter)!

Some formatting options (such as the symbol for “bold”), cannot be accessed by keyboard and hence screenreaders.

Suggestion: Allow formatting directly in html.

2.4. Navigable: Provide ways to help users navigate, find content and determine where they are

2.4.1. Bypass Blocks (Level A)

Skip links are made available to avoid repeated blocks of information
Repeated blocks of information are grouped or labeled using headings.

Problem 2: Access-Keys

Problem identified!

Access-key are associated with arbitrary letters (“o” for login, “j” for same page, “t” for discussion). This lead to keyboard conflicts with some browsers.

Suggestion: 0: main page, 1: navigation, 2: content, 3: contact, 4: sitemap, 5: search

2.4.3. Focus Order (Level A)

The order of links in the navigation and in the content is logical.

Problem: Tab indices

Solved by Wikimedia (German chapter)!

On the German page “Anmelden / Benutzerkonto anlegen” the focus jumps from the last language (Chinese) directly to the link “Hinweise zur Passwortwahl” and the actual form to log in is skipped.

Comment: Bug

2.4.4.Link Purpose (In Context) (Level A)

Link texts can be understood either alone or based on the context.
A change in format is indicated by the link text or the context.

Problem 1: Link symbols

Solved by Wikimedia (German chapter)!

Same page links are displayed as up-arrows “&uarr”. These links are not announced by screenreaders.

Problem 2: Non-latin characters

Problem identified, can be tackled by Wikimedia (German chapter)!

Non-latin symbols in the language selection are announced by screenreaders as “link”. Screenreader users cannot know what language the respective links represent.

Problem 5: Information symbol as link

Solved by Wikimedia (German chapter)!

On the German Spoken Wikipedia “Gesprochene Wikipedia”, there are two links/functions “speichern” (save) and “i” (information). The “i” must explicitly declared as information, since blind users cannot see it as an information symbol.

You can also use the CSS class .hidden in order to hide the explicit information.

2.4.7. Focus Visible (Level AA)

Elements with focus are visibly emphasized when they are activated using the keyboard.
Skip links become visible when they receive keyboard focus.

Problem 1: Default focus of browsers

Problem identified, can be tackled by Wikimedia (German chapter)!

The focus of elements when navigating by keyboard is hardly visible. This makes navigating for visually operating keyboard users very hard.

Examples: Search symbols, link texts, linked images

Problem 2: Skip links

Solved by Wikipedia community!

The skip links are not visible for visually operating keyboard users. For them, the focus seems to completely disappear at the beginning of every page.

3.Understandable

3.1. Readable: Make text content readable and understandable

3.1.2. Language of Parts (Level AA))

Sections of text in languages other than the default language are marked up using the lang attribute.
Individual words in another language that could be understood incorrectly or not at all are marked up using the lang attribute.

Problem 1: Foreign-language parts – CSS class

In process by Wikimedia (German chapter)

Parts in foreign languages must always be declared with <span lang “XY”>

Unfortunately there is no MediaWiki markup available for this issue. This should be implemented in the new editor.

Problem 2: Foreign-language parts – community

Problem identified, can be tackled by Wikipedia Community!

Parts in foreign languages must always be declared with <span lang “XY”>

This issue must be considered by every single Wikipedia author. Accessibility Checklist for authors and publishers (PDF, 414KB) and Content Accessibility Checker for MediaWiki authors.