User:RexxS/Accessibility on the English Wikipedia
A review of current provision and issues on the English Wikipedia (hereafter: Wikipedia)
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>, but 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
- en:Wikipedia:Manual of Style/Accessibility #Tables
- en:Wikipedia:Manual of Style/Accessibility/Data tables tutorial