Wikipedia:Manual of Style/Accessibility
 | This guideline is a part of the English Wikipedia's Manual of Style. It is a generally accepted standard that editors should attempt to follow, though occasional exceptions may apply. Any substantive edit to this page should reflect consensus. When in doubt, discuss first on the talk page. |
| Manual of Style (MoS) |
|---|
Accessibility is the goal of making web pages easier to navigate and read. While this is primarily intended to assist those with disabilities, it can be helpful to all readers. Articles adhering to the following guidelines are easier to read and edit by those Wikipedians with and without disabilities.
Article structure
Lead section
As explained in detail at Wikipedia:Lead section#Elements of the lead, the lead section may contain optional elements presented in the following order: disambiguation links (dablinks), maintenance tags, infoboxes, images, navigational boxes (navigational templates), introductory text, and table of contents, moving to the heading of the first section.
Headings
- Headings should be descriptive and in a consistent order (See also—References—Further reading—External links).
- Headings should be nested sequentially, starting with level 2 (
==), then level 3 (===) and so on (level 1 is not used, as this is the auto-generated page title), neither using random heading levels (e.g. selected for emphasis, which is not the purpose of headings), nor skipping parts of the sequence.
| Correct | Random/chaotic | Skipping levels |
|---|---|---|
|
|
|
Section structure
- As explained above for the lead section, each section should have a specific structure:
<!-- CORRECT CODE -->
== Foo bars ==
{{main|Foo bar}}
{{cleanup-section}}
[[Image:...|Typical Foo bar]]
A '''foo bar''' ...
- Note also that the image should be inside the section it belongs to (after the header and after any links to other articles), and not just before the header for similar reasons.
Resolution
Wikipedia articles should be accessible to readers using devices with small screens, or to readers using monitors with a low resolution. The lowest resolution that it is considered possible to support without adversely affecting other users is 800x600; all articles should look acceptable at this resolution without excessive horizontal scrolling. This is sometimes an issue in articles with multiple images on both sides of the screen; although lower resolutions will tend to stretch paragraphs vertically, moving images apart in that direction, be careful not to add images or other floating content on both sides of the screen simultaneously. Large tables and images can also create problems; sometimes horizontal scrolling is unavoidable, but consider restructuring wide tables to extend vertically rather than horizontally.
Text
- Spelling and grammar errors can dramatically affect the sound of the text ("initative" instead of "initiative"), which can make the text more difficult to read.
- Don't use strikethrough to remove objectionable text in articles. Either comment it out with "<!--" and "-->" or remove it entirely. By default, most screen readers do not indicate text attributes (bold, italic, underline), so struck-out text is read normally along with any other text. (Editors who participate in Wikipedia policy and XfD debates are advised to turn on the sounding of text attributes when doing so, as struck text is very common in Wikipedia-internal discussions.)
- Provide a transliteration for all text in a non Latin writing system. Screen readers without Unicode support will read a character outside Latin-1 as a question mark, and even in the latest version of JAWS, the most popular screen reader, Unicode characters are very difficult to read.
- Don't use techniques that require physical action to provide information, such as tooltips or any other "hover" text.
- When editing, never break up a line unless absolutely necessary, as the easiest way to edit with a screen reader is to navigate line by line.
- You can change your individual display to show footnotes in full sized text by addingto your Special:Mypage/monobook.css
.references-small { font-size: 100%; }
Links
- Do not overlink. Screen readers put each link on its own line.
- Create good link descriptions, especially for external links. (avoid "click here!" or "this" kinds of links)
- Avoid putting links in section headings, unless the link text is the only text in the title. Some screen readers, such as earlier versions of JAWS, will stop reading the heading title when they encounter a link, and if the link is the first part of the heading title, they will only read the link text. For example, a heading title of "The [[chimpanzee]]s invade the sewer system" may be read as "The", and a heading title of "[[Box]]es in popular culture" may be read as "Boxes".
- Use as little code as possible, so the text in the edit window is easier to read (for example: don't use
[[clock|clocks]]when[[clock]]swill work).
Color
Block elements
Lists
Do not separate list items by more than one line-break. If list items are separated by more than one line break, the HTML list tags will be ended. For example:
#One is a good number. #Two is a better number. #Three is the best number in the world. #But the number four should not be mentioned at all costs.
appears as:
- One is a good number.
- Two is a better number.
- Three is the best number in the world.
- But the number four should not be mentioned at all costs.
The same applies to unordered lists (using * instead of #).
Horizontal lists
For lists running across the page, the template {{flatlist}} and its partner {{endflatlist}} are available, to improve accessibility and semantic meaningfulness by marking up what is clearly a list, as such, rather than characters which are read out (e.g. "one dot two dot three dot...") by the kind of assistive software used by, for example, people who are blind. Alternatively, in templates and the like, such lists may be styled with the class "horizontal".
Tables
Screen readers and other web browsing tools make use of specific table tags to help users navigate the data contained within them.
Use the correct wikitable pipe syntax to take advantage of all the features available. See meta:Help:Tables for more information on the special syntax used for tables. Some clients may not use CSS, so relying on CSS for table borders may render incorrectly.
Data tables
{|
|+ [caption text]
|-
! [column header 1] !! [column header 2] !! [column header 3]
|-
! [row header 1]
| [normal cell 1,2] || [normal cell 1,3]
|-
! [row header 2]
| [normal cell 2,2] || [normal cell 2,3]
…
|}
- Caption (
|+) - A caption is a table's title, describing its nature [1].
- Row & column headers (
!) - Like the caption, these help present the information in a logical structure to visitors. They can have the headers read first, and then navigate the related data [2].
Voice browsers might read aloud this data table in the following order [3]:
- Caption: [caption text]
- [column header 1]: [row header 1], [column header 2]: [cell 1,2], [column header 3]: [cell 1,3]
- [column header 1]: [row header 2], [column header 2]: [cell 2,2], [column header 3]: [cell 2,3]
- …
Note that each column header is repeated when reading every row, so an abbreviation could be added to long headers using the abbr="…" attribute, for example:
{|
|+ [caption text]
|-
! abbr="Wikipedian" | Wikipedia editor
! abbr="Edits" | Number of edits
! Last edit
! abbr="Donations" | Donations (US$)
|-
…
In this example all column headers have an abbreviation except the column with the date of the last edit, which is short enough.
It can cause problems if a column or row header contains a colspan/rowspan. If there is a colspan in the first table row, both columns will be described the same by the voice browser; a similar thing happens if the first table column has rows joined by a rowspan. This may be mitigated by other aspects of the table; for instance the table may be chronologically organized, or the two columns may contain, respectively, a hard number and a percentage with a percent sign.
It can cause problems if the first column in a row has non-text comment such as a photograph (unless the photograph contains an alt attribute) or a color without explanatory text.
Layout tables
Some navboxes, series templates, and infoboxes are made using tables.
Avoid using tables for layout purposes only. The best option is to use HTML's <div> blocks and style attributes because they provide flexibility. For example, see {{Dynamic navigation box}}.
For simple layouts tables can be an option. Especially if the only point of the table is to get a floating effect, then align="right" etc. will work with some browsers not supporting CSS at all. This is in fact a verbose approximation of <div> plus CSS, and not the design sin known as (nested) "table layout".
However, to avoid accessibility barriers, when using tables for layout purposes don't use any caption, row, or column headers, and also no summary attribute. These structural table elements should be used only for data tables. Don't use structural elements for presentation purposes, use style sheets. For Wiki table markup this means to avoid "!" (= <th> in XHTML) in such cases:
{| class="toccolours" width="94%"
| align="center" bgcolor="#ccccff" | '''Title'''
|-
| [normal cell] || [normal cell]
|-
| [normal cell] || [normal cell]
|}
For example, see {{NavigationBox}}
Scrolling and collapsible sections
Scrolling and collapsible sections in tables or other block elements can be useful to save space and conceal at first-sight potentially superfluous information. However, such techniques must be used with caution, as this content can become inaccessible in a number of situations. Printers and screen-readers will both output only the content that is immediately visible on the page, and these structures are more likely to exhibit undesirable behavior on certain browsers. As such, these methods should not be used in the article body. This includes reference lists, image galleries, and image captions; they especially should not be used to conceal 'spoiler' information (see Wikipedia:Spoiler). Collapsible sections are useful in navboxes and infoboxes and are widely used outside the article namespace; in these instances, care should be taken to ensure that the content will still be acessible on devices which do not support JavaScript and/or CSS.
Infoboxes
See the HTML breaks problem.
Other languages
Non-English words or phrases should be encased in {{lang}}, which uses ISO639 language codes, thus:
{{lang|fr|Assemblée nationale}}
which renders as
- Assemblée nationale.
Images
- Images should include alt text that acts as a substitute for the image for blind readers, search-spiders and other non-visual users. This guideline includes alt text for LaTeX-formatted equations in <math> mode.
- Images should contain a caption, either using the built in image syntax or a secondary line of text. The caption should concisely describe the meaning of the image, the essential information it is trying to convey.
- Where possible, any charts or diagrams should have a text equivalent, or should be well-described so that users who can't see the image can gain some understanding of the concept.
- Detailed image descriptions, where not appropriate for an article, should be placed on the image description page, with a note saying that activating the image link will lead to a more detailed description.
- Images should be inside the section they belong to (after the heading and after any links to other articles), and not in the heading.
- When possible, do not force oversizing of images that override the default user preferences. Some users need to configure their systems to display large text; forced large thumbnails can leave little width for text, making reading difficult.
- Do not place left-aligned images directly below third-level (
===) headings, as this can disconnect the heading from the text it precedes, when read with larger fonts. Instead, either right-align the image, remove it, or move it to another relevant location.
- For example, do not use:
=== Section 1b === [[Image:Image relating to section 1b.jpg|frame|left|Caption.]] First paragraph of section 1b.
Styles and markup options
In general, articles should use wikimarkup in preference to the limited set of allowed HTML elements. In particular, do not use the HTML style tags <i> and <b> to format text; it is preferable to use Wiki markup '' or ''', or logical style tags. Of course there are natural exceptions: it may be beneficial to use <u></u> tags to indicate something like an example of an unclickable link. The <font> tag should also be avoided in article text; use logical style tags like <em>, <code>, or <strong> to emphasise semantic differences. Use <small> and <big> semantic tags to change font size, rather than setting it explicitly with the font-size= style attribute.
In general, styles for tables and other block-level elements should be set using CSS classes, not with inline style attributes. This is because the site-wide CSS is more carefully tested to ensure compatibility with a wide range of browsers; it also creates a greater degree of professionalism by ensuring a consistent appearance between articles. Deviations from standard conventions are acceptable where they create a semantic distinction (for instance, the infoboxes and navigational templates relating to The Simpsons use a yellow colour-scheme instead of the customary mauve, to tie in with the dominant colour in the series) but should not be used gratuitously.
Users with limited CSS/JavaScript support
Wikipedia articles should be accessible to readers using browsers and devices which have limited or no support for JavaScript or Cascading Style Sheets. At the same time, it is recognised that it is impossible to provide the same quality of appearance to such users without unnecessarily avoiding features that would benefit users with more capable browsers. As such, features which would cause content to be hidden or corrupted when CSS and/or JavaScript is unavailable must not be used. This includes techniques such as the hiddenStructure method for hiding table content – which produces incomprehensible output without CSS – and some implementations of the NavFrame collapsing code – which can make content inaccessible without JavaScript support. However, consideration for users without CSS or JavaScript should extend mainly to making sure that their reading experience is possible; it is recognised that it will inevitably be inferior.
To accommodate these considerations, test any potentially disruptive changes with JavaScript and/or CSS disabled. In Firefox, this can be done easily with the WebDeveloper extension; JavaScript can be disabled in IE in the 'Options' screen. Be particularly careful with inline CSS effects, which are not supported by several browsers, media, and XHTML versions.
Keyboard shortcuts
- For more detail see Wikipedia:Keyboard shortcuts
Numerous keyboard shortcuts for common Wikipedia tasks exist by default. They can be disabled.
See also
- Web Accessibility Initiative (WAI)
- Wikipedia:Accessibility advocates
- Wikipedia:Using JAWS
- Wikipedia:WikiProject Accessibility
- Wikipedia:WikiProject Usability
References
- Clark, Joe (2003). Building Accessible Websites. New Riders Press. ISBN 0-7357-1150-X.
{{cite book}}: Cite has empty unknown parameter:|month=(help) - Pilgrim, Mark (2002). "Dive Into Accessibility: 30 days to a more accessible web site". Retrieved 2006-05-07.