Accessibility

Universal access should not be an afterthought. Guidelines and pre-launch checklists for minimum WCAG 2.0 AA compliance.

Guidelines

The two most widely-used guidelines are WCAG 2.0 and RNIB's Surf Right (based on WCAG). You are expected to know and understand WCAG 2.0 and build to an AA conformance. WCAG is bloated and exhaustive, so Surf Right is recommended for learning and checking your output.

Best practice

Accessibility is a huge topic and this document won't attempt to cover everything. Read and re-read Techniques for WCAG 2.0. However there are some common misconceptions, often flagged by automated testing tools, that you should be aware of:

  • Only rarely should you need to use a title attribute. On a link don't be tempted to repeat the same content as the link text, or alt text of an image. Use it to supplement with extra detail if appropriate.
  • Only rarely should you need to use an image alt text (in our type of work). Mostly they'll be blank attributes. If you have a linked heading and an image, wrap with a single anchor (valid in HTML5) and no need for alt or title attributes
  • "JavaScript isn't accessible". It is. Screenreaders sit on top of browsers, so if your browser can render it, screenreaders can see it. If you add content with JavaScript use the focus/tabindex method to notify the user.

Tools

  • HTML5 Outliner (Chrome extension) adds a button to reflect the heading hierarchy of a page.
  • Accessibility Developer Tools (Chrome extension) adds an Accessibility option to the Profile tab in Dev Tools for running common checks against a page.
  • Web Developer (Chrome extension) adds a toolbar to manipulate page, outline links etc.
  • Colour Contrast Checker for testing text contrast on backgrounds. Note the comment about "large text" being 14px bold or 18px not bold.
  • Colour Oracle (OSX) and Sim Daltonism (OSX) are colour-blindness simulators
  • Validity (Chrome extension) lets you see validation errors in the developer tools console.

A quick checklist

The following is a quick list boiled down from Surf Right. Checking these issues should see you conforming to AA level.

Headings

  • Headings are in a logical, consecutive hierarchy (h1–6) and make sense out of context.
  • Only content headings are marked up as headings (not simply "stuff that's big fonts in the designs").

Metadata

  • Every page has a unique title that accurately describes the page content.
  • The page has a valid DOCTYPE, character encoding and language.
  • The page is valid HTML.
  • The page has a default lang attribute.
  • Any changes in language are marked with a lang attribute on the respective element.

Tables

  • Tables use separate cells for individual data items.
  • Table headers use th, rows and columns use scope attribute.
  • Tables have summary and/or caption elements where appropriate.

ARIA

ARIA refers to a set of attributes that communicate role, state and property semantics to assistive technologies—via the accessibility APIs implemented in browsers—that can be added to HTML elements.

The W3C HTML specification now contains ARIA information in the introductory section of each element definition.

Structural elements

  • List markup is used whenever items are in a visual list.
<ul>
  <li>Thing</li>
  <li>Another thing</li>
  <li>Last thing</li>
</ul>
<ol>
  <li>First thing</li>
  <li>Second thing</li>
  <li>Third thing</li>
</ol>
<dl>
  <dt>Term</dt>
  <dd>Definition</dd>
  <dt>Another term</dt>
  <dd>Another definition</dd>
  <dt>Final term</dt>
  <dd>Final definition</dd>
</dl>
  • Quotations use blockquote and cite elements (and these are used for quotations only).
<blockquote>
  <p>Link colours are HARD.</p>
  <cite>Andy P III</cite>
</blockquote>
  • Emphasis is achieved using em or strong.
  • Abbreviations and acronyms use abbr the first time they are introduced on a page; don't be tempted to use acronym – it has been dropped from XHTML2 and HTML5.
<p><abbr title="HyperText Markup Language">HTML</abbr> is great.</p>
  • Blocks of repeated content (e.g. primary navigation lists) can be bypassed with a skip link (although it's worth noting that user testing at The Guardian revealed that ARIA landmark roles are simpler and more widely used for jumping to content).
  • iframes have descriptive title attributes describing the content being loaded with alternative content if appropriate.
  • Use ARIA landmark roles on major page sections:
    • banner for global site header
    • navigation for any type of navigation construct
    • main for document body, use only once
    • complementary for sections related to the main content
    • form for a region that contains a complete form
    • contentinfo for a region that contains metadata about the page (author, company info, copyright etc.)
    • search for the primary search form

Text

  • Text colour has sufficient contrast for legibility.
  • Where background images are used, a fallback colour of sufficient contrast is also present in case the image doesn't load.
  • Text can be resized up to 200% without the design breaking.
  • Links are styled differently to surrounding text.
  • Links have different focus states so are clearly visible when tabbing through the page.

Images and media

  • Informative links have alternative text accurately conveying equivalent information.
  • If an image doesn't need alternative text, leave a blank alt attribute.
  • If text is too verbose, use the longdesc attribute.
  • Audio/video is static on page load and user has a way of pausing it.
  • Audio/video has text alternative, linked to immediately next to the media.

Forms

  • Labels are accurate, well-positioned and describe the field.
  • Labels are explicitly associated with the field (by ID preferred, implicit by wrapping not always sufficient).
  • Use fieldset and legend to ground fields together.
  • Instructions for completing the form are clear and complete.
  • Instructions for completing or correcting a field are placed before the field itself.
  • Suggestions for a correct format (e.g. email, postcode) are provided if specific formats are asked for.
  • Mandatory fields are marked as such.
  • User should have a way to review the content before submitting (controversial? does client side validation satisfy this?).
  • CAPTCHA challenges have text description of contact information to obtain human help.
  • Use native controls wherever possible rather than custom widgets. ARIA roles only go so far.
  • Anything that is keyboard focusable has a focus state (i.e. don't use outline: none;!).
  • All interactions should be executable with the keyboard; focus is in a logical order (think focus and touch, not just click).
  • There are no keyboard traps where focus can't be transferred without a mouse.
  • All links have text content (alt text on images counts as link text).
  • Link text makes sense out of context (i.e. no "Read more" or "click here").
  • Flashing and blinking content can be paused and controlled by the user.
  • Auto-updating content can be paused and users are notified when updates occur.
  • select elements that cause context change have submit buttons rather than onchange events.
  • The user is forewarned of any new windows opening (e.g. title text notice).

Objects and scripting

  • Inaccessible embedded objects have accessible alternatives that serve the same purpose.
  • Objects/components for decoration are hidden from assistive technology (e.g. aria-hidden).
  • Downloadable files are also accessible and content is in text format with sufficient colour contrast, change of language etc.
  • Things work without JavaScript (forms, important links, content) (RNIB recommendation only).

Resources

References