Misplaced Pages

Revision as of 02:56, 4 December 2010

This guideline is a part of the English Misplaced Pages's Manual of Style. It is a generally accepted standard that editors should attempt to follow, though occasional exceptions may apply. Any substantive edit to this page should reflect consensus. When in doubt, discuss first on the talk page.

Shortcuts WP:ACCESS WP:ACCESSIBILITY

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. Articles adhering to the following guidelines are easier to read and edit by those Wikipedians with and without disabilities.

Article structure

Lead section

As explained in detail at Misplaced Pages:Lead section#Elements of the lead, the lead section may contain optional elements presented in the following order: disambiguation links (dablinks), maintenance tags, infoboxes, images, navigational boxes (navigational templates), introductory text, and table of contents, moving to the heading of the first section.

Headings

Headings should be descriptive and in a consistent order (See also—References—Further reading—External links).

Headings should be nested sequentially, starting with level 2 (==), then level 3 (===) and so on (level 1 is not used, as this is the auto-generated page title), neither using random heading levels (e.g. selected for emphasis, which is not the purpose of headings), nor skipping parts of the sequence.

Section structure

As explained above for the lead section, each section should have a specific structure:

<!-- CORRECT CODE -->
== Foo bars ==
{{main|Foo bar}}
{{cleanup-section}}
]
A foo bar ...

Note also that the image should be inside the section it belongs to (after the header and after any links to other articles), and not just before the header for similar reasons.

Resolution

Misplaced Pages 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 800x600; 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

1. Spelling errors, such as "initative" instead of "initiative", can dramatically affect the sound of the text when it is read by a speech synthesizer, which can make it more difficult to read.
2. In articles, don't 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 who participate in Misplaced Pages policy and deletion debates are advised to turn on the sounding of text attributes when doing so, as struck text is very common in Misplaced Pages-internal discussions.)
3. Screen readers without Unicode support will read a character outside Latin-1 as a question mark, and even in the latest version of 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. Don't use unpronounceable symbols such as ♥ (a heart symbol); use images with alt text instead.
4. Don't use techniques that require interaction to provide information, such as tooltips or any other "hover" text.
5. When editing, never break up a line unless absolutely necessary, as the easiest way to edit with a screen reader is to navigate line by line.
6. You can change your individual display to show footnotes in full sized text by adding

   .references-small { font-size: 100%; }
   

   to your CSS page

Links

