I think we can agree that any website or web application that has been made recently needs some maintenance and updating. Even if it’s architecture is static by itself (for example Gatsby, NextJS, Nuxt etc.), the content is probably very dynamic and owners try to make updates according with their search engine optimization (SEO) strategies at least. Or when for example they get some questions from the public that could already be a part of a website or application (for example in the frequently asked questions).
And with new content, new images, maybe even new widgets and new page templates we must not forget to validate our accessibility efforts towards our accessibility compliance too. In some cases we must also update our accessibility statement.
Design and plan activities – let’s make a plan
Designers (user experience and user interface alike) must take care of basic design accessibility, for example color contrast, font selection and typography, icons should have a complementary text for assistive technology if they are not described by some sibling text elements and so on. Active element’s should have all states defined, so that developer and tester can implement and test them as defined and not forget about them.
First phase – new content accessibility
When authors use their content management system (CMS) they should think of authors tasks for improvement accessibility like alternative image texts, correct headings structure, correct language for page and if needed for some multilingual parts of it and so on. Their CMS should also allow them to check that newly made content is accessible before they are able to publish it. Some automatic tools can be applied, but we must be aware that they alone are not sufficient. Author is responsible to define if image should have an empty alt tag (it is purely used for decoration) or write a decent enough alternative text for it. Automatic tool will fail to identify this as an error. So manual verification is critical.
Second phase – accessibility for new functions (widgets, active elements,…)
When we must implement new functionality, for example our author needs a new accordion or image carousel or some other actionable element or widget, then we should also make sure it is accessible.
Developers should use accessibility linting when developing, and after these basic tests pass – then all functionality should be verified with keyboard too. Keyboard user should be able to use the new functionality and developer must make sure it really works. There are even some rules for keyboard interaction that has to be followed.
W3C released design patterns that every developer should implement when developing new active elements (link opens in new window).
Accessibility should be a part of Definition of Done (DOD) for each task that involves development of new functionality either we are using agile or non-agile project methodologies.
Third phase – end to end (E2E) accessibility testing
With all those phases done we were assuring that elements (units) comply to accessibility, but this is still not a warrant for throughout compliance. Accessibility should be verified also after elements are positioned into page(s) as it’s positioning can cause changes in the tab flow for example. Maybe all it is needed is a skip widget link, but it is still necessary to test pages with new content and new interactive elements in their new context.
Continuous accessibility (CA) phase
Even if our web page or application is simple in it’s architecture – we are probably using some testing environment to test new additions to the site before they are proof-read, spell-checked and tested on mobile, tablet, desktop and screen-reader as well.
So we are probably also using some sort of continuous deployment (CD) and/or integration (CI) behind the scenes. Maybe just a Pull Request (PR) inside our favorite version control software or some content packages being installed.
We should also adhere to some continuous best practices for accessibility. All that can be tested automatically should be a part of CD/CI pipelines, for example to test color contrasts, alternative texts and maybe even some custom accessibility unit tests that can interact with active elements and test if all aria roles are delegated or if state is correctly reflected when element is used and so on.
Test, test and test again. And compare with previous results to measure improvements
As with all testable things – only testing is hardly enough, we must also follow improvements and catch some regression errors to be most efficient.
So past results should ideally be saved and compared to new testing results. Then we could set some key point identifiers (KPIs) that are parallel with our accessibility strategy and work on them. We can follow progress only if we have some historical KPIs to compare to.
Start slow, start where it means most for users
Before we get to the sweet spots of continuous accessibility – to be assured that a wide spectrum of our users can use our online presence / webpage, / web application – we must invest our efforts into most important things first. Where to begin – start fixing things that our users interact most with. Integrate content, design, develop and test routines that integrate accessibility and start with automatic e2e testing that can be quite easily integrated into CI/CD pipelines, so that you will have the ability to implement historical heuristics and a base for your custom KPI evaluations when the time comes.
