User:RexxS/Accessibility on the English Wikipedia
A review of current provision and issues on the English Wikipedia (Wikipedia for short)
Overview
Wikipedia has WikiProject Accessibility, which "aims to make Wikipedia accessible for users with disabilities." There are editors who also attempt to ensure that Wikipedia is accessible in the broader sense, that is, also available to visitors who have outdated hardware and software or have very low bandwidth connections - a not uncommon situation in the developing and third world.
Wikipedia has a Manual of Style that documents consensus on issues of style. That has a sub-section on accessibility providing guidance on accessibility issues.
The disabilities that are of primary concern are associated with visual disadvantage, although it is recognised that videos and sound files pose problems for visitors who are deaf or hard of hearing. Visual impairment includes blindness (either from birth or in later life), reduced acuity, and multiple forms of colour-blindness.
There are many non-visual user agents available, but JAWS and NVDA are known to be used. JAWS has different capabilities depending on the version in use; the cost of upgrades is sufficiently high that we cannot assume all JAWS users have the latest version. Some visitors make use of text-to-speech addons to enhance their ability to read pages. The Royal National Institute of Blind People has recommended testing webpages with Lynx, a text-only browser that also serves as an illustration of how webpages may render on old equipment or low bandwidth connections.
Issues
The following are the principal issues and the degree to which solutions have been sought.
List articles that are rated as Featured lists are now required to meet the standards laid out in Manual of Style/Accessibility following close cooperation between the members of WikiProject Accessibility and the Featured list community. Articles that are rated as Good articles or Featured articles are not yet required to meet Manual of Style/Accessibility.
Structure
Articles and talk pages are structured through headings and sub-headings. These are well-understood and generally properly implemented to ensure that screen readers can recognise and navigate to sections of interest. Editors generally understand that heading levels must not be skipped and errors are normally fixed quite quickly.
Text
It is recognised that older readers in particular have difficulty in reading text that is substantially smaller than the normal font size used within an article. Guidance now recommends that text should never be reduced below 85% of normal size. This is badly understood by many editors who believe that changes to the user's css can remove the problem, missing the point that 99% of our visitors are not registered editors and do not have the facility to customise the css with Wikipedia-specific changes. There is also the fallacy that it can easily be compensated by the browser zoom, which ignores the inconvenience to the visitor of losing their place in the article every time that the browser zoom is changed. We should expect readers to have set a zoom which makes normal text (12.8px) comfortable to read on their monitor and screen resolution and not expect them to alter it to match tiny text that we have forced into an article.
Different screen readers have different abilities to read characters. Screen readers without Unicode support will read a character outside Latin-1 as a question mark, and even in the latest version of JAWS, Unicode characters may not be read unless the user has enabled a mode that reads all punctuation - a very inconvenient way to read articles. We have established guidance that symbols like † should be replaced with a template Template:† that provides an image with customisable alt text. This guidance is not well-known and many articles persist in using symbols that are either skipped or spoken as '?' by screen readers in their default settings.
Lists
For several years Wikipedia has deprecated the use of html <br /> tags to create vertical lists. See en:Wikipedia:Manual of Style/Lists #Line breaks. Wiki-markup allows the creation of unordered or ordered lists by beginning a line with '*' or '#' respectively. When unbulleted lists are required (for example in an infobox or a table where space is limited), the templates en:Template:Plainlist or en:Template:Unbulleted list are available that produce proper semantic lists without the bullet point or numeral. See en:Wikipedia:WikiProject Accessibility/Infoboxes for a description of the problem dating back to 2006. The problem persists to this day, despite the mechanism and the guidance available to solve it.
In 2011, Andy Mabbett, one of our very active volunteers, raised the question of horizontal lists, which are very common in the navboxes that are often found as navigational aids at the bottom of articles. Such navboxes had consisted of lots of links each separated by a mid-dot (·), which could be quite an annoyance for anybody attempting to traverse the navbox using a screen reader. I was able to produce an accessible solution using a background image and CSS. This was further improved by en:user:Edokter who was able to create a version that scaled well when zoomed and was compatible with most browsers. The result was the "hlist" class which is now used in most wikimedia implementations to create accessible horizontal lists. There are now also the templates Hlist and Flatlist that can be used to create stand-alone horizontal lists, although obviously not for use in running prose. The "hlist" class is now widely implemented in templates thus substantially overcoming the problem of editors not being aware of accessibility issues. Some problems remain such as editors not understanding that even relatively short lists of 3 or 4 items are often better rendered as lists than as plain text for the benefit of screen readers.
For some time, the wiki-markup for definition lists has been abused in an attempt to create a pseudo-heading that would not show in the table of contents. The proper usage is:
- Term to be definited
- Definition of the term ...
But most browsers render the term as bold and this is attractive to editors who just want to make a heading that isn't a heading:
- Notes
The notes go here ...
The proper usage creates a full definition list <dl>...</dl> with a definition term <dt>...</dt> and a definition <dd>...</dd>. The pseudo-heading is a definition list with a term, but no associated definition - again a potential source of confusion and annoyance for screen reader users. There exists still the problem of educating editors on the correct technique to use.
Guidance on using these is available at en:Wikipedia:Manual of Style/Accessibility #Lists along with recommendations on how to avoid fragmenting lists through careless wikimarkup. This guidance is usually quite well understood and mistakes are normally quickly corrected.
Tables
With the exception of the Main Page, Wikipedia is largely free of the use of tables purely for layout and the Manual of Style advises against it. Some common elements such as navboxes may be construed as layout tables, but the organisation of data (often links) within the table is generally organised and marked up as a data table so as not to cause confusion for screen readers. Since most of these are in templates, they are maintained centrally and can be kept reasonably accessible without having to alter every article where they appear.
Data tables are also common on Wikipedia as most make use of tables to produce two-dimensional lists. A Wikipedia standard for data tables is the "Wikitable" whose appearance is set by a class definition (.wikitable - defined centrally by the wikimedia software). A French colleague, Dodoïste put a lot of work into creating the Data tables tutorial which clearly sets out best practice in writing data tables (complete with examples), as well as rating priority and difficulty levels for each technique. The two principal issues are expanded upon below.
1. Most screen readers can make use of table captions to find and navigate directly to tables, so the use of table captions is encouraged, although unfortunately not compulsory. I often find that a caption is omitted and the first row of a table is column-spanned across the full width to use as a caption, because the default formatting of captions place them outside the table border. I can usually replace the column-spanning row with wikimarkup similar to this:
|+ style="border:1px solid #AAA; border-bottom:none;" | Caption text
without anybody noticing and complaining (although any background colour will need to be matched, of course).
2. Several screen readers can make use of column and row headers in a "table navigation mode" where the column or row headers, or both, can be read out before the contents of each cell to allow navigation to the left or right or up or down. The most popular screen reader JAWS is quite sophisticated as the tutorial below illustrates:
- "Tables with JAWS and MAGic". 2 April 2012. http://www.freedomscientific.com/Training/Surfs-up/Tables.htm. Retrieved 17 April 2014.
Unfortunately we cannot assume that everybody has JAWS, so we aim to cover as many eventualities as possible by encouraging editors to properly identify sensible column and row headers, and to mark them up as table headers with column or row scope respectively:
! scope="col" | Column header ! scope="row" | Row header
Almost all tables have column headers identified and marked up as header cells. Many of those now have the correct scope markup. Far fewer tables have row headers marked up as header cells or given row scope. One of the barriers to marking up row headers is that it would alter the formatting of the cell in most browsers: background-colour becomes #F2F2F2 and the text becomes bold and centred. In an effort to help overcome the objections of editors who only considered the visual display of the table, a group of us were able to gain consensus for a site-wide class (defined in Mediawiki:Common.css} called "plainrowheaders" that restored the left-alignment and normal font-weight of any row header cell. This has allowed us to create tables with class="wikitable plainrowheaders" which visually mimic tables that have no row headers, while having the full header markup to facilitate free navigation by screen readers.
Editors most often create tables by copying tables in other similar (often Featured) articles or lists. It has been important, therefore, to mark up as many of the Featured lists as possible with the most accessible markup so that those features will be copied, even though editors may not necessarily know why. We have been fortunate that the regular Featured List community has enthusiastically embraced the accessibility guidance and has made compliance with Manual of Style/Accessibility a requirement for a list article to achieve Featured status ("Featured content represents the best that Wikipedia has to offer"). We still have work to do to reach the same position with Featured Articles.