I’ve previously discussed the pitfalls and false claims of all those per-site accessibility tools that claim to make your site more accessible. To be blunt, I think the vendors of such products are criminals for selling products that are proven to have little to no benefit. Their customers are duped into believing that the product will solve their website’s accessibility problems. These claims are unquestionably false.
The code is where accessibility happens and so long as companies’ budgets are being diverted to ineffective products, these budget dollars are not being used on things that matter, like training developers and remediating their sites.
This is based on the three very clear facts: First, Text-only is not accessible. Second: products that don’t address the site’s specific code failings are useless. Third: Adding new & different accessibility problems is a net-negative to the user.
When is something accessible?
At a very real level, a website is accessible when people with disabilities can use it. That seems a bit vague, but it helps to understand that something is “accessible” when all people, regardless of disability have equal access to the same information, features, and services as everyone else. That seems a bit of an unattainable goal in some cases, and likely not attainable depending on what the actual website is all about. That being said, there’s a distinct difference between being pragmatic and being dismissive of basic human rights.
One thing is for sure, any solution that doesn’t seek to address all users’ needs as completely as possible is very definitely not a useful approach. For instance, a product that “reads” the content aloud can, at best, assist users with cognitive impairments. A product that creates a text-only view of the site is, at best, a solution for people who are blind. In both cases, it betrays a lack of understanding of these users’ methods of using the web. A user who needs the content read out aloud will need that on all sites, not just one. As a consequence they will already have the necessary assistive technologies to facilitate this. A product that creates a text-only representation of the site probably won’t effectively remediate any structural or content-related issues inherent to the text material itself.
In other words: as I’ve said before, any money spent on such products is money that could be spent remediating the underlying issues.
You should definitely avoid making your problem worse
Screenshot of the Virgin America “assistive” version, as created by UsableNet
Today, Adrian Roselli pointed out that Virgin America has made the mistake of allowing UsableNet to create an “assitive version”. This version is, obviously, intended to help Virgin America airlines flight search more usable for people with disabilities.
It is great that Virgin America want to help their customers with disabilities, especially because their website is dreadfully inaccessible. The front end runs on Angular and it is impossible to use with a keyboard. Hunch tells me that a fair amount of their accessibility issues can be fixed by properly including ngAria. Instead, they’ve chosen a solution that not only fails to address their code-level shortcomings but also doesn’t meet the core requirements for accessibility.
The first observation one can make about this “Assistive” version is that it is extremely plain looking. Some might claim that it is OK for it to look plain – after all, its intended users are people who are blind. But that isn’t true:
The footer from the Virgin America “assistive” version, created by Usable Net
This makes it clear that UsableNet markets this as a solution for low-vision users as well, as they provide options for text resizing and color/ contrast enhancements. But if a user needed these features, they’d need them on all websites and, in fact, every application on their computer. In other words, these features are useless.
The plain appearance is a symptom of shortsightedness and a misunderstanding of accessibility and users with disabilities. It is born from the belief that we can somehow organize people into distinct boxes into which they all fit neatly. “Disability rarely travels alone” is a message we try to convey when doing training. It is not at all uncommon for people to have multiple motor or sensory impairments that mean a “solution” focused on only one of those impairments is not useful. Before you discount that as “rare”, keep in mind the total number of people with _any disability in the United States is 12.6 million. However, adding up the number of all disabilities is 17.9 million. In other words, there are 5.3 million people in the United States with more than one disability. The total number of people with more than one disability is _more than twice_ as many as those who are blind. (Source DisabilityStatistics.org). _
There are more than twice as many people with cognitive impairments than there are people with visual impairments, and other than greatly simplifying the design, this “Assistive” version does absolutely nothing for such user. In fact, it is arguably worse, because the only mechanism provided to group content together is through headings. The lack of distinct and obvious visual feedback when activating controls on this screen would make this worse for such users.
This takes us to a discussion of why this “assistive” version is, at best, a marginal increase in accessibility for sighted keyboard-only and non-sighted screen reader users. The single reason that this is better than the main Virgin America site is because the Virgin America site is among the worst experiences for these users that I’ve ever seen. It is beautiful, interactive, and incredibly inaccessible. It is the poster child for what not to do when it comes to accessibility. However, under normal conditions, the “assistive” version would probably be a step backwards for these users.
To demonstrate what I mean by it being a step backwards, I created the video below. This video demonstrates using the “assistive” version with the VoiceOver screenreader with Safari. While there are a ton of small nitpicks that I could make, the biggest problem has to do with the user knowing what the heck is going on. Every time a choice is made on the fields on the form, it causes a page refresh. This is actually a violation of WCAG SC 3.2.2. Changing the value of an input should not cause a change of context. While UsableNet is attempting to manage this by putting a named anchor on the link they’re exhibiting a failure to understand how users interact with the site. I’m on a 50Mbps FiOS connection and yet the round trip to redisplay the page is long enough that a non-sighted user is likely to have already tabbed elsewhere. This is because the expected interaction from the user’s perspective is that once they’ve made their choice on a form field, they expect that activating the Tab key will take them to the next control on the form. Instead, tabbing causes “hocus focus” – the focus goes back to the top of the page. UsableNet has assumed that the user knows the page is going to refresh, which is not the case, or that the refresh will be fast enough that their named-anchor trick will work, which is also not the case.
This practice is even worse when you consider the very first set of radio buttons. This is possibly the best evidence that UsableNet’s developers don’t know what they’re doing. The expected keyboard behavior of a radio button set is such that once the set has focus, arrowing through each radio button also selects that radio button. This, in turn, causes the page reset. In other words, once you get focus on one of those radio buttons, you can’t even explore the options without causing the page to refresh!
Finally, you’ll notice that the error handling is terrible. Actually, if you’re a blind user of this application, the error handling will appear non-existent. On one screen, it asks for a promo code. When I attempt to submit the form without entering the promo code, it triggers an error. However, the only notice that there’s an error is that they append the word “Required” next to the field label. Since that text isn’t programmatically associated with the field, the user will have to hunt around the text on the page to find that single-word message. The message itself is merely in bold text and therefore non-blind users will have a hard time noticing it as well!
In short: add-on accessibility is a sham. Whether it is something like AudioEye or even an apparently “custom” solution like UsableNet, they are terrible. They fail to provide anything beyond a marginal benefit for the end user and are, at best, a band-aid over a gaping wound. Virgin America, and companies like it, would be better off spending their money educating their design and development staff on accessibility than wasting their money on snake oil solutions made by amateurs.