What is web accessibility, and what does it mean to make your web pages accessible?
For people embarking on the journey of making a web page accessible, here is a short introduction with some notes about the things you'd want to pay attention to. I'm also going to explain what the work entails, as I notice many developers, let alone non-technical managers, don't quite understand what's involved.
This post is aimed at both the technical and non-technical people. Therefore, I'm omitting many of the actual nitty-gritty that goes into the work that I do as an accessibility consultant.
Note that in this post I will use the term 'web page' to refer to either a web application or a web site. It doesn't really make that much difference from the web accessibility perspective.
The conflict of insight
Before we start, let me first point out the obvious. Accessibility assessment of your web page brings about various insights about how you develop it. Every insight is a driver of change. After all, gaining insight means gaining a new way of looking at things, and this means change by definition. It will test your organization's ability to adapt, and the organization member's willingness to introduce changes. In other words, it will very likely lead to conflicts.
One thing that you might need to adjust to is that what you see with your own eyeballs is not the end of the story. The same thing on the page may be used in radically different ways by people with reduced visual ability, or may even be completely useless.
Insight doesn't come equally and equally quickly to every organization member. People closer to the action will usually gain it faster, but that's also not necessarily the case. People may not be interested in the topic, or may not see it as affecting their work. Other people may simply be uninformed. For any web accessibility project to be successful, insights must be propagated to everyone that even remotely touches the project.
The insights
One day, about a decade ago, a lady from the management contacted me and informed me that a blind user tested an app I was working on and were quite happy with its usability. This was the first time I had any contact with the topic. Before that, I haven't really thought much about blind people using computers.
When I started learning web development back in 2002, I was learning from an online resource that heavily stressed the importance of semantic HTML, and did a wonderful job of explaining the concept. It also helped that content semantics was something I was involved with even before that through my work as a book designer. If there was one thing I was doing right from the very beginning, it was the correct usage of HTML to my web pages. The reason the app worked well for the blind person was that it was coded using bog-standard HTML with correct semantics (for the most part).
But that's me. I was lucky. People getting started today will be lucky if they get any kind of introduction into HTML semantics, let alone the kind of intro that would insist on it.
The first step to web accessibility is therefore that we — sorry to say — learn about how wrong some of things we do are. I'm nog going to sugar-coat this one because if we need to sugar-coat this, then we won't make it too far anyway. The success of the effort largely depends on whether we embrace this as a learning opportunity or refuse to accept that what we have been doing is in need of... serious improvement.
Accessibility is for everyone
I remember the day when my webmail app updated with some major accessibility overhaul. For me personally, the impact was quite dramatic. Although I haven't had much trouble using it before, the new version was quite a bit clearer, easier on the eyes. I felt a sense of relaxation as my eyes no longer had to work so hard to see the text. This was quite a revealing experience to me.
You will hear accessibility people harp on this point probably more than anything else. Accessibility is not just for those with disabilities. It is for everyone.
You will sometimes hear me use the term "reduced ability" instead of "disability". To me, the term "disability" sounds like a complete lack of ability. You either are or aren't disabled. In real life, ability is more like a scale. Take vision, for example. How many people do you know who have perfect vision? Most of us are at least partially disabled, if even a tiny bit. This is why I prefer to think in terms of different levels of ability.
Even though users with reduced ability may use accessibility technologies such as screen readers, many users will use generic equipment as well. On the other hand, some users may use accessibility technologies even though their abilities would otherwise permit them to use computers without them.
When it comes to screen readers, for instance, they are not only used by people who are legally blind, but also people with poor vision, or even people who simply want to listen to the content because they are temporarily unable or unwilling to look at it.
Keyboard use is a more obvious example of a device used equally by users of different levels of ability. While keyboards are a lifeline for most users with reduced ability, they are also used by a wide range of users most of whom have average-to-great ability. It's also a commonly neglected aspect of modern user interfaces.
The zoom feature on the browser are used not only to improve perception for those with reduced visual ability, but also by those with good-to-excellent visual ability to address specific viewing conditions such as being further away from the display, or wanting to see better a small detail on the page.
An accessible web page is therefore, one that can cater for a wide range of abilities and situations. We cannot simply assume an "us vs them" mentality when it comes to accessibility and address only one group of people (e.g., blind) while ignoring others (e.g., poor vision, poor motor ability).
Accessibility isn't a bolt-on layer
I remember when I first heard the term 'accessibility', it was in connection to the ARIA attributes, and I suppose that's how many people get introduced to it today as well. People think — or rater hope — that accessibility is something we can bolt onto the existing code without changing much in the existing code. Add some ARIA attributes to the existing markup, and it's all accessible all of a sudden.
Sadly, it doesn't work that way.
For example, many developers copy CSS from UX design tools like Figma. One consequence of such code is that it makes the page unresponsive to changes in the base font size set by the user.
Another example is the lack of understanding about what responsive actually means. For instance, developers will usually protest that 320px screen size is "too narrow even for a small mobile phone". However, 320px is the width is the same as zooming in 400% on a 1280px screen, and 1280px isn't that small.
Not placing headings in their correct semantic order is a very common mistake I find in code bases.
These mistakes are, in my experience, not honest mistakes or oversights. They are the result of a fundamental misunderstanding of how the underlying technology is intended to work and/or how it impacts the end user. A lot of the accessibility work is therefore an exercise in correcting such misperceptions. As such, it's a more profound change, both to the code and the way developers working on the code approach problems.
I've seen companies selling "accessibility components" that supposedly magically improve the accessibility of your pages. I would advise you to stay away from them. There is no magical way to fix broken code without... well, fixing the broken code. And there's certainly no magical fix for the misconceptions about technology.
The same goes for most 3rd party components or component libraries. Virtually all of the ones I've had the displeasure of trying had various accessibility issues, some literally preventing users from completing critical tasks in the apps.
Although I'm not sugar-coating the fact that there is no easy way out of accessibility issues I also believe they present worthwhile learning opportunities for those that truly care about the craft. Once we start to unlock the depth and breadth of the web technologies, things become quite fun. And if you ask me, if it's not fun, it's not worth doing. 😉
Accessibility cannot be automated (fully)
Although there are tools that perform automated accessibility assessments, they are not able to catch all accessibility issues. Such tools can uncover roughly 20~25% of all accessibility issues. The remainder requires manual assessment using screen readers, different browsers, and human expertise.
There are many accessibility criteria that are not quite clear-cut. They only apply under some conditions, cannot be easily determined because of the flexibility of the web UI presentation logic, result from the sequence of actions rather than a snapshot of the UI at any given time, are related to content (e.g., poor wording), and so on. To this date, no tool or AI has been able to surpass a human in performing these assessments.
Still, some automated assessment is better than no assessment. The WAVE is freely available as both an online tool as well as a browser extension (Chrome, Firefox, Edge). There is also a paid WAVE API that can be deployed on our own infrastructure to perform accessibility tests in, say, a CI/CD process. The Playwright test tool also provides integration with AXE accessibility testing. The Lighthouse tool in the Google Chrome and Chrome-based browsers will also provide you with some accessibility checks.
As I said before, though, don't over-buy into automated accessibility testing. They are just a quick check for some a smaller number of issues that can be machine-detected. Human assessment and developer training are still a much more effective solution.
Accessibility project workflow
The first step to doing any accessibility work is the assessment.
I normally start with the automated tools and write down the issues found by the tools. This is usually quick, and even for sites that are quite inaccessible, they don't take a lot of time.
The second pass is using different browser / os / screen-reader combinations, and using the keyboard to navigate the page, perform the usual tasks, etc. This step is time-consuming and relies a lot on familiarly with the site. Therefore I will do the second pass multiple times as the project progresses. The work is very similar to what a QA does, but starting from scratch.
Once the first iteration of the assessments is done, then we proceed to fix the code.
Usually, the fastest way is to get the entire team onboard with the effort and brief them about the discovered issues, and then solicit suggestions for changes, but this depends a lot on the availability and team structure, as well as their goodwill. Usually, developers don't like to be told that they messed something up, so it takes a lot of assurance that the goal is not to hold someone accountable, but to fix the issues. This is where managers get tested on their leadership abilities.
A lot of the times, however, developers are simply tied up in their own work, and the accessibility consultant is asked to implement the fixes. I should mention that this is the most expensive option, for three reasons:
- It means additional consultancy fees (be my guest, though).
- Accessibility consultant is an expert in accessibility, but not necessarily your code base. It will take significant time to get familiar with the code base before they can fix something.
- Accessibility as a whole is not only the responsibility of the consultant alone, but the entire organization. Even if the fixes are implemented, ensuring that the site stays accessible is still on the organization, and it's ultimately the organization that is responsible to its users.
The way I work, the whole process takes several iterations to complete. This is especially true if there's a need to roll out accessibility fixes alongside new development.
Maintenance
As I've hinted a few times, accessibility is an on-going effort. Even after all the accessibility work is done, if the team is not trained in maintaining and doing quick evaluations, the site will deteriorate back into the previous state. Accessibility work is about gaining insight, and insight always brings about change. If change is not embraced, things soon go back to how they used to be, despite the best efforts.
At the very least, regular accessibility assessment should be done every time there is a change in the user interface, and the discovered issues should be treated as blockers.
A better solution would be to provide accessibility training for all developers working on the UI. For experienced developers, this only takes a few days of light lectures, and they will be able to take it from there. For less experienced developers, some hands-on training, preferably on the code they are working on, is a better option. Full participation of the team during accessibility improvements is ideal.
Conclusion
I hope all of this information helps you get some idea about what accessibility work entails, and what you can expect. If you have any additional questions, feel free to get in touch, and I'll be more than happy to chat with you.
