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 it is best treated with common sense, and occasional exceptions may apply. Any substantive edit to this page should reflect consensus. When in doubt, discuss first on the talk page.

Shortcuts MOS:ACCESS WP:ACCESSIBILITY

This page in a nutshell: Wikipedia pages should be easy to navigate and read for people with disabilities.

Web 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. We aim to adhere to Web Content Accessibility Guidelines 2.1, on which the following suggestions are based. Pages adhering to them are easier for everyone to read and edit.

A standardized structure of articles improves accessibility, because it enables users to expect contents to be in a specific part of the page. For example, if a blind user is searching for disambiguation links and doesn't find any at the top of the page, they will know that there aren't any and they don't have to read the whole page to find that out.

Standardization is already a habit on Wikipedia, thus the guidelines to follow are simply Wikipedia:Manual of Style/Layout and Wikipedia:Lead section § Elements of the lead.

Headings

Headings should be descriptive and in a consistent order as defined in the Manual of Style.

Nest headings sequentially, starting with level 2 (==), then level 3 (===) and so on. (Level 1 is the auto-generated page title.) Do not skip parts of the sequence, such as selecting levels for emphasis; this is not the purpose of headings.

For purposes of readability for editors with poor vision—in source editor only—a single blank line may be added beneath each heading, but not more than one; more than one blank line beneath a section heading will cause extra space to be visible on the rendered page. Consideration should also be given to how a single blank white line beneath section headings may appear on a small screen for a particular article, as many editors use mobile devices to edit, and having a single blank line beneath the heading may actually detract from the readability for these editors, for some articles.

Do not make pseudo-headings by abusing semicolon markup (reserved for description lists) and try to avoid using bold markup. Screen readers and other assistive technology can only use headings that have heading markup for navigation. If you want to reduce the size of the table of contents (TOC), use {{TOC limit}} instead. In cases where {{TOC limit}} cannot be used because of lower-level headings elsewhere in the article, then using bold for the sub-sub-sub headings causes the least annoyance for screen reader users. Using a pseudo heading at all means you have exhausted all other options. It is meant as a rarity.

Floating elementsedit

