Accessibility vs Universality – implications

Mike Davies has stirred up something of a hornets nest with his thoughts on where accessibility as a discipline should be going, especially with statements like The current web-developer focused organisations are tainted, constrained by universality, with sour to nonexistent relationships with assistive technology providers and browser vendors.

This jogged my memory on a post I’d not quite started on the implications of having two camps for accessibility. For the purpose of discussion, the two positions are:

• Universality simply means everyone, regardless of disability. Adherents would include users with slow connections, old monitors, legacy equipment, and anything that puts a barrier between the user and the content they seek.
• Accessibility: ensure that people with disabilities are not discriminated against. Adherants would argue that there is a danger of distorting the meaning of web accessibility because discussions can quickly degenerate to pandering to people’s whims, rather than real issues that affect people with disabilities..

To put this in perspective, I guess I’d better say where I stand.

Taking the fence apart

I’m afraid I can’t say that I’m whole heartedly in either camp. I like Joe Clark’s stance:

I’m all for universality, interoperability, and availability, but it’s not something I want to work on.

I do also work in ‘universality’ as a daily part of my job in web development and consultancy. But, I don’t confuse the two. Any accessibility advice is given in the context of who it would affect (e.g. that type of layout will cause problems for people with screen magnifiers). Best practice advice is given as just that (e.g. validate your code to prevent rendering problems later).

I have to admit, it has been very helpful that several of the WCAG 1 guidelines include things that are more to do with interoperability than accessibility, such as using W3C specs. That has helped eject previous design practices and completely overhaul a site, rather than trying to retrofit accessibility in a piecemeal fashion. It required a learning curve for some, but afterwards they did find it was worthwhile.

These days, most people have dived headlong into CSS based development (but haven’t always taken on the aspects that help accessibility), so using the guidelines as a lever isn’t usually needed any more.

For me, accessibility is a constant, things must be made in an accessible fashion whatever technology you are using.

On the other hand, the importance of universality depends on the context. If you are developing a content oriented site, there is no competition between the perspectives: HTML/CSS is the best tool. If your audience is intended to include mobile usage, there is no conflict. However, if you are building a web application, a learning tool, a game, or anything else that doesn’t fit the usual page model, there could be friction between the two perspectives.

My gut feel is that in 99% of situations, the ‘camp’ you are in will make no difference to a development decision. So when would it make a difference?

Resource and decisions

Ideally, there wouldn’t be a conflict, but what often brings one is the resource available. I can only think of one example where it has made a difference at work, where we produce HTML/CSS based sites, web applications, and the occasional Flash game or demo.

The example was what to do with the WYSIWYG editor in our CMS. There were two options within the time we had available:

1. Use an inaccessible JavaScript based editor, and create a textbox fall-back for ‘accessibility’.
2. Modify an inaccessible JavaScript based editor to make it usable with keyboard access and screen readers.

You’ll note the second option is not a universal one.

I’ve written about the accessibility of WYSIWYG editors previously, and the decision was made to prioritise the quality of experience for people with disabilities, over the (largely theoretical) accessibility for user-agents without JavaScript.

I can wholeheartedly agree with Mike on this:

Web accessibility is not about shoe-horning information into pre-determined technology. Its about making the practical technology selection after considering the content and the intended audience.

There is some grey area that Mike (probably intentionally) doesn’t address. For example, the upgrade cycle required to use the accessibility features of non-HTML formats (Flash, PDF) does hamper the usability of these technologies for some people with disabilities. However, Mike’s article is forward looking, I’m sure that would be a consideration for him as well.

Moving right along

I think as soon as people start understanding the motivation behind the decisions they are making (i.e. not confusing accessibility and availability), this should blow over. You have options, you are in a certain situation, you make a business decision.

Accessibility is legislated for in many areas, and a disability is not something you choose, which is why I consider it a constant priority. If that conflicts with universal access, you’ll have to make a decision.

The usability of accessibility

Something Mike touches on is where accessibility should be implemented:

website builders have an important role, but they cannot cover the entire spectrum of accessibility issues. The user-agent vendors … are also tasked with the responsibility of easing visitor access to content by features such as font-resizing, alternate stylesheets, colour filters, print functionality.

I see this aspect as what really needs evangelism, before too many sites muddy the waters. Text-size widgets crop up in many places, and you can put a strong argument that people don’t know they can change the font size, therefore these help.

I don’t think that is good for accessibility in the longer term, as it breaks the Contract of Trust (great term!), and puts the choice in the wrong place.

To make these type of changes, it will take quite a bit of campaigning, and the type of community that Mike envisioned; including not only web developers, but browser vendors, assistive technology developers and authoring tool developers.