Best practice - Waterfall projects

If you’re building software using a waterfall process, then you must make sure you account for accessibility in the process.

Accessibility needs to be budgeted for and you need to be realistic about how long it will take to deliver a product which is accessible.

Requirements

When doing requirement gathering, accessibility must be included. If the product is not compliant with the Public Sector Bodies Accessibility Regulations then it will be breaking the law.

Design

In the design phase, you should have an understanding of how you intend to make your product accessible. The elements of the user interface should be well defined and any impact they may have on accessibility should be understood.

If you do not know exactly how something is intended to work, you should not progress to the build phase. If you don’t know exactly how it works, you won’t be able to make it work as expected on assistive technology.

Build

When you’re building your product, you should test it for accessibility as you go. Developers should be using browser plugins and automated tools to make sure there are no obvious mistakes.

You should do a manual assessment of each page against the WCAG 2.1 A and AA criteria and you should also make sure each screen is usable with a keyboard and with common assistive technologies before deciding that it is done.

You will also need to publish an accessibility statement before the product goes live.

Test

Before the testing is signed off, you will need a full accessibility evaluation. This is to make sure it is technically compliant with WCAG 2.1 to the standard of AA.

Because products built using a waterfall process are large, a third party audit would be recommended.

Any accessibility issues found in the test phase will need to be fixed before the product goes live.

Maintain

Once the product is live, if you make any updates to the UI then you will need to complete the accessibility testing again.