Wikipedia:Manual of Style/Accessibility#Other languages

{{Main|Wikipedia:Manual of Style/Layout|Wikipedia:Manual of Style/Lead section#Elements}}

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.

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

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.

{{Shortcut|MOS:PSEUDOHEAD|MOS:FAKEHEADING}}

{{Anchor|Pseudo-headings}}

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 {{tl|TOC limit}} template to reduce the length of the TOC by hiding nested subsections, rather than a floating TOC. When {{tl|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.

{{Shortcut|MOS:ACCESS#FLOAT}}

{{See also|Wikipedia:Manual of Style/Images#Location|Wikipedia:Manual of Style/Accessibility#Images}}

In wikitext, floating elements (including images) should be placed {{em|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.

{{Anchor|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 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.

{{Shortcut|MOS:NOSTRIKE|MOS:NOSYMBOLS}}

{{See also|Wikipedia:Manual of Style/Text formatting}}

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 {{tag|s|o}} and {{tag|del|o}} elements (along with their corresponding {{tag|ins|o}}, 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 , 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.

1. 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., {{tlx|Langx|2=ru|3=text=пример|4=translit=prímer|5=translation=example}) and can also be created using {{tl|Transliteration}}. These templates also offer other accessibility benefits (see § Other languages below).
2. 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 appropriate alt= text.{{cite web |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 |date=7 October 2016 |publisher=World Wide Web Consortium |url=https://www.w3.org/TR/WCAG20-TECHS/F26.html |access-date=29 December 2011}}
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 {{tl|†}} (see :Category:Single-image insertion templates for more).{{update inline |inaccurate=y |date=July 2023 |reason=The dagger template no longer produces an image.}}

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.

{{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 infoboxes, navboxes, and 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 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;{{cite web |title=4.5.4 The small element |date=24 December 2023 |work=HTML Living Standard |publisher=Web Hypertext Application Technology Working Group |url=https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-small-element |access-date=29 December 2023}} do not use it for stylistic changes.

{{Main|Wikipedia:Manual of Style/Dates and numbers#Fractions and ratios}}

Apart from the exceptions explained at {{section link|WP:Manual of Style/Dates and numbers#Fractions}}, do not use precomposed fraction characters such as {{!xt|½}} (deprecated markup: {{!xt|½}} or {{!xt|½}}). 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 {{tlx|Fraction}} which produces fractions in the form {{xt|{{Fraction|3|4}}}}. (For scientific and mathematical text, use {{tlx|sfrac}}, which produces fractions in the form {{xt|{{sfrac|3|4}}}}.)

{{Shortcut|MOS:OTHERLANG|MOS:LANG|MOS:IETF}}

{{Main|Template:Lang/doc#Rationale}}

{{See also|Wikipedia:Manual of Style#Non-English terms|Wikipedia:Manual of Style/Text formatting#Non-English language terms|Wikipedia:Manual of Style/Linking#Interwiki links|Category:Wikipedia multilingual support templates}}

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, typically with a template like {{tlx|lang}}, or one of its derivatives. This marks the text with an IETF language tag, which specifies the language and script. For example:

• {{nay}} {{code|Assemblée nationale}} is merely italicized, and has not specified that it is French-language text. Most screen readers attempting to handle this will sound ridiculous or confusing.
• {{aye}} {{tlx|lang|fr|Assemblée nationale}} renders as {{xt|{{lang|fr|Assemblée nationale}}}}, which is italicized by default and will allow screen readers to select a French-language voice.
• {{aye}} {{tlx|langx|fr|Assemblée nationale}} → {{xt|{{langx|fr|Assemblée nationale}}}} – This is similar to the above.

{{strong|Rationale}}: Among other uses, specifying the language of text with {{tnull|lang}} allows speech synthesizers to select a voice capable of correctly reading out the text.{{cite web |title=H58: Using language attributes to identify changes in the human language |work=Techniques for WCAG 2.0 |date=7 October 2016 |publisher=World Wide Web Consortium |url=https://www.w3.org/TR/WCAG20-TECHS/H58.html |access-date=29 December 2023}} Accessibility level: AA.

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:

• {{aye}} {{tlx|lang|sr-Cyrl|Народна скупштина}} → {{xt|{{lang|sr-Cyrl|Народна скупштина}}}}
• {{aye}} {{tlx|lang|sr-Latn|Narodna skupština}} → {{xt|{{lang|sr-Latn|Narodna skupština}}}} – Serbian can typically be written using either the Latin or Cyrillic script.
• {{nay}} {{tlx|lang|ja|Kokumin gikai}} – By default, it is expected for Japanese text to be written using the native writing system, whose rules may treat some characters differently.
• {{aye}} {{tlx|lang|ja-Latn|Kokumin gikai}} specifies Japanese written with the Latin alphabet (i.e. {{lang|ja-Latn|rōmaji|i=no}}).
• {{aye}} {{tlx|transliteration|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 {{code|-Latn}} to the language code, or by using the equivalent {{tlx|transliteration}} template. Wikipedia has a number of language-specific templates such as {{tlx|lang-zh}} and {{tlx|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 {{tlx|lang}} and {{tlx|transliteration}}.

It is usually unnecessary to specify italics in addition to the {{tlx|lang}} or {{tlx|lang-{{var|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 {{para|italic|unset}} may be added.{{efn|Further details on this usage are available on the template documentation for {{tlx|lang}}.}} As outlined in MOS:NON-ENG, text using a non-Latin script should almost never be italicized or bolded.

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

1. Create good link descriptions, especially for external links. (Avoid "click here!", "[http://example.com/ this] website"){{cite web |title=G91: Providing link text that describes the purpose of a link |work=Techniques for WCAG 2.0 |date=7 October 2016 |publisher=World Wide Web Consortium |url=https://www.w3.org/TR/WCAG20-TECHS/G91.html |access-date=29 December 2023}}{{cite web |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 |date=7 October 2016 |publisher=World Wide Web Consortium |url=https://www.w3.org/TR/WCAG20-TECHS/F84.html |access-date=29 December 2023}}
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 anchor where Destination highlighting helps the partially sighted to locate more easily the link target on the destination page.

{{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 colours|and|Help:Link color|the WikiProject on color|Wikipedia:WikiProject Color}}

{{About|the use of colors in articles|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

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

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

• Avoid using color as the sole means of conveying information. Always provide an alternative 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 be clearly identifiable as links for readers.
• Ensure sufficient contrast between text and its background, as some readers of Wikipedia are partially or fully color-blind or visually impaired. The contrast ratio should at least meet the Web Content Accessibility Guidelines (WCAG) 2.0 AA level of 4.5:1,{{efn|name=fn1}} 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)]" for details). For named CSS-based text colors on a white background, refer to Wikipedia:Manual of Style/Accessibility/CSS colors for recommended colors. Tools to check that contrast is sufficient are available with some listed below.

To ensure a sufficient color contrast ratio, use the following online tools:

• {{URL|https://webaim.org/resources/contrastchecker/|WebAIM contrast checker}}
• {{URL|https://whocanuse.com/|WhoCanUse}}
• {{URL|https://snook.ca/technical/colour_contrast/colour.html|Snook's color contrast check}}

Before using a tool, check if it supports WCAG 2.0, as older tools based on WCAG 1.0 are outdated.

The Wikimedia Foundation Design team {{URL|https://doc.wikimedia.org/codex/latest/style-guide/colors.html|has provided a color palette}} for AA-level contrast compliance. 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 color.

For AAA-compliant color pairings for different text types (black text, white text, links, and visited links), refer to the table at Wikipedia:Manual of Style/Accessibility/Colors. For named CSS-based text colors on a white background, refer to Wikipedia:Manual of Style/Accessibility/CSS colors for recommended colors.

• Google Chrome DevTools' {{URL|https://developer.chrome.com/docs/devtools/accessibility/contrast|color contrast debugger}} (with a visual guide and built-in color-picker).
• {{URL|https://www.tpgi.com/color-contrast-checker/|Color Contrast Analyser}} (downloadable software for precise contrast checks; be sure to only use the up-to-date "luminosity" algorithm, and not the "color brightness/difference", which is outdated.).
• {{URL|https://paletton.com/|Paletton}} (formerly Color Scheme Designer) helps select suitable color schemes for a graphical chart.
• {{URL|https://colorbrewer2.org/|Color Brewer 2.0}} provides color-blind-friendly color schemes for maps.
• {{URL|https://personal.sron.nl/~pault/#fig:scheme_light|Light qualitative color scheme}} provides a set of nine colors that work well for color-blind users and black text labels.
• 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).

If an article overuses colors, and you are unsure how to fix it yourself, you can request help from other editors. Add {{tl|Overcolored}} or {{tl|Overcoloured}} at the top of the article.

{{wide image|WCAG_web_safe_contrast_ratio.svg|600px|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)}}

{{Shortcut|MOS:LISTBREAK}}

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

{{Shortcut|MOS:INDENTMIX}}

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:

{{tick}}In 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

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

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

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

{{xmark}} nor switch from bullet list to mixed type,

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

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

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

{{xmark}} As is jumping more than one level,

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

{{xmark|color=yellow}} 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.

{{shortcut|MOS:PARABR}}

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

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

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

{{tick}} This can also be done with explicit HTML markup for paragraphs (note the closing

• This is one item.

  This is another paragraph within this item.

• This is another item.

{{tick}} 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.

  This is another paragraph within this item.

  • This is another item.

  {{tick}} 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.

    This is another paragraph within this item, and we're going to quote someone:

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

    This is a closing paragraph within the same list item.

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

    {{Crossreference|pw=y|See also WP:Manual of Style/Glossaries for rich but accessible markup of complex description/definition/association lists.}}

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

    • This is one item.
      This is the same paragraph, with a line break before it.
    • This is another item.

    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 and Wikipedia:WikiProject Computer science/Manual of style#Code samples MediaWiki tags.

    {{xmark}} 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.

    {{tick}} 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:

    
    This is some code.
    

    This is still the same item.

    |2=This is a second item.

    }}

    But this technique is not used on talk pages.

{{Shortcut|MOS:INDENTGAP|MOS:BADINDENT}}

{{See also|Wikipedia:Indentation}}

An accessible approach to indentation is the template {{tlx|block indent}} for multi-line content; it uses 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. Do not abuse the {{tag|blockquote}} element or templates that use it (such as {{tlx|blockquote}}) 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 (:) 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 lists were formerly called definition lists and association lists. The

...

...

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

: 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 $$1\; +\; 1\; =\; 2$$ be used instead of :$1\; +\; 1\; =\; 2$.

{{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 actual description lists not just talk threads – see WP:Manual of Style/Glossaries/DD bug test cases.

}}

{{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. (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."

{{anchor|nobreaks|Nobreaks|NOBREAKS}}{{shortcut|MOS:NOBR|MOS:NOBREAKS}}

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

{{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 (|) unless it is replaced by {{!}} or is contained within {{tag|nowiki}} tags. Similarly it can't contain the equals sign (=), unless replaced with {{=}} or contained within {{tag|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 {{tl|endplainlist}} instead. Inside a reference, you may need {{tl|unbulleted list citebundle}} instead.

{{plainlist |


White rose
Yellow rose
Pink rose
Red rose

}}

{{unbulleted list

| White rose
| Yellow rose
| Pink rose
| Red rose
}}

Alternatively, in templates such as navboxes and the like, or any suitable container, such lists may be styled with the class "plainlist", thus:

{{plainlist |

• | listclass = plainlist or
• | bodyclass = plainlist

}}

In infoboxes, the following may be used:

{{plainlist |

• | rowclass = plainlist or
• | bodyclass = plainlist

}}

{{Crossreference|pw=y|See also {{section link|WP:Manual of Style/Lists#Unbulleted lists}}.}}

The above blank-line issues also affect numbered lists, using # markup, and the list numbering will reset after the line break. The list-breakage problem of blank lines also applies to description (definition, association) lists, using ; and : markup; that type of list can have line breaks in it if instead created with the glossary templates.

{{Redirect|WP:FLIST|featured lists|Wikipedia:Featured lists}}

{{Shortcut|MOS:HLIST}}

For lists running across the page, and in single rows in infoboxes and other tables, the templates {{tlx|flatlist}} and {{tlx|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 escaped with {{tlx|!}}.

{{flatlist |


White rose
Red rose
Pink rose
Yellow rose

}}

{{hlist

| White rose
| Red rose
| Pink rose
| Yellow rose
}}

Alternatively, in templates such as navboxes and the like, or any suitable container, such lists may be styled with the class hlist, thus:

{{plainlist |

• | listclass = hlist or
• | bodyclass = hlist

}}

In infoboxes:

{{plainlist |

• | rowclass = hlist or
• | bodyclass = hlist

}}

may be used.

{{See also|MOS:PSEUDOHEAD}}

Improper use of a semicolon to bold a "fake heading" before a list (figure 1) creates a 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).

• Helium
• Neon
• Argon
• Krypton
• Xenon
• Radon