In the wikicode, floating elements (including images) should be placed inside the section they belong to; do not place the image at the end of the previous section. (Depending on platform, "stacking" of several images alongside a relatively small amount of text may cause a particular image to be pushed down to a later section. However, this is not an accessibility issue, as screen readers always read each image's alt= out at the point where the image is coded).

Resolutionedit

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.

By default, most screen readers do not indicate presentational text attributes (bold, italic, underline, monospace, strikethrough) or even semantic text attributes (emphasis, importance, text deletion), so struck-out text is read normally along with any other text. (Editors using screen readers who participate in Wikipedia policy and deletion debates are advised to turn on notifications about text attributes when doing so, as struck text is very common in Wikipedia-internal discussions.)

Since strikethrough is normally ignored by screen readers, its rare use in articles (e.g., to show changes in a textual analysis) will cause accessibility problems and outright confusion if it is the only indication used. This applies to both the <s> and <del> elements (along with their corresponding <ins>, usually visually rendered as underlined), as well as templates that use them. Do not use strikethrough to object to content you think is inappropriate or incorrect. Instead, comment it out with <!-- and -->, remove it entirely, or use an inline cleanup/dispute template, and raise the matter 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.

1. Provide a transliteration for all text in a non-Latin writing system where the non-Latin character is important in the original context such as names, places, things etc. This functionality is available in templates that signify non-Latin-script languages and can also be found in templates such as {{transl}}; these templates also have other accessibility benefits (see the "Other languages" section below).
2. Do not use possibly unpronounceable symbols such as ♥ (a heart symbol); use images with alt text instead.¹
3. 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.

Do not use techniques that require interaction to provide information, such as tooltips or any other "hover" text. Abbreviations are exempt from these requirements, so the {{abbr}} template (a wrapper for the <abbr> element) may be used to indicate the long form of an abbreviation (including an acronym or initialism).

Do not insert line breaks within a sentence, since this makes it harder to edit with a screen reader. A single line break may follow a sentence, which may help some editors.

Font sizeedit

Reduced or enlarged font sizes should be used sparingly, and are usually done with automated page elements such as headings, table headers, and standardized templates. Size changes are specified as a percentage of the original font size and not as an absolute size in pixels or point size. Relative sizes increase accessibility for visually impaired users by allowing them to set a large(r) default font size in their browser settings. Absolute sizes deny users such ability.

Avoid using smaller font sizes within page elements that already use a smaller font size, such as most text within infoboxes, navboxes, and references sections.^b This means that <small>...</small> tags, and templates such as {{small}} and {{smalldiv}}, should not be applied to plain text within those elements. In no case should the resulting font size of any text drop below 85% of the page's default font size. Note that the HTML <small>...</small> tag has a semantic meaning of fine print or side comments;² do not use it for stylistic changes.

Fractionsedit

Apart from the exceptions explained at WP:Manual of Style/Dates and numbers § Fractions, do not use precomposed fraction characters such as ½ (deprecated markup: ½ or ½). This is because some precomposed fractions may not work with screen readers or may be unreasonably difficult for readers with impaired vision to decipher. Use {{frac}} which produces fractions in the form 3⁄4. (For scientific and mathematical text, use {{sfrac}} which produces fractions in the form 3/4.)

By default, English Wikipedia articles state explicitly to the browser that they are written wholly in English. Text in a language other than English should be tagged as such, often with a template like {{lang}}. This wraps the text in an IETF language tag, which specifies the language and script. For example:

• N ''Assemblée nationale'' is simply italicized, and does not specify that it is French-language text. Most screen readers attempting to handle this will sound ridiculous or confusing.
• Y {{lang|fr|Assemblée nationale}} renders as Assemblée nationale, which is italicized by default and will allow screen readers to select a French-language voice.
• Y {{lang-fr|Assemblée nationale}} → French: Assemblée nationale – This is similar to the above, but uses a template specifically designed for French-language text.

Rationale: Among other uses, specifying the language of text with {{lang}} allows speech synthesizers to select a voice capable of correctly reading out the text.³

IETF language tags specify the language of text according to the ISO 639 specification, but also which script is being used to write the language:

• Y {{lang|sr-Cyrl|Народна скупштина}} → Народна скупштина
• Y {{lang|sr-Latn|Narodna skupština}} → Narodna skupština – Serbian can typically be written using either the Latin or Cyrillic script.
• N {{lang|ja|Kokumin gikai}} – By default, it is expected that Japanese text has been written using the native writing system, whose rules may treat some characters differently.
• Y {{lang|ja-Latn|Kokumin gikai}} specifies Japanese written with the Latin alphabet—e.g. rōmaji.
• Y {{transl|ja|Kokumin gikai}} is equivalent to the above.

Without specifying a script, IETF tags assume the most common script used to write a given language. Therefore, transliterations should specify use of Latin script by appending -Latn to the language code, or by using the equivalent {{transl}} template. Wikipedia has a number of language-specific templates such as {{lang-zh}} and {{nihongo}}, which provide language-specific functionality to editors, such as the ability to easily display several transliterations with one template. Not every language has its own template, but using one may be helpful to streamline wikitext, instead of cluttering paragraphs with instances of {{lang}} and {{transl}}.

It is usually unnecessary to specify italics in addition to the {{lang}} or {{lang-xx}} templates, which italicize text using the Latin alphabet by default. If text should not be italicized, such as with the names of places or people, the parameter |italic=no may be added.^c As outlined in MOS:FOREIGN, text using a non-Latin script should almost never be italicized or bolded.

Phonetic transcriptions or pronunciation guides should use {{IPA}}, {{respell}}, or another suitable template. {{PIE}} is used for Proto-Indo-European.

1. Create good link descriptions, especially for external links (avoid "click here!", "this").⁴⁵
2. Do not use Unicode characters as icons; use an icon with alt text instead. For example, a character like "→" cannot be reproduced into useful text by some screen readers.
3. Use Template:Visible anchors where Destination highlighting helps the partially sighted to locate more easily the link target on the destination page.

Colors are most commonly found in Wikipedia articles within templates and tables. For technical assistance on how colors are used, see Help:Using colors.

Articles (and other pages) that use color should keep accessibility in mind, as follows:

• Ensure that color is not the only method used to communicate important information. Especially, do not use colored text or background unless its status is also indicated using another method, such as an accessible symbol matched to a legend, or footnote labels. Otherwise, blind users or readers accessing Wikipedia through a printout or device without a color screen will not receive that information.
• Links should clearly be identifiable as a link to our readers.
• Some readers of Wikipedia are partially or fully color-blind or visually impaired. Ensure the contrast of the text with its background reaches at least Web Content Accessibility Guidelines (WCAG) 2.0's AA level, and AAA level when feasible (see WCAG's "Understanding SC 1.4.3: Contrast (Minimum)"). To use named CSS colors for text on a white background, refer to Wikipedia:Manual of Style/Accessibility/CSS colors for text on white for recommended colors. For other usage, here is a selection of tools that can be used to check that the contrast is correct:
  • You can use a few online tools to check color contrasts, including: the WebAIM online contrast checker, or the WhoCanUse site, or Snook's Color Contrast Check.
    • Several other tools exist on the web, but check if they are up-to-date before using them. Several tools are based on WCAG 1.0's algorithm, while the reference is now WCAG 2.0's algorithm. If the tool doesn't specifically mention that it is based on WCAG 2.0, assume that it is outdated.
  • The Wikimedia Foundation Design team has provided a color palette with colors being marked towards level AA conformance. It is used for all user-interface elements across products and in the main Wikimedia themes, desktop and mobile. However, it does not consider linked text.
  • The table at Wikipedia:Manual of Style/Accessibility/Colors shows the results for 14 hues of finding the darkest or lightest backgrounds that are AAA-compliant against black text, white text, linked text and visited linked text.
  • Google Chrome has a color contrast debugger with visual guide and color-picker.
  • The downloadable software Color Contrast Analyser enables you to pick colors on the page, and review their contrast thoroughly. However, be sure to only use the up-to-date "luminosity" algorithm, and not the "color brightness/difference", which is outdated.
