Is Accessibility Middleware Really The Equivalent Of Snake Oil?


Sometimes the Internet is likened to the Wild West, it contains exciting unexplored territory, people have freedom to do all kinds of things and rules are not always rigorously applied.

A cowboy on his horse overlooking a valley in Utah

Photo Credit Mark Gunn

One area where this laissez-faire attitude has significant impact is web accessibility.

The impact of poorly written code and technology implemented without adherence to accessibility standards makes it difficult or impossible for users of assistive technology to make use of many of the things that the Internet has to offer.

This is hardly a new problem, web accessibility guidelines have been around for a long time and are well established (WCAG 2.0 is now an ISO standard). There are a multitude of reasons this (some might say excuses); either people are not aware or do not care about standards or are using tools or CMS/publishing platforms that make it impossible to deliver an accessible website or product.

Accessibility is broken for many people despite a lot of hard work.

Broken pane of glass

Photo credit  Jef Poskanzer

Given the explosion in user generated content on the Internet, this problem is not going away any time soon. So what is the best way to enable people to access services and information online when much of the content and the frameworks are not fully accessible?

How can we fix this thing?

There have been a number of articles written recently discussing the pros and cons of using accessibility add-ons or overlays to add features or fix inaccessible code.

Firstly 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 a Karl Groves post in response  with Adrian commenting on both articles in an update of his original post.

Add-On Accessibility

The current state of web & intranet accessibility is poor and the tools that were discussed in Debra’s article were created in response to a general lack of access.

There are multiple different ways of describing add-on accessibility, middleware or overlays:

The first approach

The “separate but equal approach” of creating a second website accessible to assistive technology users. Like Adrian I am surprised that the 21st-century this is still happening given that creating a second site doubles the workload and usually delivers nothing like an equal experience.

The second approach

Provide embedded assistive technology. I have historically been very sceptical of this approach because if you really need assistive technology in order to use a product or service on the web you are going to need it in order to get to the website in the first place.

Embedding assistive technology into your website is like creating an island of accessibility in a sea of inaccessibility.

Island_near_Fiji

A Desert Island Near Fiji (Source Wikimedia Commons)

Despite this, my line on embedded assistive technology has softened somewhat as products have become available that don’t interfere with the assistive technology that many people with disabilities will have on their own computers.

In limited use cases these tools may have functionality that people may have therefore who am I to say not to use them if they do not break web accessibility guidelines.

The third approach – Cures what ails you?

The issue that has been most hotly debated has been over the concept of products aimed at dynamically repairing accessibility issues in websites whilst leaving the underlying code untouched.

Wormer's Famous Rattlesnake Oil advertisement

Source Wikimedia Commons

These middleware tools and their vendors appear to have a reputation in the accessibility industry as being the digital equivalent of snake oil.

Our Choices

Right First Time

Let me be clear from the outset my preference is for planning and delivering user experiences that are accessible from inception, either by making or buying products that meet standards and have been tested to meet people’s differing needs.

The reality is my preference does not match the day-to-day experience of your average browser user be that on the web at large or within companies intranets.

Fix at source / Fix the Source?

Most people are not building their own websites, they have little or no knowledge of the code that lies beneath. Despite what trends would have you believe most people won’t be learning code any time soon, if ever. They will also not have a clue about accessibility standards, that is a fact of life and it’s not going to change any day soon.

If you thought the internet was inaccessible…

Just wait until you get to look at nine out of ten large companies’ intranets. The tools that are used by organisations for many of their core intranet and business functions, portals and ticketing systems are not the sort of thing that can be easily thrown together.

No Entry Sign

Source Wikimedia Commons

They are usually made by big enterprise software companies and most IT departments attempt to deploy as close to out of the box as possible. Despite that there is a complex interplay of hundreds of dependencies; company IT and Security policies and interdependency with other parts of the company ecosystem including legacy IT.  Unfortunately they are usually not paragons of virtue when it comes to inclusive design.

An oft overlooked point is that companies that implement these systems often do not own the source code they are reliant on the vendors.  Once they’ve signed on the dotted line most of their power to influence that vendor evaporates.

Enterprise IT is a complex and often beauraucratic beast projects cost many millions and run for months and years.

Much as we may want to tear it up and start again…

Sometimes you have to admit that even if you do get the go ahead to fix at source the users may not see the benefit for months or even years.

Given the long lead times and complexity of fixing things in corporate environments I can see how middleware that solves the user access issues is attractive and even a valid choice in certain scenarios.

The vendors of these tools should be upfront about the capabilities of their tools and also the level of knowledge, training & intervention required to set them up so that the problems for users are resolved.

Equally people looking to purchase these tools should not expect a magic wand.

Middleware is not snake oil if:

  • It enables users access where they didn’t have it.
  • It expedites access reducing the glacial time-scales of mega-corporate IT.
  • It does not interfere with existing ATs.
  • Implimenting it helps create processes for handling accessibility issues better in future.

So why does it feel like the accessibility industry is circling the wagons?

Wagons in a circle

Photo Credit Don Graham

Partly I think it’s fear of change – people are used to solving a problem in a particular way.  That way is still valid for individual projects but I want to be open minded and embrace the idea that technology just might be better at solving the problem than we currently give it credit for.

I don’t think it’s because people’s income is threatened because there is plenty of broken stuff to keep everyone in the industry working for years to come.

Accept that we cannot fix accessibility piecemeal.

The greatest technology giants of our time know this and that is why they are looking at using their computational power to solve the problems of inaccessible content:

  • Facebook is experimenting with computer generated image descriptions. I don’t know about you but I don’t much feel like retrospectively writing alt text for the worlds face book feeds.
  • Nor do I fancy writing the transcripts to all of youtube’s content in order to produce captions – the 30 minutes per week that we do for #AXSChat is labour intensive enough as it is.  I welcome Youtube’s effort with auto-captions.  They are far from perfect but I do believe that their approach is the right one.

If technology genuinely removes barriers it’s OK in my book.


 

Why not join the #AXSChat conversations that Debra Ruh, Antonio Santos and I host every Tuesday on twitter or catch up with the video interviews that we’ve done with a wide range of people over the last year. www.axschat.com

Advertisements

3 thoughts on “Is Accessibility Middleware Really The Equivalent Of Snake Oil?

  1. i agree, one area I am wondering is why don’t we have tools which self correct the output during web build phase itself.

  2. The band-aid of having some script running at on the consumer’s browser seems a throwback to the pre-Deming industrial age where inspectors would fix everything after it came off the assembly line. The product really should be shipped with all the screws installed so when I push the button I get an expected result. Allowing client-side remediation shifts the burden to the consumer and 3rd party suppliers to correct other’s bad behavior. The corporate feet are no longer kept to the fire as they can now point to others to patch up their mistakes. Once the fire is out or reduced to embers the urgency to fix the underlying issues is gone and resources will be reallocated to other revenue drivers. Better to clean up the well than to bleach and boil the drinking water.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s