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.

Conclusion

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.