• Additional tools can be used to help produce graphical charts and color schemes for maps and the like. These tools are not accurate means to review contrast accessibility, but they can be helpful for specific tasks.
  • Paletton (previously Color Scheme Designer) helps to choose a good set of colors for a graphical chart.
  • Color Brewer 2.0 provides safe color schemes for maps and detailed explanations.
  • Light qualitative color scheme provides a set of nine colors that work for color-blind users and with black text labels (among other palettes).
  • There are some tools for simulating color-blind vision: Toptal ColorFilter (webpage analysis) and Coblis Color-blindness Simulator (local file analysis). There are also browser extensions for webpage analysis: NoCoffee (Firefox)
  • A very simple open-source tool that can be helpful for choosing contrasting colors is Color Oracle, a "free color blindness simulator for Windows, Mac and Linux". It lets you view whatever is on your screen as it would be seen by someone with one of three types of color-blindness or in greyscale.
• If an article overuses colors, and you don't know how to fix it yourself, you can ask for help from other editors. Place {{Overcolored}} or {{Overcoloured}} at the top of the article.

Contrast ratios of web safe colours vs black (top row) and white (bottom) or vice versa, with contours at 3 (red), 4.5 (green) and 7 (blue)

Listsedit

Do not separate list items by leaving empty lines or tabular column breaks between them. This includes items in a description list (a list made with a leading semicolon or colon, which is also how most talk-page discussions are formatted) or an ordered list or unordered list. Lists are meant to group elements that belong together, but MediaWiki will interpret the blank line as the end of one list and start a new one. Excessive double line breaks also disrupt screen readers, which will announce multiple lists when only one was intended, and therefore may mislead or confuse users of these programs. Such improper formatting can also more than triple the length of time it takes them to read the list.

