Is it Accessible?
If you follow many developers or web designers on Twitter, you may have seen the following tweet:
No! Just because bigger companies have websites that don't work without js or css, doesn't mean you should do it too #fronteers #a11y pic.twitter.com/Na8FGEqMWA— Local Developer (@LocalSourceNL) October 6, 2016
[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 level set a bit with the two following terms, “Accessibility” and “Universal Design”.
Accessibility means people have access to, the ability to use, and are not barred from the benefit of products, services or information because of special needs or disabilities. Note: accessibility does not mean that everyone has identical access. That’s not actually possible. However, it does mean that while access may not be identical – the end goal must be as equal as it possibly can be.
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 can begin with an emphasis 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 even technological constraints.
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 for everyone.
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 sidewalk. 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…
<dialog>), we can provide expected keyboard functionality and semantic intent to assistive technologies (ATs).
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 going 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 can 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’s not what this post is about. 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:
See the Pen JS-reliant Accessibility by Scott (@scottohara) on CodePen.
aria-expanded="false" will convey that the element this toggle controls isn’t open (i.e., “expanded”), even if a user does actually use a mouse click or the Enter key to trigger the link, activating the
:target pseudo selector that reveals the menu with 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 attempts to navigate to the exposed content, those links won’t be properly exposed.
- 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: