Pseudo-Accessibility: Reinventing the Wheel

In my last post, Accessibility and Client Expectations, a major point was on the practice of implementing accessibility as a site “add-on,” rather than developing a web site from the ground up with accessibility in mind. Some of the features which are implemented in this manner fall into a gross category I’m inclined to describe as “pseudo-accessibility.”

In general, pseudo-accessible features are those which:

  • Solve the symptom, not the problem.
  • Create additional accessibility problems in their implementation
  • Reinvent the wheel by duplicating browser functionality

Those of us in the accessibility community tend to agree that there’s a big difference between best-practice accessibility and some of the methods which are most commonly implemented in order to provide it. But it’s important to address in detail why these techniques are flawed.

The most common specific methods which are frequently implemented are probably

  1. tabindex (solves a symptom),
  2. accesskeys (creates additional accessibility problems), and
  3. Text-enlarging widgets (duplicating browser functionality.)

1. Solving Symptoms

The tabindex attribute was created to provide the ability to control the order in which a keyboard navigator might access a website. It’s a great idea, but all it really accomplishes is to allow designers to put documents together without any consideration to a logical source order. It’s entirely unnecessary: a page with a well-designed structure will be easily navigable without any use of tabindex.

What’s worse is that tabindex will, more often than not, actually cause the tab order to be incredibly non-intuitive. Applying a value for tabindex to an arbitrary element will place that element in the very specific sequence which that value specifies, regardless of context. The designer becomes the arbiter of what is most important on a page, because they must decide what element will be visited at what time. If any tabindex attribute is given a value which is not equal to it’s visual order on the page, a sighted user using keyboard navigation can quickly become confused.

Of course, the designer is always making the ultimate decision about item sequence. However, there is no reason to make use of special features in order to make that decision. At best, tabindex will mimic the natural behavior of the cursor; at worst, it’ll cause surprising jumps to unexpected and difficult to locate positions on the page.

2. Creating New Problems

accesskey, like tabindex is an HTML (HyperText Markup Language) attribute which was designed specifically to aid accessibility. Unfortunately, it doesn’t really accomplish its intended goal. There are many, many problems with the accesskey attribute, ranging from problems with discoverability to major keyboard shortcut conflicts.

The discoverability issue is relatively minor. The problem is that many browser fail to provide a way to discover access keys: this is a user-agent failing, and not really the developer’s problem. Worst case scenario: nobody will use them. (It is, of course, open to debate whether anybody really uses access keys anyhow.)

The software conflicts are much more severe. Is it at all helpful to provide a feature which sends somebody to the home page when they press alt + h, if what they really were looking for is help with their user agent? Access keys override the behavior of the user agent. If you break your visitor’s tools; don’t expect them to come back frequently.

3. Duplicating Browser Functionality

In fact, site features which duplicate browser functionality include a huge array of possibilities; but the text-enlarging option is quite probably the most common and least valuable option. Other features which duplicate browser behavior include font selectors and other types of style changers (high or low contrast; alternate layouts, etc.). These types of tool, however, are much less of a concern.

I think many will agree (not all, but many) that there are parts of accessibility which are simply not the responsibility of the site developer. These factors are the responsibility of those who develop the tool which will access the web site, whether this tool is a mobile device, a screen reader, or Internet Explorer. As it happens, most user agents do, in fact, provide the means to manipulate the page pretty extensively. In the case of font-size, it’s pretty easy to do. In the case of selecting high or low contrast styles, on the other hand, it’s a relatively difficult task which is probably beyond the skills of most users. As a result, you have to take the duplication of browser functions on an individual basis.

Creating a site feature to enlarge text is simply a way to encourage site visitors not to learn how to use their tools properly. User agents should make these features as easy as possible to access; but even as they currently exist, they should be an entirely reasonable expectation. Providing the ability to switch between low and high contrast, on the other hand, while entirely possible to accomplish natively with most browsers, is well beyond what I feel any user should be expected to do for themselves.


The best service you can do for your disabled visitors is to avoid creating barriers for them. Any of these so-called accessibility techniques will eventually result in further problems. Even such a simple tool as a font-resizing link is ultimately a disservice; because it may prevent your visitor from understanding what to do when they visit somebody else’s site.

No, they’re not your responsibility when they’re somewhere else. And perhaps if they’re visiting your competitor, you’d rather they weren’t able to use that web site. But just keep in mind that the vast majority of sites on the web are not your competitors.

Have something to contribute?

« Read my Comment Policy

9 Comments on “Pseudo-Accessibility: Reinventing the Wheel”

  1. hi i enjoyed the read

  2. The problem is how we stop preaching to the already-converted, and start converting those who need to be converted!

    Sad, but true. The audience reading this article is probably not the audience which needs to read the article…but reaching the right people (those who care but don’t currently have the knowledge) can definitely be a challenge!

  3. I am forced to sometimes wonder whether the ‘add-ons’ are really added to make the site more accessible or to simply present itself as being accessible.

    Absolutely. The problem is when designers and developers get it into their heads that they need to “do something”. They know that people with poor eyesight can’t read very small text, so adding a text-resizer counts as “doing something” and so they do it. Realising that it was their fault for specifying text as 9pt in the first place is unlikely to feature…

    My first thought when I see this kind of widget on a totally inaccessible page is “What idiots!” … but it isn’t as bad as that. The designers do at least see a need and point in accessibility, even if they don’t understand anything about it. This gives a better chance of meaningful dialogue leading to improved accessibility.

    The problem is how we stop preaching to the already-converted, and start converting those who need to be converted!

  4. “but having it shows that we care about people with disabilities?

    Ah, because of COURSE it’s all about demonstrating that you care. Not about actually caring. Thanks for sharing that!

  5. in response to comment 1, a little anecdote: after a lengthy and fruitless discussion with a member of staff at my day job about why we shouldn’t have a text resizer on every single page, he finally had to concede that i was right…but still said something along the lines of “but having it shows that we care about people with disabilities”.

    so yes, absolutely agree.

  6. Well, this one wasn’t aiming to be particularly controversial… 😉

  7. Another good one Joe. I agree, agree, and, well, agree 🙂

  8. That’s generally my thought — although I’m willing to accept that many people who add these types of ‘add-ons’ sincerely believe that they’re doing what they should.

    I’d like to believe that anybody who really understands how to make a site accessible would only make use of practices which actually help.

  9. Having learned alot more about the reality of disabled access and seen how websites address this issue, I am forced to sometimes wonder whether the ‘add-ons’ are really added to make the site more accessible or to simply present itself as being accessible.

    Just a thought.