විකිපීඩියා:රචනාකරණ ශෛලිය පිළිබඳ මාර්ගෝපදේශ/Accessibility සඳහා මුලාශ්‍රය නරඹන්න

{{short description|Wikipedia accessibility guideline}}
{{hatnote|This is a guide to editing pages for accessibility. For the project, see [[Wikipedia:WikiProject Accessibility]]}}
{{redirect|WP:ACCESS|access keys|Wikipedia:Keyboard shortcuts|access to editing privileges|Wikipedia:User access levels|accessibility of content|Wikipedia:Make technical articles understandable|accessibility of sources|Wikipedia:Published}}
{{ඉංග්‍රීසි ව්‍යාපෘතියේ සිට ආයාත කළ පිටුව}}
{{MoS guideline|MOS:ACCESS|WP:ACCESSIBILITY}}
{{Nutshell|Wikipedia pages should be easy to navigate and read for people with disabilities.}}
{{Style |content}}
{{Wikipedia:WikiProject Accessibility/Navigation menu |articles}}

[[Web accessibility]] is the goal of making web pages easier to navigate and read. While this is primarily intended to assist those with [[Disability|disabilities]], it can be helpful to all readers. We aim to adhere to [[Web Content Accessibility Guidelines]] 2.1{{Efn|The previous version, WCAG 2.0, is also an [[International Organization for Standardization|ISO]] standard, ISO/IEC 40500:2012.}} on which the following suggestions are based. Pages adhering to them are easier to read and edit for everyone.

On 14 January 2006, the Board of the Wikimedia Foundation passed the following [[wmf:Resolution:Nondiscrimination|nondiscrimination resolution]]: {{tq|"The Wikimedia Foundation prohibits discrimination against current or prospective users and employees on the basis of race, color, gender, religion, national origin, age, disability, sexual orientation, or any other legally protected characteristics. The Wikimedia Foundation commits to the principle of equal opportunity, especially in all aspects of employee relations, including employment, salary administration, employee development, promotion, and transfer"}}. The WMF asserts that its policies {{tq|"may not be circumvented, eroded, or ignored by Wikimedia Foundation officers or staff nor local policies of any Wikimedia project"}}.

== Article structure ==

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 {{section link|Wikipedia:Lead section|Elements of the lead}}.

=== Headings ===

{{Shortcut|MOS:GOODHEAD|MOS:BADHEAD|MOS:SPACEUNDERHEADING}}

Headings should be descriptive and in a consistent order as defined in the [[MOS:ORDER|Manual of Style]].

