Wikipedia:WikiProject Accessibility/Methodology
- 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.
| WikiProject Accessibility |
|---|
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. (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 therefore consists of:
- identifying and removing barriers to the production of accessible content at various levels of the project, i.e. the CMS and its use (ensuring that Wikipedia does not 'hinder' accessibility),
- identifying and developing the means by which the production of accessible content can be promoted (ensuring that Wikipedia ‘promotes’ accessibility)
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
[edit]The analysis is based on the identification of 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 |
|
| Default templates |
|
| Extensions |
|
| Localised settings | |
| Templates |
|
| Editors |
|
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 the developers.
The issue of editorial risk
[edit]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.
| 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.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.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
[edit]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
[edit]Evaluations may be based on the tests defined by one of the following methodologies:
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.
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.
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.