Let’s get on the same page here…
If you follow many developers or web designers on Twitter, you may have seen the following tweet:
There’s a lot to unpack in that statement. And oh the unpacking that people did… My Twitter timeline was a flurry of rants both for and against the statement, and many of those tweets came from people with no context of the talk the slide was from. We’re collectively great at getting mad on the Internet, aren’t we? (FYI, I threw a stone through my glass house while typing that.)
[Quick aside, Nolan Lawson, the person who gave the talk, posted a great follow-up article titled: Progressive enhancement isn’t dead, but it smells funny. I suggest you read it.]
I want to talk about this for a bit; but before I do, I want to define two terms that will play important roles in this article.
Accessibility means everyone (but specifically people with disabilities) has access, the ability to use, and are not barred from the benefit of products, services or information because of special needs or disabilities. On the flip-side, accessibility does not mean that everyone has identical access.
An accessible interface can be interacted with and its content can be consumed in a variety of ways. Whether that be via keyboard instead of a mouse, via screen readers and audio descriptions of what would otherwise be primarily visual content, or transcripts of audio and video. Regardless of the means, an accessible interface ensures that all users get the same information and can perform tasks that lead to the same outcome. (e.g. mouse click or hitting Enter both activate links.)
One of the most common physical examples of accessibility is stairs and ramps. They both allow entry to an elevated entryway, but each provide different pathways to get there.
2. Universal Design
Universal design may start with a focus on creating accessible experiences, but its focus is not solely on users with disabilities. Instead, universal design promotes the idea that products, services and information should be usable to everyone, regardless of disability, age, or technological limitations.
An interface that adheres to universal design principals should inherently be accessible, since the UX and technology decisions behind it are focused on comprehensive usability.
Now one of the most popular physical examples of universal design is a curb cut (ramp). This incline in the curb enables people in wheel chairs to cross roads without requiring assistance to get down or back onto a side walk. But it also makes crossing the road easier for people riding bicycles, pushing carriages or carts, and those using walkers.
With those two terms squared away, let’s get back to the question at hand…
Well, as is typical of most development questions: “it depends.”
A failure of everything
Until recently, I thought so. My reasoning being that while sighted users have a few visual cues as to what’s going on in these sorts of situations, users with visual impairments may not. A loading indicator in the browser’s address bar may still be spinning, indicating that something isn’t loading quite right. Or the fact that sighted users can immediately see an empty, unstyled white page when they might otherwise know that the page they were attempting to access normally has a different background color, or, you know…content.
Visually impaired users may not get as much context. A screen reader might return a message like “HTML content is empty”, or “[Browser-name] is busy” but that doesn’t immediately explain what has happened or why. Is the page empty now, but I just need to wait for it to load? How long is this going to be busy for? What is the problem?
And that’s what my hang up was. It was the lack of immediately understandable context that had me thinking this was an accessibility issue. But, I was mistaken.
In my opinion, just because this isn’t an issue of inaccessibility that doesn’t make it OK. A complete failure of loading any content is still a frustrating user experience, and definitely should be considered a universal design issue. There are methodologies one might be able to implement to mitigate this sort of scenario. I suggest reading up on not-so-new topics like progressive enhancement and graceful degradation, off-line first, and service workers to see paths that could be applicable if you currently find yourself in an all-or-nothing situation with your own project.
I’d talk about them here, but that’d be a bit off topic. Since we’ve identified that this scenario isn’t an accessibility failure, what would constitute as one?
Let’s take a look at the following example:
aria-expanded="false" will convey that the element this toggle controls isn’t open, even if a user does actually use a mouse click or the Enter key to trigger the link, activating the
:target pseudo selector that opens the menu using CSS alone.
Finally, the hard coded
aria-hidden="true" on the
<ul> will ensure that even if a user does get the menu open and tabs into the list of links within, those links won’t be announced.
- trapping user focus in an element
- overwriting expected keyboard controls
- moving focus or loading new pages without user initiation
Steve Faulkner may have said it best: