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
editThe official channel of communication of this group is its Discussion page.
Materials provided
edit- 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
edit- Related links welcome!
See also:
- Third Age Online Project
- «Access for all» foundation (large parts in german language]
Contributors
edit- MediaWiki groups need at least 3 people to be approved.
Promoters
- Barrierefrei (talk) 11:42, 25 April 2013 (UTC)
- 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)
- 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)
- 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)
- (((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)
- RexxS (talk) 17:46, 16 May 2013 (UTC)
- Dodoïste (talk) 09:27, 28 May 2013 (UTC)
- 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)
- 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
- 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.
- –Quiddity (talk) 20:28, 29 October 2014 (UTC) I've been dabbling in this area for years (on Enwiki and elsewhere).
- (((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)
- Pbsouthwood (talk) 07:47, 17 May 2013 (UTC)
- Sounds like a good idea to me. Sharihareswara (WMF) (talk) 18:41, 22 May 2013 (UTC)
- 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)
- (((Other people not planning to be members of this group can also express public support))).
Accessibility Tracking in German Wikipedia
editThis 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 Alternativesedit | |||||
1.1.1. Non-text Content (Level A)edit |
| ||||
Problems 1-3: Linked graphics |
|
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 |
|
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 |
|
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 |
|
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
B. Lists
C. Forms
D. Data tables
| ||||
Problem A 1,3: Heading structure: software generated pages |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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: |
|
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: |
|
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 |
|
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: |
|
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 |
| ||||
Problem 1: Extensible headings |
|
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 |
|
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 keyboardedit | |||||
2.1.1. Keyboard (Level A)edit |
The following can be navigated and operated using the keyboard (tab key):
| ||||
Problem 1: Extensible headings |
|
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 |
|
The implemented audio-players are not accessible by keyboard | Example: http://de.wikipedia.org/wiki/Wikipedia:Gesprochene_Wikipedia | ||
Problem 3: Editor |
|
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 areedit | |||||
2.4.1. Bypass Blocks (Level A)edit |
| ||||
Problem 2: Access-Keys |
|
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 |
|
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)edit |
| ||||
Problem 1: Link symbols |
|
Same page links are displayed as up-arrows “&uarr”. These links are not announced by screenreaders. | |||
Problem 2: Non-latin characters |
|
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 |
|
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 |
| ||||
Problem 1: Default focus of browsers |
|
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 |
|
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 understandableedit | |||||
3.1.2. Language of Parts (Level AA))edit |
| ||||
Problem 1: Foreign-language parts – CSS class |
|
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 |
|
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
|
|
|
| ||||||||
|
|
| |||||||||
|
|
|