Be Wary of Add-on Accessibility
When I say “add-on accessibility,” I am referring to web sites that use custom tools to try to address accessibility gaps. Typically this is done in place of a team writing code that is accessible on its own. This is usually because the team doesn’t have the accessibility skill, a company is concerned about lawsuits, or a well-meaning stakeholder is trying to do the right thing.
Two Common Methods
I’ve encountered two techniques that vendors offer when pitching their accessibility solutions to existing sites, neither of which require the site owner to change much, if any, of their existing code. After all, it’s a pretty compelling solution when you’re promised legal compliance with little to no work from your development team.
1. Separate Site
One approach is the completely separate site. Harkening back to the text-only version of sites in the mid-1990s, companies slowly discovered that maintaining two separate sites with the same core content was impractical.
In fact, I did not think this practice existed any longer except as parody. As recently as last year, Léonie Watson found a site relying on this approach:
Closer inspection did indeed reveal the presence of a “link” leading to an alternate version of the website. It’s been years since an alternate version of a website was considered a reasonable (or even necessary) way to provide accessibility. Apart from building websites like it’s 1999, it’s the antithesis of progressive enhancement.
Many accessibility professionals see this as a
separate but equal approach and are understandably uncomfortable with it, as this image from Patrick Lauke demonstrates:
Sometimes an add-on takes the form of a toolbar or widget that might adjust change contrast or allow a web page to speak its contents to you, among other features. Typically these are not built by the site owners, but are embedded from a third-party source. Often they duplicate (or conflict with) existing assistive technologies that users may already have.
Sometimes these are developed by the site developers, commonly in the form of text sizing widgets or color switchers. There are some common interface elements (such as a button with a larger letter or plus sign, and another with a smaller letter or minus sign), but for the most part these are different from site to site.
One example of a third-party tool is Browsealoud, which speaks the content of a web page (from a section defined by the site owner). Another one is Hand Talk, which will present content in sign language via a Flash-driven animated avatar (that helpfully shows advertisements while it loads).
Both of these methods (separate sites and toolbars) suffer from a common failing — namely that the stakeholder who commissioned the feature is probably not qualified to verify that it works well or at all.
Sure, the toolbar or separate site may address some issues in a compliant way, but it likely doesn’t flow well with the entire experience. It’s possible it even conflicts with the assistive technology the user already has.
Using a third-party add-on also means that the team responsible for the site not only doesn’t have the opportunity to develop new skills around accessibility, but that the team might even consider accessibility to be something that can be addressed by throwing some money at a vendor.
Money coming from a budget that could be used for accessibility training.
Does it improve the experience for anyone?
This isn’t just a question of whether or not it’s well-implemented. Sometimes a user isn’t willing to waste time on a tool that might make it difficult to revert, and so documentation and support must be considered.
Should it be provided by the website, or the user’s software?
From usability testing, we know people ignore an unfamiliar widget in the top of the page and get on with their task using the main content, even if the widget would help them.
What Motivated This
Seriously, it has been the low-hanging fruit of a public-facing site that got rave reviews while completely failing at accessibility. I’ve written about it before, it has been a staple in my talks, and it even was the impetus for me to create a handy bookmarklet. I’m not the only one who thinks it’s a cluster.
While casually perusing the Virgin America site last week I discovered that a new link has been added, visible when tabbing through the page, the offers a link to an
assistive view by Sunday night) of the site, built by a third-party.
assistive version is not accessible.
For a sighted physically-impaired user who relies on keyboard navigation, the “assistive version” is not helpful, and the main site persists in blocking these users by continuing to use the
outline:none declaration for elements that have focus.
Don’t be Virgin America.
Update: November 10, 2015
Jennison Asuncion points out (LinkedIn-free version) that airline web sites must be accessible by December 12, 2015 — or just about a month from now. SSB Bart Group outlines the core features of a site that must be accessible next month (such as booking a flight or checking in), and outlines what can wait until December of 2016 (just some leftover marketing pages at that point).
It’s possible Virgin America paid for the third-party solution in an effort to make the deadline. Sadly, if nothing improves between now and next month, Virgin America will not be compliant and may have to throw more money at an already sub-par solution.
Update: Also November 10, 2015
Today Smashing Magazine has kicked off a UX review series starting with the airline industry. Virgin America’s site ranked well, but no consideration of accessibility was mentioned anywhere. So I got ranty in the comments.
Update: November 13, 2015
Too good not to add:
I suppose I shouldn't find it surprising that snake oil salesmen are also comment spammers. pic.twitter.com/674V9eQP7O— Karl Groves (@karlgroves) November 13, 2015
It’s a screen shot from The Legal Intelligencer with a comment from Nate Bradley, in all-caps, saying that NBA can fix this lawsuit by using AudioEye. Full comment (don’t need to get past paywall to see it).
Update: Also November 13, 2015
Karl Groves was also inspired by Virgin America’s broken site to write his own perspective. His is more direct than this post and he also spends more time explaining some of the accessibility failures of the
assistive version of the Virgin America site: When the treatment is worse than the disease
Update: January 8, 2016
Debra Ruh explores the benefits of one kind of add-on, with examples, in her article Should Accessibility Overlay Tools Be Used as a Strategic Part of your Accessibility Efforts. Karl Groves responds to that post specifically: On Overlays as a means of resolving website accessibility issues.
Update: January 19, 2016
I forgot to link to my 2014 post Patents versus Accessibility — Again, where I identify a patent to automagically make sites accessible by a company that itself would have benefited from such a tool. If it’s not clear from that statement, I am of the opinion that any web site that misses the low-hanging fruit for accessibility is not qualified to apply some magic tool to anything and expect it to fix accessibility issues.
Update: April 4, 2016
Virgin America is getting bought. Hope they don’t average the accessibility efforts between Alaska Air and Virgin America.
Well this is one way to deal with Virgin America airlines's terribly inaccessible website https://t.co/io3mcMCgTi— Karl Groves (@karlgroves) April 4, 2016
Update: April 17, 2016
I neglected to mention that you should point to these broken examples of accommodations made specifically for self-identified screen reader users whenever anybody asks about detecting screen reader users. There is ample evidence to show that you’re better off just fixing the main site instead of providing a broken alternative. Read my post On Screen Reader Detection
Update: December 14, 2016
Today there is a post from Jeffrey Zeldman, In Defense of Font Size Widgets, suggesting that we should consider going back to using bespoke text resizing tools on sites.
If you want to give them a whirl, by all means go right ahead. I only ask that you track their use with Google Analytics or similar and make a commitment to remove them after some period when you find they are not used. Having built many over the years, I am confident you will find they are mostly ignored.
If you built your site well, then all the text sizing control users need is built into their operating system and their browser. There is no need to develop a brand new interface on yet another site for them to replicate what they can already do natively.
Instead, use that time to fix known accessibility issues in your site. It isn’t as satisfying and you do not get to point to a shiny widget to show how you care about users, but it is likely a better use of your time and real users will really benefit.
Update: December 15, 2016
I penned a response to the renewed call for text sizing widgets: Don’t Re-Create Browser Features
I use the broken example from the New York Times to demonstrate how it can easily go wrong.
Update: February 11, 2018
Remember that add-on tools can be attack vectors.
ALL website's currently using the @texthelp "browsealoud" plugin (which claims to make websites more accessible with speech, reading and translation tools) are currently infected with a #cryptominer #InfoSec #CyberSecurity #coinhive
Actually, if not taken as a wannabe-assistive technology, BrouwseAloud can be useful to users. Some of our goverment sites added BrowseAloud not to replace screen readers, but to help those who are illiterate or low-lettered, Dutch as a second language, dyslexic, or for whatever reason can understand the page better when it’s read to them who are not themselves screen reader users.
The real question for stuff like that then is, how many people choose to use it? (it has to be invoked.)
A few years ago a client chose to embed Browsealoud (their capitalization, I checked) on its site. The client was pretty excited that now it would be accessible, even though it already was. In that case, the client bought into a product for the wrong reasons.
After about a year the client was able to check if anyone had used it (I think Browsealoud made that number hard to get, but my memory could be off) and other than the first couple days that it was posted, it went unused.
So yeah, I can see a use case as you suggest, but too often the lack of understanding of the issue (if any) coupled with lack of measuring use means these add-ons are often wielded in a way that only hurts their perception and/or benefit.
On the flip side, I have used Browsealoud to read a page while washing dishes.
Forcing users to use a separate site is equivalent to electronic segregation, while implementing “toolbars” is equivalent to hiring a 4th grade tutor, who helps kindergartners read, to read web content aloud to it’s user. And this 4th grade tutor, who has only been in business for the last 4 months, knows more about what you want to do online than you or your professional application does, which has been in business for over 20 years, and will override your applications hotkeys if it tries to step up and perform it’s functions.
Yes, some of the toolbars are getting better about working with other programs. Don’t assume users want guided assistance, just assume they want to actually browse your site on their own. Users have their own tools to use, each setup with different configurations, and toolbar implementations disrupt users ability to use/navigate your site properly.
[…] Be Wary of Add-on Accessibility – Adrian Roselli – http://adrianroselli.com/2015/11/be-wary-of-add-on-accessibility.html […]
[…] there was Adrian Roselli’s post Be Wary of Add-on Accessibility” followed by Debra Ruh’s article on accessibility overlays in the Huffington Post and then […]