Likewise, do not switch between initial list marker types (colons, asterisks or hash signs) in one list. When indenting in reply to a post that starts with any mix of colons and asterisks and sometimes hash signs, it is necessary to copy whatever series of those characters was used above, and append one more such character. Alternatively, simply outdent and start a new discussion (i.e., a new HTML list).

Examples:

YIn a discussion, do this,

* Support. I like this idea. —User:Example 
** Question: What do you like about it? —User:Example2
*** It seems to fit the spirit of Wikipedia. —User:Example

Y Or, in an unbulleted discussion, this,

: Support. I like this idea. —User:Example 
:: Question: What do you like about it? —User:Example2
::: It seems to fit the spirit of Wikipedia. —User:Example

Y Suppressing the bullet on a reply is also acceptable,

* Support. I like this idea. —User:Example 
*: Question: What do you like about it? —User:Example2
*:: It seems to fit the spirit of Wikipedia. —User:Example

N But don't switch type from bullet list to description list,

* Support. I like this idea. —User:Example 
:: Question: What do you like about it? —User:Example2

N nor switch from bullet list to mixed type,

* Support. I like this idea. —User:Example 
:* Question: What do you like about it? —User:Example2

N Leaving blank lines between list items is generally bad practice,

* Support. I like this idea. —User:Example

** Question: What do you like about it? —User:Example2

N As is jumping more than one level,

* Support. I like this idea. —User:Example
*** Question: What do you like about it? —User:Example2

N This is generally discouraged :

: Support. I like this idea. —User:Example 
:* Question: What do you like about it? —User:Example2

This injection of a bullet unnecessarily adds to list complexity and makes people more likely to use the wrong indentation levels in replies.

Multiple paragraphs within list itemsedit

Normal MediaWiki list markup is unfortunately incompatible with normal MediaWiki paragraph markup.

Y To put multiple paragraphs in a list item, separate them with {{pb}}:

* This is one item.{{pb}}This is another paragraph within this item.
* This is another item.

Y This can also be done with explicit HTML markup for paragraphs (note the closing </p> tag):

* This is one item.<p>This is another paragraph within this item.</p>
* This is another item.

Y In both cases, this must be done on a single code line. However, you can optionally use the trick of wrapping a code line break in an HTML comment (which suppresses it as an output line break), to separate paragraphs better in code view:

* This is one item.<!--
--><p>This is another paragraph within this item.</p>
* This is another item.

Y This technique can be used for various forms of block-inclusion within a list item (because list items are technically block elements, which can contain other block elements):

* This is one item.<!--
--><p>This is another paragraph within this item, and we're going to quote someone:</p><!--
-->{{talk quote block|Imagine a world in which every single person on the planet is given free access to the sum of all human knowledge.|Jimbo}}<!--
--><p>This is a closing paragraph within the same list item.</p>
* This is another item.

Be aware that not every fancy template can be used in this manner (e.g. some decorative quotation templates are table-based, and the MediaWiki parser will not handle such markup as being inside a list item).

See also WP:Manual of Style/Glossaries for rich but accessible markup of complex description/definition/association lists.

N Do not use line breaks to simulate paragraphs, because they have different semantics:

* This is one item.<br />This is the same paragraph, with a line break before it.
* This is another item.

Line-break tags are for wrapping within a paragraph, such as lines of a poem or of a block of source code. See also the <poem> and <syntaxhighlight> MediaWiki tags.

N Definitely do not attempt to use a colon to match the indentation level, since (as mentioned above) it produces three separate lists:

* This is one item.
: This is an entirely separate list.
* This is a third list.

Y Alternatively, you can use one of the HTML list templates to guarantee grouping. This is most useful for including block elements, such as formatted code, in lists:

{{bulleted list
|1=This is one item:
<pre>
This is some code.
</pre>
This is still the same item.
|2=This is a second item.
}}

But this technique is not used on talk pages.

Indentationedit