Nest headings sequentially, starting with level 2 (<code>==</code>), then level 3 (<code>===</code>) 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 [[Help:Wikitext|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. 

{| class="wikitable"
|+ style="padding-top: 10px;" | Examples of correct and incorrect use of nested headings
|-
! scope="col" style="background: PaleGreen;" | Correct
! scope="col" style="background: Pink;" | Random/chaotic
! scope="col" style="background: Pink;" | Skipping levels
|- style="vertical-align: top;"
| style="width: 33%;" |
<poem>
''[Article lead here]''
<code>==Section==</code> ''[level 2]''
<code>===Sub-section===</code> ''[3]''
<code>==Section==</code> ''[2]''
<code>===Sub-section===</code> ''[3]''
<code>====Sub-sub-section====</code> ''[4]''
<code>==Section==</code> ''[2]''</poem>
| style="width: 33%;" |
<poem>
''[Article lead here]''
<code>====Section'''?'''====</code> ''[4]''
<code>===Section'''?'''===</code> ''[3]''
<code>==Section'''?'''==</code> ''[2]''
<code>==Section'''?'''==</code> ''[2]''
<code>====Section'''?'''====</code> ''[4]''
<code>===Section'''?'''===</code> ''[3]''</poem>
| style="width: 33%;" |
<poem>
''[Article lead here]''
''[Level-2 section missing here]''
<code>===Section'''?'''===</code> ''[3]''
<code>==Section==</code> ''[2]''
''[Level-3 sub-section missing here]''
<code>====Sub-section'''?'''====</code> ''[4]''
<code>==Section==</code> ''[2]''</poem>
|}

{{Shortcut|MOS:PSEUDOHEAD}}
{{Anchor|Pseudo-headings}}

Do not make pseudo-headings by abusing semicolon markup (reserved for [[MOS:DEFLIST|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 {{t|TOC limit}} instead. In cases where {{t|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.

{| class="wikitable"
|+ style="padding-top: 10px;" | Examples of acceptable and incorrect use of pseudo-headings and description lists
|-
! scope="col" style="background: PaleGreen;" | Acceptable
! scope="col" style="background: Pink;" | Incorrect
|- style="vertical-align: top;"
| style="width: 50%;" |
<poem>
''[Article lead here]''
<code>==Section==</code> ''[level 2]''
<code>===Sub-section===</code> ''[3]''
<code><nowiki>'''Pseudo-heading'''</nowiki></code>
<code>==Section==</code> ''[2]''
<code>===Sub-section===</code> ''[3]''
<code>====Sub-sub-section====</code> ''[4]''
<code><nowiki>;A term followed by</nowiki></code>
<code><nowiki>:at least one definition or at least one description list item</nowiki></code>
<code><nowiki>:and additional optional items, forming a list</nowiki></code>
</poem>
| style="width: 50%;" |
<poem>
''[Article lead here]''
<code>==Section==</code> ''[level 2]''
<code>===Sub-section===</code> ''[3]''
<code><nowiki>;Pseudo-heading</nowiki></code>
<code>==Section==</code> ''[2]''
<code>===Sub-section===</code> ''[3]''
<code><nowiki><small>==Sub-sub-section==</small></nowiki></code> ''[2]''</poem>
|}

=== Floating elements<span class="anchor" id="FLOAT"></span> ===

{{Shortcut|MOS:ACCESS#FLOAT}}
{{seealso|Wikipedia:Manual of Style/Images#Location}}
In the wikicode, floating elements (including images) should be placed {{em|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 <code>alt=</code> out at the point where the image is ''coded''.)

=== Resolution ===

{{Shortcut|MOS:RESOL}}

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 [[MOS:SANDWICH|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 ==

{{Shortcut|MOS:NOSTRIKE|MOS:NOSYMBOLS}}
{{See also|Wikipedia:Manual of Style/Text formatting}}
By default, most [[screen reader]]s 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 {{tag|s|o}} and {{tag|del|o}} elements (along with their corresponding {{tag|ins|o}}, 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 <code><nowiki><!--</nowiki></code> and <code><nowiki>--></nowiki></code>, remove it entirely, or use an [[Wikipedia:Template index|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.
# 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 {{tl|transl}}; these templates also have other accessibility benefits (see the [[#Other languages|"Other languages" section]] below).
# Do not use possibly unpronounceable symbols such as ♥ (a [[Heart (symbol)|heart symbol]]); use images with alt text instead.<ref>{{Cite web | url = http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F26.html| title = F26: Failure of Success Criterion 1.3.3 due to using a graphical symbol alone to convey information| work = Techniques for WCAG 2.0 | accessdate=1 January 2011|publisher = [[World Wide Web Consortium]]}}</ref>
# 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 {{tl|†}} (see [[:Category:Single-image insertion templates]] for more).

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.

{{Shortcut|MOS:NOHOVER|MOS:NOTOOLTIPS}}
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 {{tlx|abbr}} template (a wrapper for the {{tag|abbr|o}} 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 size ===

{{main|Wikipedia:Manual of Style/Text formatting#Font size}}
{{Shortcut|MOS:SMALL|MOS:SMALLTEXT}}
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 {{em|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 [[Wikipedia:Manual of Style/Infoboxes|infoboxes]], [[Wikipedia:Navigation template|navboxes]], and [[Wikipedia:Manual of Style/Layout#Notes and references|references sections]].{{efn|1=The general font size for infoboxes and navboxes is 88% of the page's default. The general font size for reference sections is 90% of the page's default. Additional values can be found at [[MediaWiki:Common.css]].}} This means that {{tag|small}} tags, and templates such as {{tlx|small}} and {{tlx|smalldiv}}, should not be applied to [[plain text]] within those elements. In no case should the resulting font size of any text drop below about 85% of the page's default font size. Note that the HTML {{tag|small}} tag has a semantic meaning of [[fine print]] or side comments;<ref>https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-small-element</ref> do not use it for stylistic changes.<!-- Replicated at Wikipedia:Manual_of_Style/Text_formatting#Font_size -->

== Other languages ==

{{shortcut|MOS:OTHERLANG|MOS:LANG}}
{{Main|Template:Lang/doc#Rationale}}
{{See also|Wikipedia:Manual of Style#Foreign terms|Wikipedia:Manual of Style/Text formatting#Foreign terms|Wikipedia:Manual of Style/Links#Interwiki links|Category:Wikipedia multilingual support templates}}

Non-English words or phrases should be encased in {{tl|lang}}, which uses [[ISO 639]] language codes, thus:

{{tlx|lang|fr|Assemblée nationale}}

which renders as:

{{lang|fr|Assemblée nationale}}

or {{tlx|lang-fr|Assemblée nationale}}

which renders as:

{{lang-fr|Assemblée nationale}}.

{{strong|Rationale}}: {{tnull|lang}} enables speech synthesizers to pronounce the text in the correct language.<ref>[http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H58 H58: Using language attributes to identify changes in the human language], Techniques for WCAG 2.0, W3C, accessibility level: AA.</ref> It has many other uses; see {{section link|Template:Lang/doc|Rationale}} for a comprehensive list of benefits.

It is not necessary nor desirable to wrap these constructions in italics markup; the {{tlx|lang}} and {{tlx|lang-xx}} templates already auto-italicize. If text should not be italicized—such as the names of places or people—it is possible to add {{code|<nowiki>italic=no</nowiki>}} to override the default behaviour.{{efn|Further details on this usage are available on the template documentation for {{tl|lang}}.}}

Note that {{strong|[[transliteration]]s should instead use {{tl|transl}}}} and pronunciations should use {{tl|IPA}}, {{tl|respell}}, or a related template. {{tl|PIE}} is for [[Proto-Indo-European]].

Wikipedia also has a number of [[:Category:Wikipedia multilingual support templates|language-specific templates]], such as {{tl|lang-zh}} and {{tl|nihongo}}, which give editors language-specific template parameters, such as the option to input different transliteration methods. Though not every language has its own template, it may be preferable to use these templates to streamline wikitext, instead of stacking several instances of {{tl|lang}} and {{tl|transl}}.

== Links ==

# Create good link descriptions, especially for external links (avoid "[[click here]]!", "[http://example.com/ this]").<ref>{{Cite web | url = http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G91.html | title = G91: Providing link text that describes the purpose of a link| work = Techniques for WCAG 2.0 | accessdate = 1 January 2011| publisher = [[World Wide Web Consortium]]}}</ref><ref>{{Cite web | url = http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F84 | title = F84: Failure of Success Criterion 2.4.9 due to using a non-specific link such as "click here" or "more" without a mechanism to change the link text to specific text| work = Techniques for WCAG 2.0 | publisher = [[World Wide Web Consortium]] | accessdate = 1 January 2011}}</ref>
# 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 reader]]s.
#Use [[Template:Visible anchor]]s where [[Template:Visible anchor#Destination highlighting|Destination highlighting]] helps the partially sighted to locate more easily the link target on the destination page. <!-- {{discuss|Accessibility issue: Use of Visible Anchors to help the partially sighted}} -->

== Color <span id="Colour"></span>==

{{anchor|Using colors in articles|reason=Original section name; might still have incoming links.}}
{{shortcut|MOS:COLOR|MOS:COLOUR|MOS:CONTRAST}}
{{Redirect|WP:Color|technical help on using colors|Help:Using colors|and|Help:Link color|the WikiProject on color|Wikipedia:WikiProject Color}}
{{About|the use of colors in articles (though the advice on contrast ratios is applicable more generally)|the civility essay dealing with colors|Wikipedia:Don't edit war over the color of templates|section=yes}}

[[File:Example of team color problem on Clive Churchill article.png|thumb|alt=Two screenshots of the same highly textual user interface. The top one uses red, green, and blue; the bottom one uses nearly the same color for red and green, so that the red text becomes nearly invisible in its green background.|A pair of screenshots showing the effects of red/green color-blindness on legibility]]

'''Colors''' are most commonly found in Wikipedia articles within [[Wikipedia:Template namespace|templates]] and [[Wikipedia:Manual of Style/Tables|tables]].  {{Crossref|printworthy=y|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 [[#Text|accessible symbol]] matched to a legend, or [[Help:Footnotes|footnote labels]]. Otherwise, [[Blindness|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 blindness|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 [https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html "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 [https://webaim.org/resources/contrastchecker/ contrast checker], or the [https://whocanuse.com/ WhoCanUse] site, or [https://snook.ca/technical/colour_contrast/colour.html 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 [https://design.wikimedia.org/style-guide/visual-style_colors.html 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 [https://a11ywins.tumblr.com/post/167324368213/google-chromes-color-contrast-debugger color contrast debugger] with visual guide and color-picker.
** The downloadable software [https://www.tpgi.com/color-contrast-checker/ 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.
** [https://paletton.com/ Paletton] (previously Color Scheme Designer) helps to choose a good set of colors for a graphical chart.
** [https://colorbrewer2.org/ Color Brewer 2.0] provides safe color schemes for maps and detailed explanations.
** [https://personal.sron.nl/~pault/#fig:scheme_light 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: [https://www.toptal.com/designers/colorfilter Toptal ColorFilter] (webpage analysis) and [https://www.color-blindness.com/coblis-color-blindness-simulator/ Coblis Color-blindness Simulator] (local file analysis). There are also browser extensions for webpage analysis: [https://addons.mozilla.org/en-US/firefox/addon/nocoffee/ NoCoffee] (Firefox)
** A very simple open-source tool that can be helpful for choosing contrasting colors is [https://colororacle.org/ 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 {{tl|Overcolored}} or {{tl|Overcoloured}} at the top of the article.
{{WCAG_web_safe_contrast_ratio.svg}}

== Block elements ==

=== Lists ===

{{shortcut|MOS:INDENTMIX}}
{{see also|Help:List|Wikipedia:Manual of Style#Bulleted and numbered lists|Wikipedia:Manual of Style/Lists#List styles}}

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 [[List (HTML)|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 reader]]s, 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 [[WP:OUTDENT|outdent]] and start a new discussion (i.e., a new HTML list). 

For example, in a discussion, do {{tick}} this best practice:

<syntaxhighlight lang="wikitext">
* 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 
</syntaxhighlight>

or {{tick}}, in an unbulleted discussion:

<syntaxhighlight lang="wikitext">
: 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 
</syntaxhighlight>

This {{tick}} is also acceptable practice (to suppress the bullet on a reply):

<syntaxhighlight lang="wikitext">
* 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 
</syntaxhighlight>

But {{xmark}} don't do this (switch type from bullet list to description list):

<syntaxhighlight lang="wikitext">
* Support. I like this idea. —User:Example 
:: Question: What do you like about it? —User:Example2 
</syntaxhighlight>

nor {{xmark}} this (switch type from bullet list to description list):

<syntaxhighlight lang="wikitext">
* Support. I like this idea. —User:Example 
:* Question: What do you like about it? —User:Example2 
</syntaxhighlight>

nor {{xmark}} this (leave blank lines between list items):

<syntaxhighlight lang="wikitext">
* Support. I like this idea. —User:Example

** Question: What do you like about it? —User:Example2
</syntaxhighlight>

nor {{xmark}} this (jump more than one level):

<syntaxhighlight lang="wikitext">
* Support. I like this idea. —User:Example
*** Question: What do you like about it? —User:Example2
</syntaxhighlight>

This is generally discouraged {{xmark|color=yellow}}:

<syntaxhighlight lang="wikitext">
: Support. I like this idea. —User:Example 
:* Question: What do you like about it? —User:Example2 
</syntaxhighlight>
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 items ====

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

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

<syntaxhighlight lang="wikitext">
* This is one item.{{pb}}This is another paragraph within this item.
* This is another item.
</syntaxhighlight>

This can also be done {{tick}} with explicit HTML markup for paragraphs (note the closing <code><nowiki></p></nowiki></code> tag):

<syntaxhighlight lang="wikitext">
* This is one item.<p>This is another paragraph within this item.</p>
* This is another item.
</syntaxhighlight>

In both cases, this must be done {{tick}} 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:

<syntaxhighlight lang="wikitext">
* This is one item.<!--
--><p>This is another paragraph within this item.</p>
* This is another item.
</syntaxhighlight>

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

<syntaxhighlight lang="wikitext">
* 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.
</syntaxhighlight>
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).

{{Crossref|printworthy=y|See also [[Wikipedia:Manual of Style/Glossaries]] for rich but accessible markup of complex [[Wikipedia:Manual_of_Style/Lists#Description (definition, association) lists|description/definition/association lists]].}}

Do not {{xmark}} use line breaks to simulate paragraphs, because they have different semantics:

<syntaxhighlight lang="wikitext">
* This is one item.<br />This is the same paragraph, with a line break before it.
* This is another item.
</syntaxhighlight>
Line-break tags are for wrapping {{em|within}} a paragraph, such as lines of a poem or of a block of source code. See also the [[Help:Wikitext#Retaining newlines and spaces|{{tag|poem|o}}]] and [[Wikipedia:WikiProject Computer science/Manual of style#Code samples|{{tag|syntaxhighlight|o}}]] MediaWiki tags.

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

<syntaxhighlight lang="wikitext">
* This is one item.
: This is an entirely separate list.
* This is a third list.
</syntaxhighlight>

Alternatively, you can {{tick}} use one of the [[Template:HTML lists|HTML list templates]] to guarantee grouping. This is most useful for including block elements, such as formatted code, in lists:
<pre>
{{bulleted list
|1=This is one item:
&lt;pre>
This is some code.
&lt;/pre>
This is still the same item.
|2=This is a second item.
}}
</pre>
But this technique is not used on talk pages.

==== Indentation ====

{{shortcut|MOS:INDENTGAP}}
{{see also|Wikipedia:Indentation|l1=Indentation}}

An accessible approach to indentation is the template {{tlx|block indent}} for multi-line content; it uses [[Cascading style sheets|CSS]] to indent the material.  For single lines, a variety of templates exist, including {{tlx|in5}} (a universal template, with the same name on all Wikimedia sites); these indent with various whitespace characters.  [[Wikipedia:Manual of style#Indentation|Do not abuse]] the {{tag|blockquote}} element or templates that use it (such as {{tlx|blockquote}} {{abbr|AKA|also known as}} {{tlx|quote}}) for visual indentation; they are only for directly quoted material. The {{tlx|block indent}} generic alternative was created for such non-quote cases, so please use it.

A colon (<code>:</code>) at the start of a line marks that line in the MediaWiki parser as the {{tag|dd|o}} part of an HTML [[description list]] ({{tag|dl|o}}).{{efn|1=HTML [[description list]]s were formerly called ''definition lists'' and ''association lists''. The <code><nowiki><dl><dt>...</dt><dd>...</dd></dl></nowiki></code> structure is the same; only the terminology has changed between HTML specification versions.}} 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 {{tag|dt|o}} (term) element of a description list, to which the {{tag|dd|o}} (description/definition) pertains. As can be seen by inspecting the code sent to the browser, this results in broken HTML (i.e. it fails [[W3C Markup Validation Service|validation]]<ref>{{cite web |url= https://validator.w3.org/ |title=Markup Validation Service: Check the markup (HTML, XHTML, …) of Web documents |work=validator.w3.org |publisher=[[World Wide Web Consortium]] |date=2017 |version=v1.3+hg |access-date= December 13, 2017}}  The validator failure reported is "<strong>Error</strong>: Element <code>dl</code> is missing a required child element."</ref>). 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, [[Semantic HTML|semantics]], or [[Wikipedia:Reusing Wikipedia content|reuse]], but is currently commonly used, despite the problems it causes for users of screen readers.<!--Accessibility editors consider this a legacy usage, some others disagree, and a Phabricator ticket is open to change the parsing of ":" markup, at https://phabricator.wikimedia.org/T6521 -->

{{strong|Blank lines must {{em|not}} be placed between colon-indented lines of text}}{{snd}}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:

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

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):

<pre>
: Text here.{{pb}}More text. —User:Example3
</pre>

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

{{Hatnote|For more information on:
* Richer and more accessible alternative description-list markup, see [[Wikipedia:Manual of Style/Glossaries]].
* Weaknesses of colon-based markup—even for [[Wikipedia:Manual_of_Style/Lists#Description (definition, association) lists|actual description lists]] not just talk threads—see [[WP:Manual of Style/Glossaries/DD bug test cases]].
}}

==== Vertical lists ====

===== Bulleted vertical lists =====

{{shortcut|MOS:LISTGAP}}
For bulleted vertical lists, do not separate items by leaving blank lines between them. Instead, use the [[#Multiple paragraphs within list items|pb template or <nowiki><p></nowiki> HTML markup]]. 

The problem with blank lines is that, if list items are separated by more than one line break, the [[WP:HTML|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 reader]]s. For example, for the coding:

<pre>* White rose
* Yellow rose

* Pink rose

* Red rose
</pre>
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."

{{anchor|nobreaks|Nobreaks}}{{shortcut|MOS:NOBR|MOS:NOBREAKS}}
Do not separate list items with line breaks ({{tag|br|s}}). Use {{tl|plainlist}} / {{tl|unbulleted list}} if the list is to remain vertical; or consider {{tl|flatlist}} / {{tl|hlist}} if the list could be better rendered horizontally (inline) as described in the following two sections.

===== <span id="Unbulleted (vertical) lists"></span>Unbulleted vertical lists =====

<!-- This Anchor tag serves to provide a permanent target for incoming section links. Please do not move it out of the section heading, even though it disrupts edit summary generation (you can manually fix the edit summary before saving your changes). Please do not modify it, even if you modify the section title. It is always best to anchor an old section header that has been changed so that links to it won't be broken. See [[Template:Anchor]] for details. (This text: [[Template:Anchor comment]]) -->
{{shortcut|MOS:PLIST|MOS:VLIST}}

For unbulleted lists running down the page, the templates {{tl|plainlist}} and {{tl|unbulleted list}} are available, to improve accessibility and semantic meaningfulness by marking up what is clearly a list rather than including {{Tag|br|single}} 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 (<code>|</code>) unless it is replaced by <code><nowiki>{{!}}</nowiki></code> or is contained within {{tag|nowiki}} tags. Similarly it can't contain the equals sign (<code>=</code>), unless replaced with <code><nowiki>{{=}}</nowiki></code> or contained within {{tag|nowiki}}, though you can bypass this by naming the parameters (<code>|1=</code>, <code>|2=</code> etc.). If this becomes too much of a hassle, you may be able to use the variant using {{tl|endplainlist}} instead. Inside a reference, you may need {{tl|unbulleted list citebundle}} instead.
<div style="display:flex;flex-flow:row wrap;justify-content:space-evenly">
{| class="wikitable plainrowheaders"
|+ Example of plainlist
! scope="col" style="width:11.7em;" | Wikitext
! scope="col" style="width:11.7em;" | Renders as
|-
! scope="row"| <pre style="line-height:1.2em;">{{plainlist |
* White rose
* Yellow rose
* Pink rose
* Red rose
}}</pre>
| {{plainlist |
* White rose
* Yellow rose
* Pink rose
* Red rose
}}
|}
{| class="wikitable plainrowheaders"
|+ Example of unbulleted list
! scope="col" style="width:11.7em;" | Wikitext
! scope="col" tyle="width:11.7em;" | Renders as
|-
! scope="row"| <pre style="line-height:1.2em;">{{unbulleted list
| White rose
| Yellow rose
| Pink rose
| Red rose
}}</pre>
| {{unbulleted list
| White rose
| Yellow rose
| Pink rose
| Red rose
}}
|}
</div>

Alternatively, in templates such as [[Wikipedia:Navigation template|navboxes]] and the like, or any suitable container, such lists may be styled with the class "<code>plainlist</code>", thus:

{{plainlist |
* <code><nowiki>| listclass = plainlist</nowiki></code> or
* <code><nowiki>| bodyclass = plainlist</nowiki></code>
}}

In [[Wikipedia:Manual of Style/Infoboxes|infoboxes]]:

{{plainlist |
* <code><nowiki>| rowclass = plainlist</nowiki></code> or
* <code><nowiki>| bodyclass = plainlist</nowiki></code>
}}

may be used.

{{crossref|printworthy=y|See also [[Wikipedia:Manual of Style/Lists#Unbulleted lists|Manual of Style: Lists § Unbulleted lists]].}}

==== Horizontal lists ====

{{shortcut|MOS:HLIST}}

For lists running across the page, and in single rows in [[Wikipedia:Manual of Style/Infoboxes|infoboxes]] and other tables, the templates {{tl|flatlist}} and {{tl|hlist}} (for "horizontal list") are available to improve accessibility and semantic meaningfulness. This feature makes use of the correct HTML markup for each list item, rather than including bullet characters which, for example, are read out (e.g., "dot cat dot dog dot horse dot...") by the assistive software used by people who are blind. The templates differ only in the wiki-markup used to create the list. Note that when text is being passed to these (or any other) templates, the vertical bar character ({{pipe}}) should be [[Escape_character|escaped]] with {{tn|!}}.

<!-- The following examples deliberately wrap the list over two lines to show the position of the list separator.
Please don't widen them. -->
<div style="display:flex;flex-flow:row wrap;justify-content:space-evenly">
{| class="wikitable plainrowheaders"
|+ Example of flatlist
! scope="col"| Wikitext
! scope="col"| Renders as
|-
! scope="row"| <pre style="line-height:1.2em;">{{flatlist |
* White rose
* Red rose
** Pink rose
* Yellow rose
}}</pre>
| {{flatlist |
* White rose
* Red rose
** Pink rose
* Yellow rose
}}
|}
{| class="wikitable plainrowheaders"
|+ Example of hlist
! scope="col"| Wikitext
! scope="col"| Renders as
|-
! scope="row"| <pre style="line-height:1.2em;">{{hlist
| White rose
| Red rose
| Pink rose
| Yellow rose
}}</pre>
| {{hlist
| White rose
| Red rose
| Pink rose
| Yellow rose
}}
|}
</div>

Alternatively, in templates such as [[Wikipedia:Navigation template|navboxes]] and the like, or any suitable container, such lists may be styled with the class <code>hlist</code>, thus:

{{plainlist |
* <code><nowiki>| listclass = hlist</nowiki></code> or
* <code><nowiki>| bodyclass = hlist</nowiki></code>
}}

In [[Wikipedia:Manual of Style/Infoboxes|infoboxes]]:

{{plainlist |
* <code><nowiki>| rowclass = hlist</nowiki></code> or
* <code><nowiki>| bodyclass = hlist</nowiki></code>
}}

may be used.

==== List headings ====

{{see also|MOS:PSEUDOHEAD}}

Improper use of a semicolon to bold a "fake heading" before a list (figure 1) creates a [[#MOS:LISTGAP|list gap]], and worse. The semicolon line is a one-item description list, with no description content, followed by a second list.

Instead, use heading markup (figure 2).

<div role="figure" style="display: inline-block; margin: 0 1em; width: 13em;">
<strong>{{xmark}} 1. Incorrect</strong>
<syntaxhighlight lang="wikitext">
; Noble gases
* Helium
* Neon
* Argon
* Krypton
* Xenon
* Radon
</syntaxhighlight>
</div>

<div role="figure" style="display: inline-block; margin: 0 1em; width: 13em;">
<strong>{{tick}} 2. Heading</strong>
<pre>
== Noble gases ==
* Helium
* Neon
* Argon
* Krypton
* Xenon
* Radon
</pre>
</div>

=== Tables ===

{{shortcut|MOS:DTAB}}

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. Do not solely use formatting, either from CSS or hard-coded styles, to create semantic meaning (e.g., changing background color).

Many [[Wikipedia:Navigational templates|navboxes]], [[Wikipedia:Series templates|series templates]], and [[Wikipedia:Manual of Style/Infoboxes|infoboxes]] are made using tables.

Avoid using {{tag|br|s}} or {{tag|hr|s}} tags in adjacent cells to emulate a visual row that isn't reflected in the HTML table structure. This is a problem for users of screen readers which read tables cell by cell, HTML row by HTML row, not visual row by visual row. [[Wikipedia:WikiProject Accessibility/Infobox accessibility|WikiProject Accessibility/Infobox accessibility]] has been addressing this problem.

==== Data tables ====

{{Main article|Wikipedia:Manual of Style/Accessibility/Data tables tutorial}}

<pre>
{|
|+ [caption text]
|-
! scope="col" | [column header 1]
! scope="col" | [column header 2]
! scope="col" | [column header 3]
|-
! scope="row" | [row header 1]
| [normal cell 1,2] || [normal cell 1,3]
|-
! scope="row" | [row header 2]
| [normal cell 2,2] || [normal cell 2,3]
...
|}
</pre>

; Caption ( <code>|+</code> )
: A caption is a table's title, describing its nature.<ref name="H39">[http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H39 H39: Using caption elements to associate data table captions with data tables], A accessibility level.</ref> Data tables should always include a caption.
; Row and column headers (<code> ! </code>)
: Like the caption, these help present the information in a logical structure to visitors.<ref>{{Cite web | url = http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H51 | title = H51: Using table markup to present tabular information| accessdate = 1 January 2011| publisher = [[World Wide Web Consortium]]}}</ref> The headers help screen readers render header information about data cells. For example, header information is spoken prior to the cell data, or header information is provided on request.<ref>{{Cite web | url = http://www.w3.org/TR/REC-html40/struct/tables.html#edef-TH | title= Table cells: The TH and TD elements | work = Techniques for WCAG 2.0 | publisher = [[World Wide Web Consortium]] | accessdate = 1 January 2011}}</ref> Because the row header and column header may be spoken before the data in each cell when navigating in table mode, it is necessary for the column headers and row headers to ''uniquely identify'' the column and row respectively.<ref name="jaws">{{cite web |title=Tables with JAWS |url=https://www.freedomscientific.com/SurfsUp/Tables.htm |publisher=Freedom Scientific |access-date=18 February 2021}}</ref>
; Scope of headers (<code>! scope="col" |</code> and <code>! scope="row" |</code>)
: This clearly identifies headers as either row headers or column headers. Headers can now be associated to corresponding cells.<ref name="H63">{{Cite web | url = http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H63.html | title = H63: Using the scope attribute to associate header cells and data cells in data tables| work = Techniques for WCAG 2.0 | accessdate = 1 January 2011| publisher = [[World Wide Web Consortium]]}}</ref>

[[Wikipedia:Manual of Style/Accessibility/Data tables tutorial]] provides detailed requirements about:
# Correct table captions
# Correct headers structure
# Complex tables
# Images and color
# Avoiding nested tables

==== Layout tables ====

{{shortcut|MOS:LTAB}}

Avoid using tables for visual positioning of non-tabular content. Data tables provide extra information and navigation methods that can be confusing when the content lacks logical row and column relationships. Instead, use semantically appropriate elements or <code>&lt;div&gt;</code>s, and <code>style</code> attributes.

When using a table to position non-tabular content, help screen readers identify it as a layout table, not a data table. Set a <code>role="presentation"</code> attribute on the table, and do not set any <code>summary</code> attribute. Do not use any <code>&lt;caption&gt;</code> or <code>&lt;th&gt;</code> elements inside the table, or inside any nested tables. In wiki table markup, this means do not use the <code>|+</code> or <code>!</code> prefixes. Make sure the content's reading order is correct. Visual effects, such as centering or bold typeface, can be achieved with style sheets or semantic elements. For example:

<pre>
{| role="presentation" class="toccolors" style="width:94%"
|-
| colspan="2" style="text-align: center; background-color: #ccf;" | <strong>Important text</strong>
|-
| The quick || brown fox
|-
| jumps over || the lazy dog.
|}
</pre>

== Images ==

{{Shortcut|MOS:ACCIM}}
{{Further information|Wikipedia:Alternative text for images|Wikipedia:Manual of Style#Images|Wikipedia:Image use policy#Displayed image size|Wikipedia:Image dos and don'ts}}

# Images and icons that are not purely decorative should include an [[alt attribute]] that acts as a substitute for the image for blind readers, search-spiders, and other non-visual users. If additional alt text is added, it should be succinct or refer the reader to the caption or adjacent text. See [[WP:ALT]] for more information. {{Crossref|printworthy=y|For additional considerations about icons, see {{section link|Wikipedia:Manual of Style/Icons#Remember accessibility for people with visual impairment}}.}}
# In [[Wikipedia:Manual of Style/Captions#Special situations|most cases]], images should include a [[Wikipedia:Manual of Style/Captions|caption]] using the built-in image syntax. The caption should concisely describe the meaning of the image and the essential information it is trying to convey.
# Avoid using images in place of [[MOS:DTAB|tables or charts]]. Where possible, any charts or diagrams should have a text equivalent or should be well-described so that users who are unable to see the image can gain some understanding of the concept.
# Avoid placing images on the left hand side as a consistent left margin makes reading easier.
# Avoid [[MOS:IMAGELOCATION|sandwiching]] text between two images or, unless absolutely necessary, using [[Wikipedia:Image use policy#Displayed image size|fixed image sizes]].
# Avoid indiscriminate [[WP:GALLERY|galleries]] because screen size and browser formatting may affect accessibility for some readers due to fragmented image display. Articles with many images will time out on mobile versions of Wikipedia. Ideally, a page should have no more than 100 images (regardless of how small). See [[mediawikiwiki:Recommendations for mobile friendly articles on Wikimedia wikis#Limit number of images in a page|MediaWiki:Limit number of images in a page]] 
# Avoid referring in text to images as being on the left or right. Image placement may be different for viewers of the mobile site, and is meaningless to people having pages read to them by assistive software. Instead, use captions to identify images.
# Detailed image descriptions, where not appropriate for an article, should be placed on the image's description page, with a note saying that activating the image link will lead to a more detailed description. See [[Help:File description page#Image summary]]
# Images should be inside the section to which they are related (after the heading and any [[Wikipedia:Hatnote|hatnotes]]), and not in the heading itself nor at the end of the previous section. This ensures that screen readers will read, and the mobile site will display, the image (and its textual alternative) in the correct section.
# This guideline includes alt text for LaTeX-formatted equations in [[Wikipedia:Manual of Style/Mathematics#Typesetting of mathematical formulae|{{tag|math|o}}]] mode. See [[Wikipedia:Manual of Style/Mathematics#Alt text]]
# [[Wikipedia:Manual of Style#Section headings|Do not put images in headings]]; this includes [[Wikipedia:Manual of Style/Icons#Encyclopedic purpose|icons]] and [[Wikipedia:Manual of Style/Mathematics#Typesetting of mathematical formulae|{{tag|math|o}}]] markup. Doing so can break links to sections and cause other problems.

== Animations, video, and audio content ==

{{anchor|Animations, video and audio content|reason=Old section name with awkwardly missing comma.}}
{{Shortcut|MOS:ANIMATION}}
{{Further information|Help:Media|Help:Creation and usage of media files}}

=== Animations ===

To be accessible, an animation ([[GIF]] – Graphics Interchange Format) should either:
* Not exceed a duration of five seconds (which results in making it a purely decorative element)<ref>{{Cite web| url =http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G152| title =  Setting animated gif images to stop blinking after n cycles (within 5 seconds)| work = Techniques for WCAG 2.0 | accessdate = 1 January 2011 | publisher = [[World Wide Web Consortium]]}}</ref> or
* Be equipped with control functions (stop, pause, play)<ref>{{Cite web | url = http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G4 | title = Allowing the content to be paused and restarted from where it was paused| accessdate = 1 January 2011| work = Techniques for WCAG 2.0 | publisher = [[World Wide Web Consortium]]}}</ref>

This requires GIFs with animations longer than five seconds to be converted to video (to learn how, see the tutorial [//commons.wikimedia.org/w/index.php?title=Help_talk:Converting_video&oldid=39737985#Converting_an_animated_GIF converting animated GIFs to Theora OGG]).

In addition, animations {{em|must not}} produce more than three flashes in any one-second period. Content that flashes more than that limit is known to cause seizures.<ref name="wcag 2.0 gl2.3">{{cite web | url=http://www.w3.org/TR/2008/REC-WCAG20-20081211/#seizure-does-not-violate | title=Guideline 2.3 Seizures: Do not design content in a way that is known to cause seizures. | date=11 December 2008 | work=Web Content Accessibility Guidelines (WCAG) 2.0 | publisher=[[World Wide Web Consortium]] | accessdate=28 May 2015}}</ref>

=== Video ===

Subtitles can be added to video, in [[timed text]] format. There is a corresponding help page at [[:commons:Commons:Video#Subtitles and closed captioning]]. Subtitles are meant for the transcription of speech.

There is a need for [[closed captions]] for the hearing impaired. As of November 2012 this is not possible, but this feature could be easily added and has been requested in [[bugzilla:41694]]. Closed captions are meant to be viewed instead of subtitles. Closed captions provide a text version of all important information provided through the sound. It can include dialogue, sounds (natural and artificial), the setting and background, the actions and expressions of people and animals, text or graphics.<ref>{{Cite web | url = http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G69 | title = Providing an alternative for time based media | work = Techniques for WCAG 2.0 | accessdate = 1 January 2011| publisher = [[W3C]]}}</ref> Off-Wikipedia guides should be consulted for how to create closed captions.<ref>Please see: [https://web.archive.org/web/20120504142732/http://main.wgbh.org/wgbh/pages/mag/services/captioning/faq/sugg-styles-conv-faq.html A quick and basic reference for closed captions], [http://www.cab-acr.ca/english/social/captioning/captioning.pdf a detailed reference (PDF)] and [https://dcmp.org/learn/captioningkey a list of best practices for closed captions].</ref>

A text version of the video would also be needed for the blind, but as of November 2012 there is no convenient way to provide alt text for videos.

=== Audio ===

Subtitles for speech, lyrics, dialogue, etc.<ref>{{Cite web| url = http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G158 | title = Providing an alternative for time-based media for audio-only content| work = Techniques for WCAG 2.0 | publisher = [[World Wide Web Consortium]]| accessdate = 1 January 2011}}</ref> can easily be added to audio files. The method is similar to that of the video: [[:commons:Commons:Video#Subtitles and closed captioning]].

== Styles and markup options ==

{{Shortcut|MOS:DEVIATIONS}}

=== Best practice: Use wiki markup and CSS classes in preference to alternatives ===

In general, styles for tables and other block-level elements should be set using CSS classes, not with inline style attributes. The site-wide CSS in [[MediaWiki:Common.css]] is more carefully tested to ensure accessibility (e.g. sufficient color contrast) and compatibility with a wide range of browsers. Moreover, it allows users with very specific needs to change the color schemes in their own style sheet ([[Special:MyPage/skin.css]], or their browser's style sheet). For example, a style sheet at [[Wikipedia:Style sheets for visually impaired users]] provides higher contrast backgrounds for [[Wikipedia:Navigation template|navboxes]]. The problem is that when the default site-wide classes are overridden, it makes it far more difficult for an individual to choose their own theme.

It also creates a greater degree of professionalism by ensuring a consistent appearance between articles and conformance to a style guide.

Regarding accessibility, deviations from standard conventions may be tolerated [[Wikipedia:Manual of Style/Accessibility#Color|so long as they are accessible]]. Members of the accessibility project have ensured that the default style is accessible. If some template or specific color scheme deviates from the standard, its authors should make sure that it meets accessibility requirements such as providing enough [[Wikipedia:Colour contrast|color contrast]]. For instance, the [[Wikipedia:Manual of Style/Infoboxes|infobox]] and [[Wikipedia:Navigation template|navbox]] relating to a sport team might use a yellow and red color scheme, to tie in with the colors of the team livery. In this case, dark red links on light yellow provide enough color contrast, and thus would be accessible, while white on yellow or black on red would not.

In general, articles should use [[wiki markup]] in preference to the limited set of [[meta:Help:HTML_in_wikitext#Permitted_HTML|allowed HTML elements]]. In particular, do not use the HTML style elements {{tag|i|o}} and {{tag|b|o}} to format text; it is preferable to use Wiki-markup <code><nowiki>''</nowiki></code> or <code><nowiki>'''</nowiki></code> for purely typographic italicization and boldfacing, respectively, and use [[Semantic HTML|semantic markup]] templates or elements for more meaningful differences.  The {{tag|font|o}} element should also be avoided in article text; use {{tlx|em}}, {{tlx|code}}, {{tlx|var}}, and our other [[:Category:Semantic markup templates|semantic markup templates]] as needed, to emphasize logical differences not just visual ones. Use the {{tl|resize}}, {{tl|small}}, and {{tl|big}} templates to change font size, rather than setting it explicitly with CSS style attributes like <code>font-size</code> or deprecated style elements like {{tag|big|o}}. Of course there are natural exceptions; e.g., it may be beneficial to use the {{tag|u}} element to indicate something like an example link that isn't really clickable, but underlining is otherwise generally [[MOS:BADEMPHASIS|not used in article text]].

=== Users with limited CSS or JavaScript support ===

{{shortcut|MOS:PRECOLLAPSE}}
{{see also|Wikipedia:Manual of Style#Scrolling lists and collapsible content|mw:No-JavaScript notes}}{{anchor|Scrolling and collapsible sections|Users with limited CSS/JavaScript support}}<!--Old name, misusing slash; may be linked to from somewhere.-->

Auto-collapsed (pre-collapsed) elements [[Wikipedia:Manual of Style#Scrolling lists and collapsible content|should not be used to hide content]] in the article's main body.

Wikipedia articles should be accessible to readers using browsers and devices that have limited or no support for [[JavaScript]] or [[Cascading Style Sheets]], which is referred to as "[[progressive enhancement]]" in web development. Remember that [[Wikipedia:Reusing Wikipedia content|Wikipedia content can be reused freely]] in ways we cannot predict as well as accessed directly via older browsers. At the same time, it is recognized 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 that would cause content to be hidden or corrupted when CSS or JavaScript is unavailable must not be used. However, consideration for users without CSS or JavaScript should extend mainly to making sure that their reading experience is {{em|possible}}; it is recognized that it will inevitably be {{em|inferior}}.

Note that mobile versions of the website do not support collapsing, so any collapsible content will automatically be uncollapsed.

To accommodate these considerations, test any potentially disruptive changes with JavaScript or CSS disabled. In Firefox or Chrome, this can be done easily with the Web Developer extension; JavaScript can be disabled in other browsers in the "Options" screen. Be particularly careful with inline CSS effects, which are not supported by several browsers, media, and XHTML versions.

In 2016, around 7% of visitors to Wikipedia did not request JavaScript resources.<ref>[https://commons.wikimedia.org/w/index.php?title=File:Browsers,_Geography,_and_JavaScript_Support_on_Wikipedia_Portal.pdf&page=5 File:Browsers, Geography, and JavaScript Support on Wikipedia Portal.pdf] and [[:File:Analysis of Wikipedia Portal Traffic and JavaScript Support.pdf]].</ref>

== See also ==
*[[List of style guides]]
* [[Usability:Accessibility Initiative]] (located at  Wikimedia)
* [[Web Accessibility Initiative]] (WAI)
* [[Wikipedia:Accessibility dos and don'ts]] (key points of this guideline)
* [[Wikipedia:Dyslexic readers]]
* [[Wikipedia:Make technical articles understandable]]
* [[Wikipedia:Using JAWS]]
* [[Help:mobile access]]
* [[Wikipedia:Accessibility advocates]]
* [[Wikipedia:WikiProject Accessibility]]
* [[Wikipedia:WikiProject Usability]]

== Notes ==
{{Notelist}}

== References ==
{{Reflist}}

== Further reading ==
* {{cite book
  | first = Joe
  | last = Clark
  | year = 2003
  | title = Building Accessible Websites
  | edition =
  | publisher = New Riders Press
  | location =
  | isbn = 0-7357-1150-X
  | url = http://www.joeclark.org/book/
  | accessdate = 1 January 2011
  |ref=none
  }}
* {{cite web
  | first = Mark
  | last = Pilgrim
  | title = Dive Into Accessibility: 30 days to a more accessible web site
  | year = 2002
  | url = http://diveintoaccessibility.info
  |archive-url=https://web.archive.org/web/20171005130529/http://diveintoaccessibility.info/
  |archive-date=5 October 2017
  |ref=none
  }}
*{{cite book | author1 = Patrick J. Lynch | author2 = Sarah Horton | year= 2016 | title = Web Style Guide | publisher = Yale University Press | pages = | isbn = 978-0-300-21165-8 | oclc = 1004033147 | url = https://books.google.com/books?id=EY_BDAAAQBAJ&pg=PP1}}

== External links ==

* [https://design.wikimedia.org/style-guide/ The Wikimedia Design Style Guide]
* [[mw:Recommendations_for_mobile_friendly_articles_on_Wikimedia_wikis|Recommendations for mobile friendly articles on Wikimedia wikis]]
* [http://www.w3.org/WAI/quicktips/ 10 Quick Tips to Make Accessible Web Sites], from WAI
* [http://colorfilter.wickline.org/ Colorblind web page filter]
*[https://webstyleguide.com/wsg3/8-typography/3-legibility.html Legibility], from  Web Style Guide, 3rd Edition
* [http://www.w3.org/WAI/intro/components.php Essential Components of Web Accessibility], from WAI
* [http://www.w3.org/WAI/intro/accessibility.php Introduction to Web Accessibility], from [[Web Accessibility Initiative|WAI]]
* [https://phabricator.wikimedia.org/tag/accessibility/ Known and tracked MediaWiki accessibility issues]

{{Wikipedia policies and guidelines}}

[[Category:Wikipedia Manual of Style (accessibility)| ]]
[[Category:Wikipedia accessibility| ]]