Wikipedia:Accessibility

Article on other languages:

del.icio.us del.icio.us
Digg Digg
Furl Furl
Reddit Reddit
Rojo Rojo
Add to OnlyWire
WP:ACCESS redirects here. This is a guide to editing articles for accessibility. For assistance with accessibility, see: Help:Accessibility. You may also be looking for Wikipedia:WikiProject Accessibility.
This guideline is a part of the English Wikipedia's Manual of Style. Editors should follow it, except where common sense and the occasional exception will improve an article. Before editing this page, please make sure that your revision reflects consensus.
Shortcuts:
WP:ACCESS
WP:ACCESSIBILITY
Style and formatting
Manual of Style and its subpages
Related policies and guidelines
Related help, tutorials and proposals
Related to specific cultures

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.

Contents

Article structure

Lead section

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.

Click "hide" to collapse the full details of these elements.

<!-- CORRECT STRUCTURE OF LEAD SECTION -->
{{otheruses}}
{{unreferenced}}
{{Foo bar Infobox|name=...}}
[[Image:...|Typical Foo bar]] or {{Foo bar Navigation}}
'''Foo bar''' ...
[table of contents]
== First section ==

  • Disambiguation links should be the first elements of the page, before any image or infobox; if a reader has reached the wrong page, they typically want to know that first. Text-only browsers and screen readers present the page sequentially. A "for topics of the same name ..." disambiguation link is sometimes put at the beginning of an article to link to another article discussing another meaning of the article title. Do not make this initial link a section. In such cases, the line should be italicized and indented using templates. A horizontal line should not be placed under this line. See also Wikipedia:Hatnote.
  • The maintenance tags should be below the disambiguation links. These tags inform the reader about the general quality of the article, and should be presented to the user before the article itself.
  • Infoboxes contain summary information or an overview relating to the subject of the article, and therefore should be put before any text. The primary difference between an infobox and a navigational box is the presence of parameters: a navigational box is exactly the same in all articles of the same topic, while an infobox has different contents in each article.
  • Images. An image's caption is part of the article text. If the article has disambiguation links (dablinks), then the introductory image should appear just before the introductory text. Otherwise a screen reader would first read the image's caption, which is part of the article's contents, then "jump" outside the article to read the dablink, and then return to the lead section, which is an illogical sequence.
  • Navigational templates (also called "navigational boxes") are a collection of links used in multiple related articles to facilitate navigation between those articles. Vertical navigational boxes, sometimes called "sidebars", and horizontal navigational boxes are sometimes placed in the lead, especially when no infobox is present. If an infobox is present, the navigation sidebar may be moved to either the top or bottom of any other section in the article.
  • Introductory text. As explained in more detail at Wikipedia:Lead section#Introductory text, all but the shortest articles should start with introductory text (the "lead"). The lead should establish significance, include mention of notable criticism or controversies, and be written in a way that makes readers want to know more. The appropriate length of the lead depends on that of the article, but should be no more than four paragraphs. The lead itself has no heading and, on pages with more than three headings, automatically appears above the table of contents, if present. See also Wikipedia:Guide to writing better articles#Lead section.
  • The table of contents (TOC) automatically appears on pages with more than three headings. Avoid floating the table of contents if possible, as it breaks the standard look of pages. If you must use a floated TOC, put it below the lead section in the wiki markup for consistency. Users of screen readers expect the table of contents to follow the introductory text; they will also miss any text placed between the TOC and the first heading.

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.
Heading use (and misuse) examples
Correct Random/chaotic Skipping levels
[Article lead here]
==Section== [level 2]
===Sub-section=== [3]
==Section== [2]
===Sub-section=== [3]
====Sub-sub-section==== [4]
==Section== [2]
[Article lead here]
====Section?==== [4]
===Section?=== [3]
==Section?== [2]
==Section?== [2]
====Section?==== [4]
===Section?=== [2]
[Article lead here]
[Level-2 section missing here]
===Section?=== [3]
==Section== [2]
[Level-3 sub-section missing here]
====Sub-section?==== [4]
==Section== [2]

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.

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.

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. Screen readers 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 Simpsons" will be read as "The", and a heading title of "hackers in popular culture" will be read as "hackers".
  • 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]]s will work).

Color

See Wikipedia:Colours#Using colours in articles

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:

  1. One is a good number.
  2. Two is a better number.
  1. Three is the best number in the world.
  1. 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.

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 navigation, series, and info boxes 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 style="text-align: " 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%"
| style="text-align: " bgcolor="#ccccff" | '''Title'''
|-
| [normal cell] || [normal cell]
|-
| [normal cell] || [normal cell]
|}

For example, see {{NavigationBox}}

Other languages

Main article: Template:Lang/doc#Rationale

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.

Infoboxes

Images

For more detail see Wikipedia:Manual of Style#Images
  1. Images should contain a caption, either using the built in image syntax or a secondary line of text. The caption should concisely describe any information contained in the image.
  2. 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.
  3. 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.
  4. Images should be inside the section they belong to (after the header and after any links to other articles), and not just before the header.
  5. 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.
  6. 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.

Style and markup

  1. Avoid inline CSS style= attributes where a similar common class is available, e.g. class="wikitable".
  2. Use CSS shorthand properties when possible (e.g., background versus background-color).
  3. Test inline CSS effects with disabled CSS. Inline CSS is not supported by several browsers, media, and XHTML versions.
  4. Do not use <font> tags or inline CSS to play with font sizes. If necessary, use <small> or <big>, which are also supported by Lynx to a certain degree (even nested).
  5. Do not use <font> tags to manipulate foreground colors, unless you also use legacy bgcolor= markup to set the background color. It is preferable to use simple logical style tags like <em>, <code>, or <strong> for semantical differences.
  6. Inline CSS is ideal for decorative purposes including decorative colors, but do not mix CSS with legacy markup: old browsers respect the legacy markup and ignore the CSS.
  7. Combining logical style tags with CSS colors is a good idea (depending on the colors for browsers supporting CSS).
  8. Do not use the physical style tags <u>, <i>, or <b>; it is preferable to use Wiki markup '' or ''', or logical style tags.
  9. Use common sense; a deprecated <u> could be perfectly okay if it is used to indicate something like an example of an unclickable link.

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

References

Notes

External links

Retrieved from "http://en.wikipedia.org/wiki/Wikipedia:Accessibility"

This article is from Wikipedia. All text is available under the terms of the GNU Free Documentation License.

Giant Panda

Mercedes Car
James Bond Guide
This site monitored by SitePinger.net