Wikiafripedia:Manual of Style/Accessibility

From Wikiafripedia, the free encyclopedia that you can monetize your contributions or browse at zero-rating.
Jump to navigation Jump to search

Web accessibility is the goal of making web pages easier to navigate and read. While this is primarily intended to assist those with disabilities, it can be helpful to all readers. We aim to adhere to Web Content Accessibility Guidelines 2.0 (also known as 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 nondiscrimination resolution: "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 "may not be circumvented, eroded, or ignored by Wikimedia Foundation officers or staff nor local policies of any Wikimedia project".

Article structure[edit source | edit]

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

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

Headings[edit source | edit]

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

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

Examples of correct and incorrect use of nested headings
Correct Random/chaotic Skipping levels

[Article lead here]
==Section== [level 2]
===Sub-section=== [3]
==Section== [2]
===Sub-section=== [3]
====Sub-sub-section==== [4]
==Section== [2]

[Article lead here]
====Section?==== [4]
===Section?=== [3]
==Section?== [2]
==Section?== [2]
====Section?==== [4]
===Section?=== [3]

[Article lead here]
[Level-2 section missing here]
===Section?=== [3]
==Section== [2]
[Level-3 sub-section missing here]
====Sub-section?==== [4]
==Section== [2]

Do not make pseudo-headings by abusing semicolon markup (reserved for description lists) and try to avoid using bold markup. Screen readers and other assistive technology can only use headings that have heading markup for navigation. If you want to reduce the size of the table of contents (TOC), use

  1. REDIRECT Template:Template link

instead. In cases where {{TOC limit}} cannot be used because of lower-level headings elsewhere in the article, then using bold for the sub-sub-sub headings causes the least annoyance for screen reader users. Using a pseudo heading at all means you have exhausted all other options. It is a rarity.

Examples of acceptable and incorrect use of pseudo-headings and description lists
Acceptable Incorrect

[Article lead here]
==Section== [level 2]
===Sub-section=== [3]
==Section== [2]
===Sub-section=== [3]
====Sub-sub-section==== [4]
;A term followed by
:a definition is a description list

[Article lead here]
==Section== [level 2]
===Sub-section=== [3]
==Section== [2]
===Sub-section=== [3]
<small>==Sub-sub-section==</small> [2]

Floating elements[edit source | edit]

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

Resolution[edit source | edit]

Wikiafripedia articles should be accessible to readers using devices with small screens, or to readers using monitors with a low resolution. The lowest resolution that it is considered possible to support without adversely affecting other users is 1024×768; all articles should look acceptable at this resolution without excessive horizontal scrolling. This is sometimes an issue in articles with multiple images on both sides of the screen; although lower resolutions will tend to stretch paragraphs vertically, moving images apart in that direction, be careful not to add images or other floating content on both sides of the screen simultaneously. Large tables and images can also create problems; sometimes horizontal scrolling is unavoidable, but consider restructuring wide tables to extend vertically rather than horizontally.

Text[edit source | edit]

In articles, do not use strikethrough to remove objectionable text. Either comment it out with "<!--" and "-->" or remove it entirely. By default, most screen readers do not indicate presentational text attributes (bold, italic, underline) 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 Wikiafripedia policy and deletion debates are advised to turn on notifications about text attributes when doing so, as struck text is very common in Wikiafripedia-internal discussions.)

Screen readers without Unicode support will generally read a character outside Latin-1 and Windows-1252 as a question mark, and even in JAWS, the most popular screen reader, Unicode characters are very difficult to read.

  1. Provide a transliteration for all text in a non-Latin writing system where the non-Latin character is important in the original context such as names, places, things etc.
  2. Do not use unpronounceable symbols such as ♥ (a heart symbol); use images with alt text instead.[1]
  3. Symbols that cause problems for screen readers may already have templates created to produce an image and alt text. An example is the dagger template {{}} (see Category:Single-image insertion templates for more).

The sequence of characters must be sufficient to convey semantic aspects of the text (and, preferably, other similar forms of content); reliance on custom "special symbols" distinguishable only by CSS properties or wiki markup is not acceptable.

Do not use techniques that require interaction to provide information, such as tooltips or any other "hover" text. Abbreviations are exempt from these requirements, so the {{abbr}} template may be used to indicate the long form of a word.

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[edit source | edit]

Reduced or enlarged font sizes should be used sparingly, and are usually done with automated page elements such as headings, table headers, and standardized templates. Size changes are specified as a percentage of the original font size and not as an absolute size in pixels or point size. This improves accessibility for visually impaired users who use a large default font size.

Avoid using smaller font sizes within elements that already use a smaller font size, such as infoboxes, navboxes, and reference sections. This means that <small>...</small> tags, and templates such as {{small}} and {{smaller}}, 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 (i.e. 11.9 px in Vector skin or 10.8 px in Monobook).

Other languages[edit source | edit]

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

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

which renders as

Assemblée nationale

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

which renders as

French: Assemblée nationale.

Rationale: {{lang}} enables speech synthesizers to pronounce the text in the correct language.[2] It has many other uses; see Template:Lang/doc § Rationale for a comprehensive list of benefits.

