Wikipedia:Accessibility

Jump to: navigation, search

Template:Style-guide

Accessibility is the practice of making web pages easier to navigate and read. It is intended to assist those with disabilities, but it can be helpful to all readers. Articles adhering to the following guidelines are easier to read and edit by those Wikipedians.

Wikipedia needs you!
Do you have accessibility problems
in Wikipedia? Please, tell us!

Article structure

Lead section

  • 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 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.
  • The lead section is usually composed of several elements, including disambiguation links, images, infoboxes and navigation boxes. These (optional) elements should be in the following order:
<!-- CORRECT STRUCTURE OF LEAD SECTION -->
{{otheruses}}

{{unreferenced}}

{{Foo bar Infobox|name=...}}
[[Image:...|Typical Foo bar]]

'''Foo bar''' ...

{{Foo bar Navigation}}

== First section ==
  • Disambiguation links should be the first elements of the page, before any image or infobox. A text only browser or screen reader presents the page sequentially, and otherwise the dablink will be read between the image and the lead section. For example:
<!-- WRONG CODE -->
[[Image:...|Typical Foo bar]]

{{otheruses}}

'''Foo bar''' ...

The above code is wrong because, although in a graphic browser it will be read OK, a screen reader will start reading the article (the image caption), later it will be disrupted by the disambiguation link, and later it will continue reading the article. Instead, it should be:

<!-- CORRECT CODE -->
{{otheruses}}

[[Image:...|Typical Foo bar]]

'''Foo bar''' ...

This code will be both readable in a graphic browser and by a screen reader.

  • 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 are a summary of the article, and therefore should be put before any text. A 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.
  • Navigational boxes are a collection of links to related articles of the same topic. For the same reason as avoiding the floating TOC, they should be just after the lead section so a wikipedian using a screen reader can jump to the table of contents without reading the whole navigational text.

Headings

  • Headings should be descriptive and in a consistent order (See also — References — Further reading — External links).
  • Avoid using heading titles with the same name as one of the form names on the page, like "search" or "go".
  • 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 link to other article), and not just before the header for similar reasons.

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.
  • 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.
  • 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.

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

  • Ensure that color is not the only way used to convey important information. Especially, do not use colored text unless its status is also indicated using another method such as italic emphasis or footnote labels. Otherwise blind users or readers accessing Wikipedia through a printout or device without a color screen will not receive that information.
  • Many readers of Wikipedia may be partially or fully color blind. Ensure that the color combinations used in Wikipedia (infoboxes, navigational boxes, graphs, etc.) have an adequate contrast. Use a color scheme generator to select the colors, and tools for simulating colorblind vision (colorfilter.wickline.org or vischeck.com) to check the result.
  • Web pages can be checked on-line by the developers with AccessColor, which analyzes the HTML source for a web page and the Cascading Style Sheets associated, and then calculates the colour contrast and color brightness between the text and background colours to check that they conform with WCAG 1.0.
  • Suitable colour contrast for people with vision impairments, including colour blindness, can be tested with the Colour Contrast Analyser that uses the draft algorithms from the W3C.

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

{| summary="A description of the data to be found in the table."
|+ [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].
Summary ( summary="…")
The summary can provide a longer description of the table's purpose and structure for non-visual browsers [2].
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 [3].

Voice browsers might read aloud this data table in the following order [4]:

Caption: [caption text]
Summary: [summary 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:

{| summary=""
|+ [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.

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 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}}

Infoboxes

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.

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 vs. background-color).
  3. Test inline CSS effects with disabled CSS. Inline CSS isn't supported by several browsers, media, and XHTML versions.
  4. Don't use <font> tags or inline CSS to play with font sizes. If really necessary use <small> or <big> also supported by Lynx to a certain degree (even nested).
  5. Don't use <font> tags to manipulate foreground colors, unless you also use legacy bgcolor= markup to set the background color. Better 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 then don't 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 (of course depending on the colors for browsers supporting CSS).
  8. Don't use the physical style tags <u>, <i>, or <b>, better use Wiki markup '' or ''', or logical style tags.
  9. Use common sense; a deprecated <u> could be perfectly okay if it's used to indicate something like an example of un-clickable 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

  • Clark, Joe (2003). Building Accessible Websites. New Riders Press. ISBN 0-7357-1150-X.

External links

de:Wikipedia:Barrierefreiheit he:ויקיפדיה:נגישות it:Wikipedia:Accessibilità del contenuto


Linked-in.jpg