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

edit
  • 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

edit
  • 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

edit

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

Materials provided

edit
edit
Related links welcome!

See also:

Contributors

edit
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

Other endorsements

Accessibility Tracking in German Wikipedia

edit

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

edit

1.1. Text Alternatives

edit
1.1.1. Non-text Content (Level A)
edit
  • 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.

edit
1.3.1 Info and Relationship (Level A):
edit

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)
edit
  • 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

edit

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

edit
2.1.1. Keyboard (Level A)
edit

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

edit
2.4.1. Bypass Blocks (Level A)
edit
  • 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)
edit

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
edit
  • 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)
edit
  • 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

edit

3.1. Readable: Make text content readable and understandable

edit
3.1.2. Language of Parts (Level AA))
edit
  • 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.

Legend

edit
  Problem identified!
  Problem identified, can be tackled by Wikimedia (German chapter)!
  Problem identified, can be tackled by Wikimedia Foundation (USA)!
  Problem identified, can be tackled by Wikipedia Community!
  In process by Wikimedia (German chapter)
  In process Wikimedia Foundation (USA)!
  In process by Wikipedia community. Refer to Accessibility Checklist for authors and publishers (PDF, 414KB) and Content Accessibility Checker for Wikipedia
  Solved by Wikimedia (German chapter)!
  Solved by Wikimedia Foundation (USA)!
  Solved by Wikipedia community!