Edit page

Web accessibility

Why web accessibility matters #

Everyone experiences disability in some form throughout their life including permanent, temporary and situational types of disability. This is why it matters that everything we create for the web is as easy to use as possible so that no one is excluded from using a website because of their disability.

It also matters because making online public services that meet WCAG 2.2 level AA standards is a legal duty under the Accessibility regulations.

Design for accessibility #

Test early and often in the design and prototyping stages to identify problems because they are often harder and more time-consuming to resolve later on in the development phase.

Develop for accessibility #

Whether working on an existing codebase or starting an entirely new project, everything should be accessible to WCAG 2.2 level AA. This includes any plugins authored outside dxw.

Accessibility testing #

Everything we create for the web that involves user interaction should be tested for accessibility. Testing may also be necessary during routine maintenance and for any updates or changes to a website. There are also guidelines applicable to authoring tools such as WordPress and other content management systems. Authoring tools need to be accessible, so that people with disabilities can create web content as well as consume it.

Automated testing #

For automated testing you should be able to identify around 50% of code-based accessibility issues. You must also follow up these with manual tests. A couple of extensions you can install on your browser for automated testing include:

Manual testing #

Manual testing needs to identify whether a website is accessible with or without use of assistive technologies. In your testing you need to identify any traps, barriers or challenges which make a website hard or impossible to access.

Guides manual testing #

There are a couple of helpful tools available for performing manual testing. These provide visual helpers to help your assessment and keep a track of all completed or outstanding tests.

Prepare to spend anything upwards of one day, to a week, to perform manual testing comprehensively depending on the size of your project or task. Try to test with real devices, as opposed to emulators, where possible including:

Browser/screen reader combinations to include in your testing procedure:

Mac #

Windows #

iOS #

Android #

Each screen reader comes with a variety of different keyboard shortcut commands and dialogues to help navigate and interact with a website. Screen Reader Keyboard Shortcuts and Gestures by Deque University provides specific guidance on how to use them.

Magnification and viewport size #

Part of your testing also needs to identify any failures for a website to resize and reflow the text and layout sufficiently to a zoom level of up to 400% and smaller viewport sizes down to 320 CSS pixels. This helps support people with low vision who need to enlarge text and read it in a single column as well as anyone who browses with a mobile.

Fixing accessibility issues #

Accessibility issues found need fixing before going live. Be sure you fully understand why an issue isn’t accessible before finding ways to resolve it. Once you’re confident with the changes made then restart automated and manual testing for the affected pages or component that the issue is present in.

Prioritisation #

Ultimately you should be looking to resolve all accessibility issues. Where there are time and budgetary constraints, then prioritise those which have the highest level of user impact, such as critical or serious. Add any unresolved issues to an accessibility statement with explanation for when you anticipate they will be fixed. Every release must be accessibility tested.

Assignment #

It’s the responsibility of everyone on a project team to understand how accessibility impacts on their role from managing a project to designing, building and maintaining it. Communicate often with your team and include accessibility in decision-making at all stages.

Further information #


Last updated: 6 October 2023 (history)