Wikipedia:WikiProject Accessibility/Methodology

The approach of the Accessibility Workshop is based primarily on the Web Content Accessibility Guidelines (WCAG1). However, these require the use of an implementation methodology that makes it possible in particular to:

update the provisional WCAG 1 checkpoints (dating from 1999) and take into account the advances of the WCAG 2 project (which is nearly finalised),
clarify them in the specific context of Wikipedia.

In the absence of a methodology specifically defined for Wikipedia, the methods outlined below are indicative.

The usual approach to WCAG accessibility consists of:

carrying out an evaluation of the existing site, based on an audit of a sample of typical content pages and strategic pages, using a test reference framework (see the last section of this page),
identifying weak points to be improved and strengths to be preserved,
making corrections and ensuring their long-term sustainability.

Its aim is to reach and maintain a fixed level of compliance (one of levels A, AA, or AAA defined by WCAG).

This approach is unsuitable here, due to the multiplicity and volatility of content. However, attempts at evaluation along these lines have been made, see Accessible websites in Quebec and apparently User:Valérie75 in 2006.

Wikipedia instead falls under a continuous risk-management approach, where evaluation is carried out using an ATAG-type approach (Authoring Tool Accessibility Guidelines). This method consists of:

identifying and removing barriers to producing accessible content at various levels of the project (i.e. the CMS and its use),
identifying and developing means by which producing accessible content can be promoted

Strictly speaking, this workshop does not implement a true ATAG approach, but rather an intermediate approach between the usual methodology and ATAG: for example, the accessibility of the editing interface and, more generally, of MediaWiki as a CMS is not fully addressed.

Six levels of risk

The analysis identifies six levels of risk for accessibility. At each level, it is possible to identify obstacles and/or means of promoting accessibility:

	Examples of impact
MediaWiki core	HTML structure of content, including links and images Special pages
Default templates	Overall interface structure (menus, footers, headers, keyboard shortcuts, etc.) CSS JavaScript
Extensions	Additional HTML structures and content Special pages Forms
Localised settings	MediaWiki:Common.css MediaWiki:Common.js System messages
Templates	HTML structures CSS Metadata (language changes)
Editors	HTML structures CSS Article content (images, timelines, etc.) Metadata (language changes)

The first three levels (the MediaWiki core, default templates, and extensions) are not within the direct scope of action of this workshop. However, it is entirely possible to intervene by reporting bugs and submitting improvement proposals to developers.

The issue of editorial risk

The accessibility of Wikipedia cannot be reduced to technical issues that can be addressed in a more or less automated way. Editorial work (the daily additions and modifications made by all contributors) and the collaborative nature of the platform have a major impact on the accessibility of the content.

Examples of editorial risks
WCAG1.0 directive	Control point	Example on Wikipedia
1. Provide equivalent alternatives to visual and auditory content	1.1 Provide a textual alternative to non-textual elements	Relevance of image alternatives
2. Do not rely solely on colours	2.1 Do not use colour alone to convey information.	Graphic choices for maps, diagrams, etc.
3. Use markup and style sheets appropriately	3.5 Using title hierarchy	Frequent reluctance to reduce to a sufficient titration level
3. Use markup and style sheets appropriately	3.6 Use list items appropriately	Preference for unstructured lists for stylistic reasons (examples)
5. Create tables that transform elegantly	5.1 Marking row and column headers	Relevance of header labels
5. Create tables that transform elegantly	5.5 Provide additional information on data tables	Relevance of summaries and table titles
13. Provide clear navigation mechanisms	13.1 Identify link destinations	Relevance of link descriptions
	13.3 Provide information on the general architecture of the website	Ambiguous categorisations
	13.4 Provide consistent navigational mechanisms	Relevance of variations across projects (navigation palettes, etc.)
	13.8 Write content in a simple, logical and orderly manner	Quality of article writing
14. Ensure that pages are clear and simple	14.1 Use clear and simple language	Relevance of links for understanding content
	14.2 Provide visual or audio illustrations	Relevance of images and sound illustrations for understanding content
	14.3 Provide a consistent presentation throughout the site	Relevance of graphic choices for consistency in the presentation style of information and navigation blocks

Possible workshop strategy

The work may be organized in practice by establishing priorities according to the level of risk impact. For example:

Common.css and Common.js
The most widely used templates and extensions (including those listed here)
The most frequently used editorial micro-content (e.g. language templates, links, image alternatives)
Projects that generate a significant volume of “standardized” content (e.g. Counties of the United Kingdom)
Featured Articles and Good Articles, insofar as they define the target format intended to serve as a model for all articles

In addition to precisely identifying the specific items (pages, templates, etc.) to be monitored, an initial phase of the project should consist of adapting an existing evaluation methodology to the MediaWiki environment. This may include:

Adjusting the scope of the tests so that they assess wiki syntax rather than rendered HTML output, where feasible and appropriate
Excluding any tests that are not applicable in light of the nature of the site and its content
Structuring the evaluation into sections corresponding to distinct needs, thereby facilitating its use (e.g., “testing an infobox,” “testing a clickable map,” “testing a script,” etc.)
Improving usability by adopting a clearer, more instructional style directly aligned with the practices of Wikipedia contributors

Methods for applying WCAG to Wikipedia content testing

Evaluations may be based on the tests defined by one of the following methodologies:

Public RGAA Deployment Method:

This method is recent and comprehensive in relation to WCAG. However, a subset of the applicable tests would need to be developed in order to simplify implementation. The document currently available at this address is not the final version, although the finalized version may be accessible elsewhere.

Evaluation Methodology UWEM 1.2

This recent methodology does not fully cover WCAG. It presents the same requirement to produce a subset of tests, subject to considerations regarding usage rights.

Method guide

Soon to be updated, this methodology does not fully cover WCAG and includes several additional criteria. Its principal strength lies in its highly pedagogical approach. However, it does not allow for the extraction of a subset of tests, due to rights-related constraints.