An accessible approach to indentation is the template {{block indent}} for multi-line content; it uses CSS to indent the material. For single lines, a variety of templates exist, including {{in5}} (a universal template, with the same name on all Wikimedia sites); these indent with various whitespace characters. Do not abuse the <blockquote>...</blockquote> element or templates that use it (such as {{blockquote}} AKA {{quote}}) for visual indentation; they are only for directly quoted material. The {{block indent}} generic alternative was created for such non-quote cases, so please use it.

A colon (:) at the start of a line marks that line in the MediaWiki parser as the <dd> part of an HTML description list (<dl>).^d The visual effect in most Web browsers is to indent the line. This is used, for example, to indicate replies in a threaded discussion on talk pages. However, this markup alone is missing the required <dt> (term) element of a description list, to which the <dd> (description/definition) pertains. As can be seen by inspecting the code sent to the browser, this results in broken HTML (i.e. it fails validation⁶). The result is that assistive technology, such as screen readers, will announce a description list that does not exist, which is confusing for any visitor unused to Wikipedia's broken markup. This is not ideal for accessibility, semantics, or reuse, but is currently commonly used, despite the problems it causes for users of screen readers.

Blank lines must not be placed between colon-indented lines of text – especially in article content. This is interpreted by the software as marking the end of a list and the start of a new one.

If space is needed, there are two approaches, which will have different results for screen readers:

The first is to add a blank line with the same number of colons on it as those preceding the text above and below the blank line. This is appropriate when two editors are making comments immediately after each other at the same indentation level. For instance:

: I completely agree. —User:Example
:
: I'm unconvinced. Is there a better source available? –User:Example2

This will tell the screen reader that this is two list items (the blank one will be ignored).

The second approach, for when the material is meant to be a single comment (or other list item, e.g. in article text) is to use new-paragraph markup on the same output line (see previous section for advanced techniques in this, to include complex content blocks):

: Text here.{{pb}}More text. —User:Example3

To display a mathematical formula or expression on its own line, it is recommended that <math display="block">1 + 1 = 2</math> be used instead of :<math>1 + 1 = 2</math>.

Vertical listsedit

Bulleted vertical listsedit

For bulleted vertical lists, do not separate items by leaving blank lines between them. Instead, use the {{pb}} template or <p> HTML markup. (A blank line before the start of a list, or after the end of the list, causes no problems.)

The problem with blank lines in the middle of a list is that, if list items are separated by more than one line break, the HTML list will be ended before the line break, and another HTML list will be opened after the line break. This effectively breaks what is seen as one list into several smaller lists for those using screen readers. For example, for the coding:

* White rose
* Yellow rose

* Pink rose

* Red rose

the software partially suppresses line spaces and therefore it looks like this:

• White rose
• Yellow rose

• Pink rose

• Red rose

but will be read by a screen reader as: "List of 2 items: (bullet) White rose, (bullet) Yellow rose, list end. List of 1 items: (bullet) Pink rose, list end. List of 1 items: (bullet) Red rose, list end."

Do not separate list items with line breaks (<br />). Use {{plainlist}} / {{unbulleted list}} if the list is to remain vertical; or consider {{flatlist}} / {{hlist}} if the list could be better rendered horizontally (inline) as described in the following two sections.

Unbulleted vertical listsedit

For unbulleted lists running down the page, the templates {{plainlist}} and {{unbulleted list}} are available, to improve accessibility and semantic meaningfulness by marking up what is clearly a list rather than including <br /> line breaks, which should not be used—see above. They differ only in the wiki-markup used to create the list. Note that because these are templates, the text of each list item cannot contain the vertical bar symbol (|) unless it is replaced by {{!}} or is contained within <nowiki>...</nowiki> tags. Similarly it can't contain the equals sign (=), unless replaced with {{=}} or contained within <nowiki>...</nowiki>, though you can bypass this by naming the parameters (|1=, |2= etc.). If this becomes too much of a hassle, you may be able to use the variant with {{endplainlist}} instead. Inside a reference, you may need {{unbulleted list citebundle}} instead.