This meta page is intended for discussion about the accessibility of Wikimedia wikis. The concept encompasses not only Making Wikipedia more accessible to the blind, but to any user that is not browsing Wikimedia wikis 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 accessibility of Wikimedia wikis might be improved
- What recommendations should be made for Wikimedia wikis in order to improve accessibility (e.g. policies and guidelines on the English Wikipedia)
- How the existing content of Wikimedia wikis might be refactored in order to improve accessibility
- How the software behind Wikimedia wikis could be modified to improve accessibility
Wikimedia wikis are already quite accessible, when compared with many other sites. But there are still a few things we can do, especially in the area of recommendations about how to write articles and create pages, that will make wikis even more accessible, and available to even more people.
Some highlights include:
- Accessibility guide for developers
- Phabricator’s accessibility category
- WikiProject Accessibility on the English Wikipedia
- Request for accessibility specifications September 2020
- Adding an accessibility requirement?, September 2020
- Community Wishlist Survey 2021/Reading/Increased accessibility, November 2020
- Accessibility of Wikipedia, a March 2021 use test session, March 2021
People and organizations actively working on accessibility
See the list on mediawiki.org.
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
alttext 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
Accessibility helps everyone
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. An integrated text-to-speech solution in the MediaWiki software, such as Wikispeech, enables more people to take advantage of 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.
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
fonttags, 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.
- Get involved in the development of the Wikispeech extension to make Wikipedia more accessible for people that have limited reading abilities.
Color for the color blind or visually impaired
- We lack specific guidelines, help pages or tutorials on how to draw maps and charts which are readable by color-blind users.
- w:en:Wikipedia:WikiProject Maps/Conventions/Gradient maps is a nice step.
- 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 specific color impair at a time for both, websites 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 colors 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.
- Grants:IEG/Color blindness content checker - 2015 (not selected)
- Wikimedia Design Style Guide provides a color palette for user interfaces and text, that conforms to WCAG 2.0 level AA
- strategy:Category:Proposals for improving accessibility
- mw:Accessibility guide for developers
- w:Wikipedia:WikiProject Accessibility (and extensive sidebar navbox)
- WikiBlind User Group
- Wikimedia Accessibility User Group