Many years ago I posted about ‘subscription accessibility‘, where sites pay a third party service to enable accessibility features for users. It came up again recently with a different service (Handtalk) for providing automated sign language.
If you are a site owner there are two questions to answer when considering adding a service for accessibility purposes:
1. Does it improve the experience for anyone?
In this case I’m not sure, a couple of years ago I looked around for automated sign-language solutions and talked to some people who are deaf (via their interpreter) during some testing we were doing.
At that time they were very dismissive of automated solutions, they tend not to be that clear, it is the equivalent of the robot-voice of a screenreader compared to a live person. For most it didn’t provide anything above reading text.
Handtalk may not have been around back then so perhaps it has improved the situation. I’m skeptical though, partly because sign-language has many local variations. UK and US sign language are completely different, and I assume Spanish (the native language of the Handtalk site) is also very different. Would it be good for a UK audience?
2. Should it be provided by the website, or the user’s software?
Handtalk may be a wonderful service for a certain slice of the population, but why stop there? Shouldn’t you also provide:
- Text size widgets (for visual impairment)
- Colour scheme changers (for visual and cognitive impairment)
- An easy read scheme, adding pictures associated with every concept on the page (for cognitive impairment / learning difficulties)
- An audio read-out (for visual and cognitive impairment)
- A zoom widget (for visual impairment)
Your website ends up with a huge toolbar at the top, which creates an accessibility issue for keyboard users having to tab past them on every page!
I find the business model of selling a solution to websites when it should be on the user’s computer counter-productive. Unless they were on every website an individual user will not have come across it, and would have to go through a learning process. 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.
If these widgets were on every website they might as well be built into the browser, in which case the websites wouldn’t need to show them! Handtalk make several mobile apps, why not a browser plugin that has the same functionality as the site service?
For a practical ‘what should the site owner do?’ recommendation, mine would be:
- Make sure the website is as intrinsically accessible as it can be, which is difficult enough for large websites.
- Include help pages that include accessibility information, linking people through to a general help aimed at all types of disability such as Sky’s or BBC’s help.
All of those tools work better if the website is built to (W3C) standards and to be accessible, but the responsibility for the ‘user agent’ (browser, screen reader etc.) is the users, not the sites.
Must there be an either-or answer to this question? Might it not be possible for both approaches — assistive technology from the website owner AND from the end user– to have merit in different situations?
I could imagine a web user who does not self-identify as disabled, and is therefore highly unlikely to install assistive software. That same user might be more inclined to employ a site feature, especially if there is no associated disability label.
I could also imagine a corporation being more willing to fund a highly visible toolbar, rather than back-end work to follow WCAG guidelines. A toolbar might be funded from a corporation’s marketing budget rather than a legal/compliance budget. I see more avenues for funding of accessibility as a good thing.
If the end goal is to get more web users the assistance they need, why not take an “all of the above” approach?
I’ve seen people who do self-identify as visually impaired ignore/miss text-sizing widgets. The point is unless they are universal then people don’t understand them. If they were universal, why have them on the site, why not the browser?
On the budget point, the toolbars generally need the site to be well coded (i.e. accessible) in order to work properly, so if anything it would be less budget to just make the site accessible.
NB: The budget for accessibility should really be part of the design & development budget (i.e. built into the projects), rather than tacked on later under compliance.
Why not do “all of the above”? It becomes a diffused effort, and the effort on the toolbars is generally wasted. It smacks of being seen to be accessible rather than really helping people.