Accessibility testing should be done as part of the Definition of Done.

  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 - Automated

  1. Check 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 in early 2017).

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

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

Checklist - Manual

  1. Screen reader UX - Check the screen reader UX is met.

  2. Accessibility acceptance criteria - Check the accessibility acceptance criteria is met.

  3. Design - Are elements styled correctly? e.g. Do links use the standard link colour and have the standard associated hover and focus styles?

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

  5. Colour blindness - Use the ChromeLens dev tool extension to view the code with different vision issues. Can all elements in the feature still be identified and used?

  6. View the feature with High Contrast mode on PC. Can all elements in the feature still be seen? Can you identify links etc.? Go to the ‘Personalization’ settings in the Control Panel and view the feature with all the different High Contrast modes.

  7. View the feature with the colour preferences changed in FireFox. Can all elements in the feature still be seen? Can you identify links etc.? Go to the ‘Preferences’ under the ‘Firefox’ menu, then under ‘Language and Appearance’, select ‘Colours’ and change the colours for text, background, unvisited and visited links, then select ‘Always’ for ‘Override the colours specified by the page with your selections above’. After testing, you will need to restore the default colors.

  8. View the feature with text resized to 200%. Can all elements in the feature still be seen? Go to the browser preferences and set the font size to the largest default setting.

  9. View the feature with the page zoomed to 200%. Can all elements in the feature still be seen? To zoom the page on Mac, press ‘CMD and +’.

  10. Does the design use icons? Meaning should not just be conveyed with icons/images, do the icons have off-screen (visually hidden) text so users of assistive technology don’t miss out? Check by inspecting the element in the web browser or with a screen reader.

  11. 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.)

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

  13. 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. Check interactions can be controlled when using only a keyboard.

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

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

  14. Has the feature been considered 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.

  15. No CSS - Disable CSS and check core content is accessible when styling is unsupported or removed. You can use a tool such as the Web Developer add-on for Chrome or Firefox to disable CSS.

Checklist - Assistive Technology

Test with Supported Assistive Technology, using an actual device if possible.

The accessibility acceptance criteria can be used for manual testing steps on device, this is written by the Business Analyst and part of their checklist.

  1. Is the feature useable?
  2. Does the feature make sense?

Checklists for other roles in the team