Wikipedia:Manual of Style/Accessibility
 | This guideline is a part of the English Wikipedia's Manual of Style. Editors should generally follow it, though it is best treated with common sense, and exceptions may apply. Substantive edits to this page should reflect consensus. |
 | This page in a nutshell: Wikipedia pages should have clear formatting, descriptive links, and alternative text so that content is easy to navigate and accessible for all readers, including those with disabilities. |
Web accessibility is the goal of making web pages easier to navigate and read. Although primarily intended for disability support, it benefits all readers. The Web Content Accessibility Guidelines (WCAG) 2.2[a] provide the framework for the recommendations in this guideline. Adhering to these guidelines improves content navigation and enhances accessibility for all users, including individuals with disabilities.
Article structure
[edit]A standardized article structure improves accessibility by allowing users to anticipate the location of specific content on a page. For example, a blind user searching for disambiguation links will know that if none are found at the top of the page, they are not present, eliminating the need to read the entire page.
Headings
[edit]Headings should be descriptive and follow a consistent order, as outlined in the Manual of Style. They must be nested sequentially—beginning at level 2 (==) for the main headings, then level 3 (===), and so on. Level 1 headings, automatically reserved for the article title, should not appear within the article's body text. Skipping heading levels for emphasis disrupts the logical hierarchy and should be avoided. For editors using the source editor, a single newline beneath each heading is permissible.
| Correct | Random/chaotic | Skipping levels |
|---|---|---|
|
[Article lead here] |
[Article lead here] |
[Article lead here] |
Do not create pseudo-headings by misusing semicolon markup (;), which is reserved for description lists, and avoid using bold text for headings. Screen readers and other assistive technologies rely on proper heading markup for navigation. If the table of contents (TOC) is too large, use the {{TOC limit}} template to reduce the length of the TOC by hiding nested subsections, rather than a floating TOC. When {{TOC limit}} cannot be used due to lower-level headings elsewhere in the article, using bold text for sub-sub-sub headings is the least disruptive alternative for screen readers. However, pseudo-headings should be used only as a last resort.
| Acceptable | Incorrect |
|---|---|
|
[Article lead here] |
[Article lead here] |
Floating elements
[edit]In wikitext, floating elements (including images) should be placed inside the section they belong to rather than at the end of the preceding section. Although multiple images in a narrow text area can sometimes cause an image to shift into a later section, this does not pose an accessibility issue because screen readers read each image's alt= text at the point where it appears in the code.
Screen resolution
[edit]
Wikipedia articles should be accessible to readers using devices with small screens such as mobile devices, or to readers using monitors with a low resolution. On desktop, 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
[edit]By default, most screen readers do not indicate HTML attributes like presentational text attributes (bold, italic, underline, monospace, strikethrough), or even semantic text attributes (emphasis, importance, text deletion). As a result, strikethrough text is read normally along with other text. (Editors who use screen readers and participate in Wikipedia policy and deletion debates are advised to enable notifications about text attributes, as struck text is very common in Wikipedia-internal discussions.)
Since strikethrough is typically ignored by screen readers, its occasional use in articles (e.g., to show changes in a textual analysis) can cause accessibility problems and confusion if it is the only indication used. This applies to both the <s> and <del> elements (along with their corresponding <ins>, which are usually visually rendered as underlined), as well as templates that use them. Do not use strikethrough to object to content you believe is inappropriate or incorrect. Instead, comment it out using <!-- and -->, remove it entirely, or use an inline cleanup/dispute template and raise the issue on the talk page.
Screen readers have widely varying support for characters outside Latin-1 and Windows-1252, and it is not safe to assume how any given character in these ranges will be pronounced. If they are not recognized by the screen reader or speech synthesizer, they may be pronounced as a question mark or omitted entirely from the speech output.
- Provide a transliteration for all text in a non-Latin writing system where the non-Latin characters are important in the original context, such as names, places, or things. Transliteration can be created in templates using those that signify non-Latin-script languages (e.g.,
{{Langx|ru|text=пример|translit=prímer|translation=example}}and can also be created using {{Transliteration}}. These templates also offer other accessibility benefits (see § Other languages below). - Do not use symbols that will not be read out loud such as
♥(a heart symbol), or symbols which may be read incorrectly such as–(which may be read as "dash" instead of "minus"); instead, use images with appropriatealt=text.[1] - Symbols that cause problems for screen readers may already have templates created to produce an image and alt text. An example is the dagger template {{†}} (see Category:Single-image insertion templates for more).[needs update]
The sequence of characters must be sufficient to convey semantic aspects of the text (and, preferably, other similar forms of content); reliance on custom "special symbols" distinguishable only by CSS properties or wiki markup is not acceptable.