1. Audio & Video

Making audio and video content accessible helps users who are deaf or hard of hearing. We provide a text alternative and ensure clear audio recordings.

  • Audio quality: Audio meets basic quality standards.
  • Text equivalent: Audio and video files have transcripts or closed captioning.

2. Text

Accessible text helps users who are blind, color blind, or low vision, by making it possible to access content using a screen reader, braille output, screen magnification or understand instructions in a way that doesn’t rely on visual attributes.

  • Typeface selection: Select a limited number of typefaces that are simple and easy to read.
  • Font variations: Limit the use of font variations such as bold, italics, and ALL CAPITALS.
  • Text size: Avoid small text size and control size using relative units such as “em” and %.
  • Scalable text: Text can be resized up to 200% without loss of content or functionality.
  • Images of text: Avoid images of text, except for logos.
  • Color contrast: Ensure sufficient color contrast between text and background.
  • Animation: Avoid blinking or moving text.

3. Color

People with visual impairments experience limited color vision and cannot depend uniquely on color clues for meaning or instructions.

  • Contrast: Color contrast meets WCAG AA contrast ratio.
  • Color to convey meaning: Information conveyed with color is also conveyed by other means, such as text.

4. Graphics and Non-Textual Information

Accessible graphics and non-textual information help users who are blind, color blind, or low vision, by making it possible to access content using a screen reader, braille output, or understand instructions in a way that doesn’t rely on visual attributes.

  • Text equivalent: Images and non-text elements have a text equivalent.
  • Animated content: Provide pause, stop, or hide functions for moving, blinking, scrolling, or auto-updating information.
  • Blinking/flickering: Avoid flashing images and content.
  • Shape or location to convey meaning: Information conveyed with shape or location is also conveyed by other means, such as text clues.
  • Icons: Avoid relying on icons alone for navigation and information.
  • Timed response: allow user to request more time.
  • CAPTCHAS: CAPTCHAS should be avoided, unless other programmatic alternatives have failed.

5. Navigation and Links

All functionality is operable and accessible through a keyboard interface, voice control and a screen reader.

  • Drop down menus: Users can access menus and sub-menus without a mouse.
  • Skip link: A mechanism is available to bypass blocks of content that are repeated on multiple web pages.
  • Descriptive links: The purpose of each link can be determined from the wording of the link text alone. (e.g. “Click here to download brochure” should be replaced with “Download brochure“).
  • Focus order: Tabbing through links and input fields on a web page follow a logical order.
  • Show focus: There is a visual indicator on a selected link or input field that marks the current location on the page.
  • Image maps: Assign alt text to each image map “hot spots” on client-side image map.

6. Forms and Tables

Forms

Forms should allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.

  • Labels: All input fields have labels are marked up with <label for=”the_form_field_id”> to associate them with the form fields.
  • Focus order: Tabbing through input fields, the input fields and drop down menus order follows the visual layout.
  • Selection: Changing a form element and not clicking submit or pressing enter should not reload the page.
  • Selection: Changing a form element without removing focus from the field should not change anything on the page.
  • Error identification: If an input error is automatically detected, the error is described in text and screen readers are notified of the error.
  • Additional content: Instructions, warnings, or other annotations in your form will only be read by screen readers in forms mode if you use WAI-ARIA markup.

Tables

Tables are used for displaying tabular data only, using appropriate table tags.

  • Table tags: Each row and column has a <th> (table header) row, associated with the appropriate row or column using the “scope” attribute.
  • WAI-ARIA: Use WAI-ARIA landmark roles as appropriate in your table.

7. Page Structure and Semantic Markup

One way to insure accessibility is utilizing correct semantic markup, which basically means using the right HTML tags for the right jobs.

  • Compliant HTML: Use well-formed, semantically correct, compliant HTML5.
  • Page titles: Web pages have titles that describe topic or purpose of individual page.
  • Headings: Section headings are used to describe sections of a web page.
  • Language of page: The default human language of each web page is programmatically determined.
  • Elements: Use existing elements instead of creating new ones (e.g. Buttons). If you must create fake buttons or links, add the appropriate WAI-ARIA and JavaScript to give them all the same accessibility of the native elements.
  • Double-Scroll: Avoid a scrolling area within a scrolling window. It also creates a usability issue on mobile devices.
  • Frames: If frames cannot be avoided, label each frame. Labeling each frame helps users with screen readers identify and navigate frames.

8. Scripting

Javascript / AJAX

Surveys show that well over 90% of screen reader users browse with JavaScript enabled. While writing a page that works minimally without JavaScript is a best practice, it is not an alternative to creating an accessible JavaScript page.

  • Trigger: All JavaScript events which trigger on mouse movement should also trigger on keyboard movement.
  • Elements: All fake HTML elements (e.g. buttons, links) need to use WAI-ARIA roles to tell the keyboard and screen reader to treat them as if they were native HTML elements.
  • Keyboard focus: Be very careful about capturing the keyboard focus or creating keyboard shortcuts that override existing keyboard shortcuts.
  • WAI-ARIA: Use WAI-ARIA to tell the browser when a dynamic page is updating.

Adobe Flash

Despite the problems Flash can introduce for screen reader users, there are techniques to make Flash content and navigation more accessible, such as text equivalents and keyboard accessibility. Because Flash is not supported on many mobile devices, the use of Flash should be limited to those circumstances where there is no alternative. See WebAIM’s Creating Accessible Flash Content.

Plug-ins

All external tools / plug-ins must be accessible to the main assistive technologies (screen readers, voice control, keyboard input).

9. Accessibility for Mobile

A future phase of this project will target some of the unique accessibility requirements for mobile, but following the guidelines for “Web Accessibility” above will increase mobile accessibility by many folds.

Meanwhile, we can refer to the draft of the BBC Mobile Accessibility Guidelines for guidance.