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 chapters
 * 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-04-25: Set up of the current proposal
 * YYYY-MM-DD: Proposal announced to wikitech-l.

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)
 * COMING SOON: Content Accessibility Checker for MediaWiki authors
 * [[Media:PublisherAccessibilityChecklist4MediaWiki.pdf|Accessibility Checklist for authors and publishers (PDF, 414KB)]]

Related

 * Related links welcome!

See also:
 * Third Age Online Project

Contributors

 * MediaWiki groups need at least 3 people to be approved.

Promoters
 * Barrierefrei (talk) 11:42, 25 April 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)
 * (((Add your name and sign by using "~" . All the better if you Introduce yourself briefly.)))

Other endorsements
 * (((Other people not planning to be members of this group can also express public support))).

1.Perceivable
{| border="1" cellpadding="20" cellspacing="0"
 * colspan="4"|

1.1. Text Alternatives



 * colspan="2"|

1.1.1. Non-text Content (Level A)

 * colspan="2"|
 * 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
 * Linked graphics must contain the link purpose within the alt-attribute
 * Example: Symbolic images for the different portals (main page)
 * 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. [[Media:PublisherAccessibilityChecklist4MediaWiki.pdf|Accessibility Checklist for authors and publishers (PDF, 414KB)]] and Content Accessibility Checker for MediaWiki authors
 * This issue must be considered by every single Wikipedia author. [[Media:PublisherAccessibilityChecklist4MediaWiki.pdf|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, …
 * 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.
 * Example: http://de.wikipedia.org/wiki/Poker#Kombinationen.


 * colspan="4"|

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

 * colspan="2"|
 * colspan="2"|

1.3.1 Info and Relationship (Level A):
A. Headings B. Lists C. Forms D. Data tables
 * colspan="2"|
 * Headings make the structure of the document clear.
 * Headings are marked up using the heading element (h1, h2, ..., h6).
 * Listed information is formatted as a list (ul, ol, dl).
 * In forms with multiple parts, the parts are grouped by content into information blocks.
 * Labels and related form input fields are logically linked.
 * 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
 * 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”)
 * 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. [[Media:PublisherAccessibilityChecklist4MediaWiki.pdf|Accessibility Checklist for authors and publishers (PDF, 414KB)]] and Content Accessibility Checker for MediaWiki authors.
 * This issue must be considered by every single Wikipedia author. [[Media:PublisherAccessibilityChecklist4MediaWiki.pdf|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. [[Media:PublisherAccessibilityChecklist4MediaWiki.pdf|Accessibility Checklist for authors and publishers (PDF, 414KB)]] and Content Accessibility Checker for MediaWiki authors.
 * 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. [[Media:PublisherAccessibilityChecklist4MediaWiki.pdf|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: [[Media:PublisherAccessibilityChecklist4MediaWiki.pdf|Accessibility Checklist for authors and publishers (PDF, 414KB)]]
 * The final implementation of these classes must be accomplished by the authors: [[Media:PublisherAccessibilityChecklist4MediaWiki.pdf|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
 * 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)
 * 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.
 * 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)
 * 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. [[Media:PublisherAccessibilityChecklist4MediaWiki.pdf|Accessibility Checklist for authors and publishers (PDF, 414KB)]] and Content Accessibility Checker for MediaWiki authors.
 * 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. [[Media:PublisherAccessibilityChecklist4MediaWiki.pdf|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. [[Media:PublisherAccessibilityChecklist4MediaWiki.pdf|Accessibility Checklist for authors and publishers (PDF, 414KB)]] and Content Accessibility Checker for MediaWiki authors.
 * 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. [[Media:PublisherAccessibilityChecklist4MediaWiki.pdf|Accessibility Checklist for authors and publishers (PDF, 414KB)]] and Content Accessibility Checker for MediaWiki authors.


 * colspan="2"|

1.3.2 Meaningful Sequence (Level A)

 * colspan="2"|
 * 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
 * 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
 * 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
{| border="1" cellpadding="20" cellspacing="0"
 * colspan="4"|

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

 * colspan="2"|
 * colspan="2"|

2.1.1. Keyboard (Level A)
The following can be navigated and operated using the keyboard (tab key):
 * colspan="2"|
 * 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
 * When operating with keyboards, collapsed link lists are skipped. Screenreader users will not know about their existence.
 * Refer to 1.3.2. Problem 1.
 * 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
 * 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.
 * Suggestion: Allow formatting directly in html.


 * colspan="4"|

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

 * colspan="2"|
 * colspan="2"|

2.4.1. Bypass Blocks (Level A)

 * colspan="2"|
 * Skip links are made available to avoid repeated blocks of information
 * Repeated blocks of information are grouped or labeled using headings.


 * Problem 1: Skip links
 * All pages come with skip links to navigation and search but with no link jumping directly to the main content area.
 * All pages come with skip links to navigation and search but with no link jumping directly to the main content area.
 * All pages come with skip links to navigation and search but with no link jumping directly to the main content area.


 * 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
 * Suggestion: 0: main page, 1: navigation, 2: content, 3: contact, 4: sitemap, 5: search


 * colspan="2"|

2.4.3. Focus Order (Level A)
The order of links in the navigation and in the content is logical.
 * colspan="2"|


 * 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
 * Comment: Bug


 * colspan="2"|

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

 * colspan="2"|
 * 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
 * Same page links are displayed as up-arrows “&uarr”. These links are not announced by screenreaders.
 * Same page links are displayed as up-arrows “&uarr”. These links are not announced by screenreaders.
 * 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.
 * 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.
 * You can also use the CSS class .hidden in order to hide the explicit information.


 * colspan="2"|

2.4.7. Focus Visible (Level AA)

 * colspan="2"|
 * 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
 * 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
 * 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
{| border="1" cellpadding="20" cellspacing="0"
 * colspan="4"|

3.1. Readable: Make text content readable and understandable

 * colspan="2"|
 * colspan="2"|

3.1.2. Language of Parts (Level AA))

 * colspan="2"|
 * 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
 * Parts in foreign languages must always be declared with 
 * Unfortunately there is no MediaWiki markup available for this issue. This should be implemented in the new editor.
 * Parts in foreign languages must always be declared with 
 * 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 
 * This issue must be considered by every single Wikipedia author. [[Media:PublisherAccessibilityChecklist4MediaWiki.pdf|Accessibility Checklist for authors and publishers (PDF, 414KB)]] and Content Accessibility Checker for MediaWiki authors.
 * }
 * }
 * }