Web accessibility commentary

In the past year, I've been more exposed to web accessibility and its importance in the digital landscape. Accessibility isn't a new concept: the UK has the Equality Act 2010, and the US has the American's Disability Act of 1990 which both state the right to equal opportunities for people with disabilities. On the web, I view this as the right to equal access to content and services for all.

If I had a guess, I'd say that most people's (indirect) introduction to web accessibility likely stemmed from defining alt attributes for <img> tags. Here's an example:

<img src="20231122.jpg" alt="An olympic white Fender Stratocaster guitar" />

Now without even seeing the image, we probably have enough context from the alt description to infer that it's supposed to render a guitar — a white Fender Stratocaster even!

At the time, we may not have realised how helpful this was for users relying on assistive technology. We simply saw how alt text was useful when an image failed to load — giving us some idea of what was supposed to be there.

But this very obscurity is the everyday experience for many assistive technology users. For sighted users, we can easily "crawl" through the contents of a site and quickly garner an understanding of what we're looking at. However, imagine a hypothetical scenario where all the web content has failed to load. If a webpage has not been marked up in a sufficient way with web accessibility in mind, assistive technology users will encounter limitations that will make digesting the contents of a webpage difficult and, at times, even impossible.

Website content requiring assistive aid goes far beyond just images; even before Web 2.0, there were headings, links, forms, etc.. In the current decade, you have more dynamic content in the form of modals, notification elements, countdowns, carousel components, etc. which gives rise to a whole host of problems to solve to make them accessibly coherent. Furthermore, it's not just mark-up which is important, but the user experience that assistive technology users go through.

Getting this right is hard, but it matters.

In my opinion, there's currently an issue with how we are approaching this. It's all very good to strive for making web content more accessible, but I think it falters when the main cohort of developers, or even accessibility reviewers, are not active assistive technology users (me included). As developers, we can read up on the WAI-ARIA specification and implement our code to satisfy the criteria. As reviewers, we can verify that the component checks off everything in our guidelines and is coherent when parsing it through our reviewing tools. But is this sufficient?

Let me sidetrack briefly. I once came across some funny content that really drove home the value of integration testing in addition to unit testing:

And another one from Twitter: 2 unit tests. 0 integration tests

It's a good analogy. I raise this because I view the current issue in a similar way. We praise the importance of having integration tests as we know that something could test well in silo but could go wrong when used in composition with other components. For instance, you could have a button that functions correctly and passes your unit tests (i.e. you click -> something happens -> nice!). But what if in the actual environment the button is hidden in view behind some other content and so is never visible to the user?

If we only view making our content accessible by going through a checklist of criteria, we end up with something that is technically correct and "web accessible". But without focusing on the actual experience as a whole, we could end up with something that just doesn't work practically and ends up ultimately being detrimental to the user experience.

As a developer, I have unknowingly written code that has contributed to a poor web experience for users who require assistive technology. Using a screen reader has provided me with exposure to these problems first hand. There have been times when I've shut off the screen reader whilst testing because of its annoyance. But this freedom to revert back to a "normal" way of browsing isn't possible for people who are reliant on assistive technology.

As creators, the work we produce needs to look good visually for sighted users, but it also needs to make sense in the lens of an assistive technology user. I think this is an important point to make as the majority of us are geared towards making things look "pretty" (which is normal!) but are not aware that what we create may not "look pretty" for a screen reader. We can add fancy layouts and clean animations to spruce up the design, but if it's difficult for a screen reader to crawl through your content in a coherent way, you're leaving a set of users in the dark.

It may appear like there's an inverse relationship between pretty visuals and accessible content, but I don't believe this to be the case. We are able to meet the needs of both types of users without compromising the other. We can create "pretty" content for all — both visually and audibly - but we need to make a conscious effort to bridge the gap for all.