2018 update: It is no longer necessary or desirable to wrap these constructions in italics markup; the {{lang}} and {{lang-xx}} templates already auto-italicize.

Links[edit source | edit]

  1. Create good link descriptions, especially for external links (avoid "click here!", "this").[3][4]
  2. Do not use Unicode characters as icons; use an icon with alt text instead. For example, a character like "→" can not be reproduced into useful text by a screen reader, and will usually be read as a question mark.

Color[edit source | edit]

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 colorblindness on legibility

Colors are most commonly found in Wikiafripedia 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:

  • Ensure that color is not the only method used to convey important information. Especially, do not use colored text or background unless its status is also indicated using another method such as an accessible symbol matched to a legend, or footnote labels. Otherwise, blind users or readers accessing Wikiafripedia 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 Wikiafripedia are partially or fully color-blind or visually impaired. Ensure the contrast of the text with its background reaches at least Web Content Accessibility Guidelines (WCAG) 2.0's AA level, and AAA level when feasible (see WCAG's "Understanding SC 1.4.3: Contrast (Minimum)"). To use named CSS colors for text on a white background, refer to Wikiafripedia: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:
    • The Colour 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.
    • You can also use Snook's color contrast tool, which is entirely up-to-date as of 11 January 2015.
    • The Wikimedia Foundation Design team has provided a color palette with colors being marked towards level AA conformance. It is used for all user-interface elements across products and in the main Wikimedia themes, desktop and mobile. However, it does not consider linked text.
    • The table at Wikiafripedia: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's Chrome Canary has a color contrast debugger with visual guide and color-picker.
    • 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.
  • Additional tools can be used to help produce graphical charts and color schemes for maps and the like. These tools are not accurate means to review contrast accessibility, but they can be helpful for specific tasks.
    • Paletton (previously Color Scheme Designer) helps to choose a good set of colors for a graphical chart.
    • Color Brewer 2.0 provides safe color schemes for maps and detailed explanations.
    • There are some tools for simulating color-blind vision: toptal (webpage analysis) and coblis (local file analysis). There are also browser extensions for webpage analysis: Colorblinding (Chrome) NoCoffee (Chrome) NoCoffee (Firefox)
  • If an article overuses colors, and you don't know how to fix it yourself, you can ask for help from other editors. Place ({{Overcolored}} or {{Overcoloured}}) at the top of the article.

Block elements[edit source | edit]

Lists[edit source | edit]

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) or an unordered list. Lists are meant to group elements that belong together, but MediaWiki will interpret the blank line as the end of one list and start a new one. Excessive double line breaks also disrupt screen readers, which will announce multiple lists when only one was intended, and therefore may mislead or confuse users of these programs. Such improper formatting can also more than triple the length of time it takes them to read the list.

Likewise, do not switch between initial list marker types (colons, asterisks or hash signs) in one list. For example, in a discussion, do ☑Y this best practice:

* Support.  I like this idea.  [[User:Example]] 
** Question:  What do you like about it?  [[User:Example 2]]

or ☑Y this acceptable practice:

* Support.  I like this idea.  [[User:Example]] 
*: Question:  What do you like about it?  [[User:Example 2]] 

but ☒N don't do this (switch type from bullet list to description list):

* Support.  I like this idea.  [[User:Example]] 
:: Question:  What do you like about it?  [[User:Example 2]] 

nor ☒N this (switch type from bullet list to description list):

* Support.  I like this idea.  [[User:Example]] 
:* Question:  What do you like about it?  [[User:Example 2]] 

nor ☒N this (leave blank lines between list items):

* Support.  I like this idea.  [[User:Example]]

** Question:  What do you like about it?  [[User:Example 2]]

nor ☒N this (jump more than one level):

* Support.  I like this idea.  [[User:Example]]
*** Question:  What do you like about it?  [[User:Example 2]]

Multiple paragraphs within list items[edit source | edit]

Normal MediaWiki list markup is unfortunately incompatible with normal MediaWiki paragraph markup. To put multiple paragraphs in a list item, ☑Y separate them with {{pb}}:

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

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

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

Definitely do not ☒N 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.

Indentation[edit source | edit]

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

A colon (:) at the start of a line marks that line in the MediaWiki parser as the <dd>...</dd> part of an HTML description list (<dl>...</dl>).[lower-alpha 1] The visual effect in most Web browsers is to indent the line. This is used, for example, to indicate replies in a threaded discussion on talk pages. However, this markup alone is missing the required <dt> (term) element of a description list, to which the <dd> (description/definition) pertains. As can be seen by inspecting the code sent to the browser, this results in broken HTML (i.e. it fails validation[5]). 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 Wikiafripedia's broken markup. This is not ideal for accessibility, semantics, or reuse, but is currently commonly used, despite the problems it causes for users of screen readers.

Blank lines must not be placed between colon-indented lines of text – especially in article content. This is interpreted by the software as marking the end of a list and the start of a new one. If a blank line is needed, place the same number of colons on it as those preceding the text below the blank line, for instance:

: Text here.
: More text.

Another solution is new-paragraph markup, but it must be in one unbroken line in the wiki code:

: Text here.<p>More text.</p>

For more information on the weaknesses of colon-based description list markup – even for actual description lists