How to maintain accessibility long term?
Even the most accessible website, web or mobile application is at risk of 'accessibility erosion'. Every new sub-page, blog article, content or structure update, or even an update to the content management system (CMS) or the library used by the application (e.g. JavaScript) can have the side effect of causing an accessibility problem.
Being aware of this risk is the first step. It cannot be avoided completely, but it can be minimised. But for this, you need a plan.
A strategy for ensuring (and maintaining!) digital accessibility is really an answer to the question "How do we take care of the accessibility of our application?". This answer does not have to be long or complicated, at a minimum it should cover the following areas:
An awareness of what accessibility is and why it should be cared for
Knowledge of how to design, develop and test accessible solutions
A software development process that includes elements of accessibility assurance
Automation of accessibility testing
Accessibility monitoring in production
Regular testing by users with disabilities
Learning from our mistakes
Here are tips on how to put the above points into practice:
An awareness of what accessibility is and why it should be cared for
People who know nothing about the perspective of persons with disabilities will not be able to maintain an accessible application. It is difficult to take care of something you have no idea about.
Therefore, a key topic to address in order to maintain digital accessibility in the long term is education. Basic training for teams or individual employees does not take or cost much (2-3h, a few hundred EUR/USD), and without it all the other activities mentioned in this article have no chance of success.
Those responsible for maintenance must have at least a minimum level of empathy towards people with disabilities and a minimum level of knowledge about digital accessibility. This is a small but most important investment to make to maintain accessibility in the long term.
Knowledge of how to design, develop and test accessible solutions
Every new system functionality, application screen or website subpage should be designed, coded and tested in line with accessibility principles.
Team members, for whom digital accessibility is no longer a new term (see above), can (and should) gain practical skills in this area in a second step. Each role in the company has a stake in the development of accessible solutions and each faces specific challenges - from Product Owner, to Analysts, UX designers, Developers, Testers, DevOps and end-user Support Specialists. It is therefore worth tailoring accessibility training to the specific position and specific needs. Each position in a company or institution means different problems to solve, different sets of tools used and different skills.
The team needs to be trained, but it needs to be done in a thoughtful way:
advise the UX team on how to build accessibility into the design system and work in Figma
show the UI specialists examples of good and bad solutions
give testers practical knowledge on how to check WCAG guidelines and tools to improve accessibility testing
conduct workshops with DevOps on automated accessibility validation and integrate it into the CI/CD pipeline
familiarise the support department with the specific needs of users with disabilities and practice cooperation with them
Armed with such skills, the team will avoid the most common accessibility pitfalls and have a much better chance of maintaining and even improving accessibility in future versions.
IMPORTANT: Both initial and specialised training need to be repeated. Knowledge that is not refreshed evaporates. Also think about digital accessibility training for every new member of your team.
A software development process that includes elements of accessibility assurance
Now that we know what to do, it's "just" enough to do it, right? But how do we make certain things just happen (designing, creating, testing available solutions) and how do not make certain things (accessibility defects)? The answer is process.
The process of continuous digital accessibility assurance can take many forms and use many methods and means. A few of the most common, without going into detail:
guidelines containing good and bad UX and UI design practices
checklists
manual accessibility tests as part of DoD (Definition of Done)
automated accessibility tests - at unit, integration and system levels - more on this below
regular testing and consultation with users with special needs
scanners for monitoring application accessibility in production
regular accessibility audits carried out by people from the organisation or external companies
Each of the above-mentioned activities is a topic for a separate article (yes, we will write about it). Each of them is also a good candidate for an additional step in the software development and maintenance process (SDLC) - a step dedicated to digital accessibility.
If you need help creating such a process from scratch, building an overall testing strategy (not just accessibility) or implementing CI/CD or DevOps practices - we can help with that too, having a lot of experience in these areas.
Automation of accessibility testing
Another degree of initiation and, incidentally, a great optimisation of time and costs. Now that we know how to test (because we are trained) and we do it regularly (because we have a process), why not automate the simplest and most repetitive (and therefore most boring) tests for ourselves? The choice of tools for digital accessibility testing is wide and some of them are free of charge.
However, implementing automation should not start with the choice of tool. You need to think about and define your needs, your budget, take into account the specifics of the product, the technology stack used in the organisation and the tools already in use. The next steps are a POC (proof of concept), a pilot project and at the end a gradual implementation across the organisation. Good practices for implementing tools are widely known and well described, for example in the ISTQB Foundation syllabus, familiar to most software testers.
Automated accessibility testing will not detect all problems and MUST be accompanied by other types of testing, primarily testing with a user with a disability.
Accessibility monitoring in production
The erosion of accessibility mentioned in the introduction is a natural phenomenon, like any kind of erosion. It is difficult to combat, especially if it is not measured. Regular, automatic scans of application accessibility will provide us with information on:
the number of accessibility defects in the production version of our application
the types of these problems
accessibility trends for the whole system and individual modules
All in the form of clear reports that can be configured as desired. Using open source tools, it is also possible to freely extend the functionality of such monitoring by adding, for example, information about WCAG guidelines not being met, recommendations for improvements or translations into other languages.
It is very difficult to maintain the accessibility of large internet and intranet portals, online shops, public, educational or cultural institution websites, where new content and modifications appear almost every day, without correctly implemented monitoring.
Regular testing by users with disabilities
Nothing can replace testing with a real user with a disability. We are not able to simulate a disability, we do not use assistive technologies on a daily basis, we simply perceive the world around us differently and use its digital resources in a different way.
This is why regularly checking the accessibility of the website or application we maintain is a must. Without this, we will never really know if people with special needs can and want to use our product.
Regular testing with a user with a disability does not cost much and can make a real difference. This is especially true when we involve people with experience in such projects - who know how to report their findings in a language that IT professionals can understand.
Disability groups and communities are full of referrals of accessible websites and services, but you will find a lot of complaints there, too. Let's make sure that the application we are developing is in the first group.
Learning from our mistakes
Even with all the mechanisms mentioned above in place, accessibility problems will still occur. There are no perfect solutions and no unmistakable people. So let's create the possibility to easily report digital accessibility problems:
in the customer service (support) department, using, for example, a really accessible form
among those responsible for system development, e.g. by introducing a new 'accessibility' category in the defect handling system (Jira, Trello, Azure DevOps, etc.)
on the accessibility statement sub-page, clearly and transparently stating how this can be done and encouraging feedback
Of course, issues reported through these channels should be corrected and discussed. A retrospective, or lessons learnt meeting at the end of the last project/iteration/sprint/period, is a great opportunity to do this. Reserve time during this meeting to discuss accessibility topics. You could also invite a person with a disability, or consider what skills in this area your team members lack and how to acquire them. Where there's a will there's a way.
As you can see, maintaining accessibility in the long term can be implemented in a number of ways. There is no need to implement all elements at once, it is not even advised. Every single step will be a step in the right direction, towards accessibility. The important thing is not to lose sight of the main objective and to select measures according to the context.
Dariusz Drezno
CEO and co-founder at Accens
Software testing consultant with 20 years of experience. Manager of testing and QA teams. Built testing strategies for major corporations and startups. Co-founder of KraQA, postgraduate studies and testing courses. Standards Development Stewardship Panel Member at SAR.
Maintaining accessibility is a long trip. We are happy to accompany you on it, just as we accompany all our customers and partners. We have experience in each of the areas mentioned above, which we love to share.