Accessibility

This meta page is intended for discussion about the accessibility of Wikipedia. The concept encompasses not only Making Wikipedia more accessible to the blind, but to any user that is not browsing Wikipedia using their eyes, or is not using a graphical browser on a desktop computer. Please note that this page is not intended for the purpose of recommending policy, editing guidelines, or other suggestions to contributors; it is for discussion of:

• The ways in which Wikipedia's accessibility might be improved
• What recommendations should be made in Wikipedia's policies and guidelines pages in order to improve accessibility
• How the existing content of Wikipedia might be refactored in order to improve accessibility
• How the software Wikipedia uses could be modified to improve accessibility

It should be noted that Wikipedia's design is already quite accessible, when compared with many other sites. The designers of Wikipedia's site layout and software have clearly taken significant steps towards making Wikipedia accessible and available to as many people as possible. The broad application of CSS and the implementation of valid HTML places Wikipedia head and shoulders above many contemporary sites. Bravo! But there are still a few things we can do, especially in the area of recommendations about how to write articles, that will make Wikipedia even more accessible, and available to even more people. This meta page is about discussing what we can do to make Wikipedia more accessible.

People and organizations actively working on accessibility

See the list on mediawiki.org.

Issues

Several components of Wikipedia may need extra attention in order to make them accessible:

• Templates at top of page : Watch (listen) what happens when a screen reader hits one of these. It ain't pretty. Many infoboxes are very hard to navigate in practice.
• Images - there has been extensive discussion (though as yet no real agreement) about what is the appropriate alt text to use for images. Other aspects may be relevant as well.
• Colors - Color may not be seen, or may not be seen in the same way, by all users.
• Tables - Tables are primarily a visual means of representing information, and as such, authors often format them to look good visually, at the expense (or simple neglect) of good rendering in text-only or spoken form. Tables are meant for data, and should not be used for layout effects.
• Hypertext links - The phrase which is used for hypertext links is often of importance. Usually, authors are recommended to stay away from things like "click here", since it makes no sense when taken out of context. Good link phrases are important.
• Appropriate markup - HTML markup is often used to specify visual presentation characteristics (such as color, font styles, and layout), but the real purpose of HTML markup is to give semantic and structural meaning to the text.
• WCAG checkpoints - Cannot make MediaWiki meet WCAG checkpoints
• (Others?)

Not just for the blind

Often when we talk about accessibility, we're talking about making sites accessible to the blind. Since the web is a predominantly visual medium, it is often assumed that the only group we must accommodate in accessibility design is the visually impaired. However, there are other groups of people who should also be considered. Particular issues might include:

• Color-blindness - Various estimates indicate that around 8-10% of males (and a very small percentage of females) are red-green colorblind, or have other forms of colorblindness. The use of color in website design can affect the experience these users have. Wikipedia should use carefully-chosen colors to avoid problems in this area. Any important information which is conveyed using color should also be conveyed in another form, for users who cannot see the colors.
  • Color Blindness and Web site Design by Jeanne Liu is a short document explaining why this is important.
• Impaired vision - Wikipedia provides no mechanism I can see (heh) that allows the reader to have the pages rendered in a larger font. Furthermore, Wikipedia style sheets appear to be set up in such a way that setting the minimum font size preference on at least some common browsers (e.g. Firefox) does not change the font of Wikipedia pages.
• No mouse - The web is often navigated by users with a mouse or other pointing device. Some users of the web cannot accurately control a mouse for whatever reason, or who prefer not to use a mouse. Links must be tabbed through or otherwise selected without the aid of a random-access device like a mouse. We should take care to ensure that Wikipedia is easily navigable by such users.
• Text-only renderings - Many users, either through preference or necessity, browse the web with a text-only interface. We should ensure that Wikipedia looks good to them too.
• Speech renderings - Closely related to text-only renderings, speech renderings of websites are often strictly sequential. Sites designed predominantly with visual appearance in mind may not be so great when read through a speech browser. There may be problems of sequential navigation, alternate text, and enabling users to skip over sections they aren't interested in. Wikipedia should make sense when presented in speech renderings.
• Illiteracy - Illiterate users, or users with reading difficulties, may prefer visual or spoken alternatives to text. This may be a difficult group to accommodate, given that Wikipedia is an encyclopedia requiring a significant degree of literacy, but it is something to keep in mind.
  • Vocabulary matters - many articles use jargon or obscure terms, and this is a major issue not just for the semi-literate, those speaking English as a foreign or second language, and children, but often for professionals crossing fields.

Accessibility has a number of other advantages, too; if done well, accessibility design benefits everyone in that it often makes a site easier to use and navigate, gives it the capability for display on a wider variety of platforms and devices (such as mobile devices), and may provide the site with a clearer visual design and layout. It also allows search spiders to better index the site, as they are essentially blind.

Examples

Many articles on Wikipedia use tables. There is some debate about when a table is appropriate, and how complex it should be. Sometimes, the content presented by a table may be made simpler using a list format. For an example of how some complex tables might be better formatted, see Wikipedia accessibility/Table example. See w:Wikipedia:How to use tables for additional discussion on where tables are appropriate, and how to keep them simple.

Proposed items to do

This section is to list proposed items to do for the purpose of improving accessibility. Feel free to add your own proposals or discuss existing ones.

• Modify the PHP code to generate a heading bar without any tables. (Apparently this has also been proposed on the WikiTech mailing list. Accessibility is another good reason to do it.)
  • on my list of things to do, sort of. See Skins
• Closely related to the above, revise the code to avoid other potential accessibility problems as much as possible.
• Revise templates for Tree of Life taxoboxes, chemical elements, or others, if a non-table or less table-intensive layout is agreed upon. See the table example for examples. (This is a large undertaking, so it may take a while to determine what should be done about them, if anything. Anyone working on a WikiProject of this variety, your input would be welcomed!)
• Determine what custom or global style sheets may need to be created in order to eliminate latent dependencies on font tags, tables, explicit color or size declarations, and other stuff that we could provide a good CSS solution for.
• Fix bug 4845 - CAPTCHA doesn't work for blind people.

Colour-blind-friendly images

• We lack specific guidelines, help pages or tutorials on how to draw maps and charts which are readable by colour-blind users.
  • w:en:Wikipedia:WikiProject Maps/Conventions/Gradient maps is a nice step.
• Vischeck (unavailable?) is a very easy tool which allows to upload an image and see how it looks to colour-blind users.
• http://www.color-blindness.com/coblis-color-blindness-simulator/ Upload 1 image at a time, to check 8 types.
• http://colorfilter.wickline.org/ Use URLs to check 1 at a time. Pages or images.
• Any free software tool? Especially for mass-checks of all our illustrations. Dichromacy for ImageJ can do it; developer says to "Have a look in the IJ documentation to see how you can record macros".
• Colorbrewer, the Accessibility Color Wheel and Colour Contrast Check can be used to select good colours for an illustration.
• Communicating data with colour: a rather complete but not verbose and quick guideline, with several tips.
• mw:Talk:Accessibility#Colour-blindness links and notes - further pointers. Link-roundup.

See also

• Mobile
• strategy:Category:Proposals for improving accessibility
• mw:Accessibility
• mw:Accessibility guide for developers
  • TAO's MediaWiki – Accessibility Enhancements
• w:Wikipedia:WikiProject Accessibility (and extensive sidebar navbox)

External links

• Web Accessibility Initiative
• WAI Quick Tips
• Authoring Tool Accessibility Guidelines
• Complete List of Web Accessibility Evaluation Tools