1. Do not overlink. Screen readers put each link on its own line.
2. Create good link descriptions, especially for external links (avoid "click here!", "this".)
3. Avoid putting links in section headings. Some screen readers, such as versions of JAWS prior to 7.1, have significant difficulty correctly rendering such headers. Additionally, special characters such as brackets ("[") and curly brackets ("{") are invalid characters in HTML, which causes section headers to be invalid as HTML anchors. Using wikitext in section headers makes it more difficult to link to them internally as well.
4. Use as little code as possible, so the text in the edit window is easier to read (for example: don't use ] when ]s will work).
5. 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

• WP:COLOR
• WP:COLOUR
• WP:COLORS

Template:Otheruses-section

Colors are most commonly found in Misplaced Pages articles within templates and tables. To view the colors available, see List of colors. For technical assistance on how colors are used, see Help:Using colours.

Articles that use color should keep accessibility in mind, as follows:

• Ensure that color is not the only way used to convey important information. Especially, do not use colored text unless its status is also indicated using another method such as italic emphasis or footnote labels. Otherwise, blind users or readers accessing Misplaced Pages through a printout or device without a color screen will not receive that information.
• Some readers of Misplaced Pages are partially or fully color blind. Ensure that the color combinations used in Misplaced Pages (infoboxes, navigational boxes, graphs, etc.) have an adequate contrast. Use a color scheme generator to select the colors, and tools for simulating color blind vision (colorfilter.wickline.org or vischeck.com) to check the result.
• Be aware of the contrast of both plain text and the red/blue/purple link text with the background and avoid clashes where possible (such as blue writing on a red background).
• If an article overuses colors, an alternative to correcting it is add a tag ({{Overcolored}}/{{Overcoloured}})to the top of the article:

This article may overuse or misuse colour, making it hard to understand for colour-blind users. Please remove or fix instances of distracting or hard-to-read colours or remove coloured links that may impede users' ability to distinguish links from regular text, or links coloured for purely aesthetic reasons. See the guides to editing for accessibility of contrast and colour.

to draw the help other editors to correcting the problem

• Automated contrast and brightness checkers
  • Pages can be checked on-line with AccessColor, which analyzes the HTML source for a web page and the associated Cascading Style Sheets, and then calculates whether the color contrast and color brightness between the text and background colors conform with version 1.0 of the Web Content Accessibility Guidelines.
  • Color contrast for people with vision impairments, including color blindness, can be tested with
    • The Colour Contrast Analyser.
    • The Firefox extension that use the draft algorithms from the World Wide Web Consortium.
• Safe color schemes from maps can be found from Color Brewer 2.0's.

Block elements

Lists

Do not separate items by leaving blank lines between them, even when using unordered or definition lists. If list items are separated by more than one line break, the HTML list tags will be ended, which makes it difficult to read the list with screeen readers. For example:

* One is a good number.
* Two is a better number.
* Three is the best number in the world.
* But the number four should not be mentioned at all costs.

will be read by a screen reader as: "List of 2 items: (bullet) One is a good number, (bullet) Two is a better number, list end. List of 1 items: (bullet) Three is the best number in the world, list end. List of 1 items: (bullet) But the number four should not be mentioned at all costs, list end." Improper formatting can more than triple the length of time it takes to read the list.

Tables

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 hardcoded styles, to create semantic meaning (eg, changing background colour).

The technique of creating a multi-line infobox using matching embedded HTML <br /> tags in adjacent cells creates a visual row not 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. WikiProject Accessibility/Infobox accessibility is addressing this problem.

Data tables

• Priority: high (A accessibility level)
• Difficulty: easy (blend in nicely with editorial habits)

{| 
|+ 
|-
! scope="col" | 
! scope="col" | 
! scope="col" | 
|-
! scope="row" | 
|  || 
|-
! scope="row" | 
|  || 
...
|}

Caption ( |+ )

A caption is a table's title, describing its nature.

Row & column headers ( ! )

Like the caption, these help present the information in a logical structure to visitors. 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.

Scope of headers ( ! scope="col" | and ! scope="row" | )

This clearly identifies headers as either row headers or column headers. Headers can now be associated to corresponding cells.

Misplaced Pages:Manual of Style (accessibility)/Data tables tutorial provides detailed requirements about:

1. Correct table captions
2. Correct headers structure
3. Images and color
4. Avoiding nested tables

Layout tables

Some navboxes, series templates, and infoboxes are made using tables.

Avoid using tables for layout purposes only. The best option is to use HTML's <div> blocks and style attributes because they provide flexibility. For example, see {{Navbox}}.

For simple layouts tables can be an option. Especially if the only point of the table is to get a floating effect, then align="right" etc. will work with some browsers not supporting CSS at all. This is in fact a verbose approximation of <div> plus CSS, and not the design sin known as (nested) "table layout".

However, to avoid accessibility barriers, when using tables for layout purposes don't use any caption, row, or column headers, and also no summary attribute. These structural table elements should be used only for data tables. Don't use structural elements for presentation purposes, use style sheets. For Wiki table markup this means to avoid "!" (= <th> in XHTML) in such cases:

{| class="toccolours" width="94%"
| align="center" bgcolor="#ccccff" | '''Title'''
|-
|  || 
|-
|  || 
|}

For example, see {{Navbox}}

Infoboxes

See the HTML breaks problem.

Other languages

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

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

which renders as

Assemblée nationale.

Images

1. Images should include an alt attribute, even an empty one, 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 should refer the reader to the caption or adjacent text: see WP:ALT for more information.
2. Images should contain a caption, either using the built in image syntax or a secondary line of text. The caption should concisely describe the meaning of the image, the essential information it is trying to convey.
3. Where possible, any charts or diagrams should have a text equivalent, or should be well-described so that users who can't see the image can gain some understanding of the concept.
4. Detailed image descriptions, where not appropriate for an article, should be placed on the image description page, with a note saying that activating the image link will lead to a more detailed description.
5. Images should be inside the section they belong to (after the heading and after any links to other articles), and not in the heading. See Misplaced Pages:Picture tutorial for more information.
6. This guideline includes alt text for LaTeX-formatted equations in <math> mode.

Videos and animations

In order to be accessible, an animation (GIF) should either:

• not exceed a duration of 5 seconds (which results in making it a purely decorative element), or
• be equipped with control functions (stop, pause, play).

In short, most animated GIFs should be converted to video (to learn how, see the tutorial converting animated GIFs to Theora OGG).

Although these are not yet supported by MediaWiki as of August 2010, a video also ought to have subtitles and a text version (alt-text) of its content. A good way to satisfy these needs is to make sure that the information in the video is also present in the prose text of the article.

Styles and markup options

• WP:Deviations

Best practice: Use Wikimarkup and CSS in preference to alternatives

In general, articles should use wikimarkup in preference to the limited set of allowed HTML elements. In particular, do not use the HTML style tags <i> and <b> to format text; it is preferable to use Wiki markup '' or ''', or logical style tags. Of course there are natural exceptions: it may be beneficial to use <u></u> tags to indicate something like an example of an unclickable link. The <font> tag should also be avoided in article text; use logical style tags like <em>, <code>, or <strong> to emphasise semantic differences. Use <small> and <big> semantic tags to change font size, rather than setting it explicitly with the font-size= style attribute.

In general, styles for tables and other block-level elements should be set using CSS classes, not with inline style attributes. This is because the site-wide CSS is more carefully tested to ensure compatibility with a wide range of browsers; it also creates a greater degree of professionalism by ensuring a consistent appearance between articles. Deviations from standard conventions are acceptable where they create a semantic distinction (for instance, the infoboxes and navigational templates relating to The Simpsons use a yellow colour-scheme instead of the customary mauve, to tie in with the dominant colour in the series) but should not be used gratuitously.

Users with limited CSS/JavaScript support

Misplaced Pages articles should be accessible to readers using browsers and devices which have limited or no support for JavaScript or Cascading Style Sheets. At the same time, it is recognised 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 which would cause content to be hidden or corrupted when CSS and/or JavaScript is unavailable must not be used. This includes techniques such as the hiddenStructure method for hiding table content — which produces incomprehensible output without CSS — and some implementations of the NavFrame collapsing code — which can make content inaccessible without JavaScript support. However, consideration for users without CSS or JavaScript should extend mainly to making sure that their reading experience is possible; it is recognised that it will inevitably be inferior.

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

Keyboard shortcuts

Numerous keyboard shortcuts for common Misplaced Pages tasks exist by default. They can be disabled.

See also

• Web Accessibility Initiative (WAI)
• Misplaced Pages:Accessibility advocates
• Misplaced Pages:Using JAWS
• Misplaced Pages:WikiProject Accessibility
• Misplaced Pages:WikiProject Roadmap
• Misplaced Pages:WikiProject Usability
• usability:Accessibility Initiative

References

1. F26: Failure of Success Criterion 1.3.3 due to using a graphical symbol alone to convey information
2. G91: Providing link text that describes the purpose of a link, techniques for WCAG 2.0
3. 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., Techniques for WCAG 2.0
4. Table cells: The TH and TD elements, W3C
5. Setting animated gif images to stop blinking after n cycles (within 5 seconds), A accessibility level
6. Allowing the content to be paused and restarted from where it was paused, A accessibility level
7. The conference about Kaltura's partnership with Wikimedia Collaborating on Collaborative Video for Misplaced Pages announced that video will get "multi-lingual timed text subtitles" in a near future. Alt text was not mentioned and its implementation might not be planned.
8. Providing an alternative for time based media, A accessibility level; Providing an alternative for time-based media for audio-only content, A accessibility level.

• Clark, Joe (2003). Building Accessible Websites. New Riders Press. ISBN 0-7357-1150-X. {{cite book}}: Cite has empty unknown parameter: |month= (help)
• Pilgrim, Mark (2002). "Dive Into Accessibility: 30 days to a more accessible web site". Retrieved 2006-05-07.

External links

• 10 Quick Tips to Make Accessible Web Sites, from WAI
• Colorblind web page filter
• Essential Components of Web Accessibility, from WAI
• Introduction to Web Accessibility, from WAI
• MediaWiki bug 367: Markup accessibility issues (tracking)

Cite error: There are <ref group=WCAG-TECH> tags on this page, but the references will not show without a {{reflist|group=WCAG-TECH}} template (see the help page).

• Misplaced Pages accessibility
• Misplaced Pages Manual of Style (content)
• WikiProject Accessibility