Design with accessibility in mind from the start.

Some simple quick checks are outlined here, please refer to the BBC Accessibility Standards and Guidelines for in depth information.

Do you have an understanding of what Assistive Technology we support, such as screen readers? And how to use this?

For an introduction on accessible thinking see the How to Design for Accessibility guide. It is also recommended to attend the Accessible UX course and complete the Accessibility for Web Developers (Internal BBC link) online course. The Introduction to Screen Readers (Internal BBC link) course would also be very useful.

Design checks

For designs created using Sketch or Photoshop etc.

Checklist - Throughout the design process

  1. Are elements styled correctly? e.g. Do links use the standard link colour and standard associated hover and focus styles? A consistent experience is good for accessibility.

  2. Do all elements meet colour contrast levels? Use a tool such as Stark a contrast checker for Sketch, or online tool such as Contrast Checker to check this. All colours should meet a level of 4.5:1 or higher.

  3. Does your design work for colour blindness? You can use a tool such as Stark a color-blind simulator for Sketch, or alternatiely view code or drop a jpg/gif of your design into Chrome and use the ChromeLens dev tool extension to view your design with different vision issues.

  4. Does your design pass the Dos and Don’ts of Designing for Accessibility?

  5. Have you considered the page without javascript? It should degrade gracefully.

Checklist - Before design sign off

  1. Accessibility design review - Get your designs peer reviewed, from a champion in the product/feature team, before sign off and/or development starts.

  2. Does your design use icons? Meaning should not just be conveyed with images, do the icons need some off-screen (visually hidden) text so users of assistive technology don’t miss out? If so, what would this text be? Discuss this with the development team.

  3. Think about the HTML, and discuss this with the development team before coding starts. How will this be marked up? Have you thought about the heading structure? Do you know what heading level your headings are and how this will fit into the rest of the page? Do you need to use any ARIA? For example, ARIA can be used simply to add landmarks/regions to a page or more advanced usage can help with dynamic content and advanced user interface controls such as tabs. For examples see ARIA Authoring Practices. Note ARIA should be used sparingly.

  4. Have you thought about keyboard navigation, is the tab order logical? e.g. When using the keyboard and the tab key, the tab order should go from left to right as you work your way down the page (there will be some exceptions to this order, such as when the ‘Breaking news’ banner is on the page).

Checklist - When on test or live

  1. Test your design with assistive technology, such as a screen reader, VoiceOver on iOS (iPhone/iPad) is recommended, does the feature make sense? If using VoiceOver for the 1st time, see VoiceOver iOS testing steps.
  2. You can use the bbc-a11y Pa11y Dashboard to check for code errors against the BBC Accessibility Standards. Note passing the standards does not mean a product is useable. This dashboard is to be released early 2017.

Checklists for other roles in the team