Accessibility in the project lifecycle

Accessibility is important at all stages of the project lifecycle. There are clear accessibility considerations you must have when completing discovery, alpha and beta stages. There are also things to consider as part of business as usual once the product or service is live.

Accessibility in the discovery phase

Everyone in the project team should understand their responsibilities around accessibility.

Project managers and product owners need to be aware of accessibility and make time and budget available for this. This may be time with an internal accessibility specialist or an external third party organisation.

Content designers, interaction designers and developers need to be aware of how their choices could impact accessibility.

Training and awareness sessions with the team at this stage will greatly increase the team's understanding of how design influences accessibility.

Accessibility in the alpha phase

You should make sure you test wireframes with disabled people. Certain types of wireframes may not be suitable for testing with users of certain assistive technologies. However, this shouldn't deter you from testing with those users who can.

As a general rule, you can test HTML wireframes with anyone using assistive technologies. It should be possible to test wireframes built in Axure or those which are image only with users of screen magnifiers and users who don't use assistive technologies. If you can't test with a user with a particular assistive technology because of the type of prototype you have, consider alternative ways of conducting the research. For instance, you could try freeform discussion or even mimicking screen reader output. If these alternatives aren't possible, ensure you test with these users as early as possible in the beta phase.

You should also carry out an accessibility review on wireframes and other artefacts.

Accessibility in the beta phase

Testing for accessibility issues should form part of your test cycle at the beta stage. You'll need to buy and configure several different assistive technologies and accessibility test tools for your team to use.

You should run research and testing sessions with users with disabilities. Any findings should be raised as defects and fed back to the project team.

An accessibility audit, or even multiple accessibility audits, needs to be carried out at this stage of the project.

When this phase is complete you should publish an accessibility statement.

Accessibility review

If you're unable to conduct a full accessibility audit, an accessibility review can be carried out instead. This can be done in order to quickly evaluate the accessibility level of a service or product. You can also use it to quickly check the accessibility of a proposed solution.

Accessibility reviews:

• can be faster to complete than a full accessibility audit and don't require the same level of expertise
• can be undertaken with or without assistive technology
• usually consist of a number of high level manual checks, and these checks are designed to identify obvious, high-level accessibility issues
• can be supplemented with automated testing

Accessibility audit

You'll need to ask an internal accessibility specialist to perform your audit. They'll need to have experience and understanding of how to evaluate web content to level AA against the WCAG 2.2 standards.

Alternatively you'll need to ask a third-party auditor to complete the audit. This can cost between £3,000 and £7,000, although for larger services the cost can be greater. You'll also need the internal specialist or third-party to evaluate any fixes you make based on the initial audit and potentially need budget for this.

There are a number of reasons why you might carry out a full accessibility audit such as:

• to ensure you meet the requirements of The Public Sector (Websites and Mobile Apps) Accessibility Regulations 2018 regulations
• to ensure third party suppliers meet their contractual commitments with regards to accessibility
• to determine compliance of services in development
• final confirmation of accessibility compliance before launch

A full accessibility audit can be time-consuming and expensive and will require a high level of technical expertise.

In advance of commissioning an audit, you'll need to identify a representative sample of webpage templates and user journeys. Ideally this will include:

• your website's homepage
• content pages that are mostly text based
• images, video and audio content
• interactive tools and transactions, like forms
• if your website has them, pages including login functionality
• PDFs and other document types you have
• dynamic content like pop-up windows
• navigation pages, including your sitemap and pages with search functionality

Automated testing

Automated testing is really useful for quickly identifying accessibility issues on a page or even across an entire service.

Automated testing:

• can identify issues without needing expertise
• can review large sites very quickly
• can't evaluate all success criteria and therefore should be done in conjunction with manual testing

Read more about automated and manual testing.