Web Accessibility Commentary

In the past year, I've become more exposed to web accessibility and its importance in the digital landscape. It's obvious to state that accessibility is not 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. In the web realm I view this as referring to equal access to content and services for all.

If I was to make a guess, I would assume that most people's (indirect) introduction to web accessibility probably stemmed from defining alt attributes in <img> tags. I've included an example below:

<!-- Even just from the mark-up, we have enough context to understand what it should render -->
<img src="20231122.jpg" alt="An olympic white Fender Stratocaster guitar" />

Though we were probably not aware of how this aided assistive technology users, we saw how this extra piece of textual content proved helpful in scenarios where the visual content was obscured (i.e. an image fails to load on the webpage -> the webpage fallbacks to rendering the alt text).

In the very same way, this obscurity is encountered by assistive technology users when browsing the web. 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 complex, but it is important.

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?

To sidetrack briefly, I remember coming across some funny content online that highlighted the importance of integration testing in addition to unit testing.

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

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 (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 being fatally 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 appears 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 aurally - but we need to bridge the gap and make a conscious effort to design for all.