Accessibility should be considered from the start of development and throughout the process.

  1. Are you aware of the BBC Accessibility Standards and Guidelines? Some simple quick checks are outlined here, please refer to the guidelines for in depth information.

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

To gain an understanding of accessibility features and what to look for it is 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.

Checklist - Before development starts

  1. Has there been an Accessibility Review for the product feature? (Part of the design checklist). Question/Check the design you are working from. Are elements styled correctly? e.g. Do links use the standard link colour and have the standard associated hover and focus styles? Do all elements meet colour contrast levels? Use a tool such as contrast checker to check. All colours should meet a level of 4.5:1 or higher.

  2. Does the design use icons? Meaning should not just be conveyed with icons/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?

  3. Consider the mark up. Semantic HTML should be used, this way you get accessibility from the start.

Checklist - Throughout development

  1. Use a linting tool with accessibility rules added to catch errors as you develop, for example if using React, the jsx-a11y ESLint plugin should be installed in your module if it isn’t already.

  2. Check the accessibility of the rendered DOM. Use a tool such as the Axe browser extension.

  3. Turn CSS off in the browser. Does the page make sense, is it easily understandable? Is the correct mark up used for the correct elements? e.g. If there is a button, is it marked up as a button? If there is a list, is it marked up as a list? Do components have headers? Use a tool such as the Web Developer add-on for Chrome or Firefox to easily turn CSS off.

  4. Have you considered the page without javascript? It should degrade gracefully. Use a tool such as the Web Developer add-on for Chrome or Firefox to easily turn Javascript off.

  5. Keyboard navigation

    1. Check the tab order is correct when using the keyboard and the tab key. Can you see where you are on the page at all times? You are looking for styling in addition to the browser default styling (such as the blue outline), such as change of colour to text links combined with an underline. Focus styling is usually the same as the hover styles. e.g Has focus CSS been written?

    2. Is the keyboard focus always in the correct place? e.g. After selecting a ‘More’ button with the return key you should be taken to the new content displayed with the next press of the tab key.

    3. When using ‘Trace tab path’, the path 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). Use the ChromeLens dev tool extension to trace the tab path.

  6. 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.

  7. Use VoiceOver (Screen Reader) on iOS (iPhone/iPad) during development. It’s a lot more effort to fix bugs after you are code complete. If using VoiceOver for the 1st time, see VoiceOver iOS testing steps.

Checklist - Before code merge

  1. Manually check the heading order. Do the heading and the heading order actually make sense? If working on a foreign language site, use Google Translate to check what the headers actually say. You can use a tool such as the Web Developer add-on for Chrome or Firefox. (Under ‘Information’ select ‘View Document Outline’ - This will show you the heading structure for the selected page.)

  2. Colour blindness - Use the ChromeLens dev tool extension to view the code with different vision issues. Let UX know if there are some concerns.

  3. Specifically check your code for errors against BBC Accessibility Standards, either by using bbc-a11y in the terminal or by using the bbc-a11y Pa11y Dashboard (Dashboard to be released early 2017).

  4. Test with Assistive Technology that we support

  5. Automated testing with SHIVE (HIVE for Screen Readers) - Have cucumber tests been written against the accessibility acceptance criteria? Note, SHIVE is not yet in production, however the tests should still be written so you are ready to go when it is.

  6. Have End to End Tests been written to cover accessibility? A tool such as Axe, can be integrated, for example if using React, via React Axe or the bbc-a11y CLI could be used.

Checklists for other roles in the team