Mar 17, 2010
Web Accessibility Preferences Are For Sissies?
Several years ago I read an article by Garrett Dimon titled “User preferences are for sissies” (available at archive.org, also see this 37signals article). The general idea is that when you present preferences to the end user it typically indicates that you screwed up or are a sissy – either you are forcing the user to account for a poor design or usability decision, or you are too indecisive to make the decision to begin with and thus place the burden to decide upon the user.
In general, I believe that web accessibility preferences are no different.
Important Clarification
I’ve found that some have misinterpreted the message of this post to suggest that those who implement web accessibility preferences, or even web accessibility at all, are literally sissies. This is not at all what I am suggesting – I would not have devoted my life’s work to this effort if I viewed implementers of web accessibility this way. Such preferences obviously have their place, particularly on sites that target people with disabilities (see the comments below). However, implementing them as a method of avoiding native accessibility in content is not acceptable and certainly a cop-out approach to accessibility. My primary goal is that developers will consider the impact on ALL users when implementing such widgets and preferences for a particular group of users.
The term “sissies” comes from the original article that inspired this. We do not intend offense by reusing it here, no more so than “Dummies” books literally mean that someone who reads them is a “dummy”. I have rephrased the article title as a question, to perhaps clarify that this is not a literal, blanket statement, but an invitation to question the motivations and the overall impact of implementing such preferences. I apologize to any who took offense at the general theme of this post. This post has also generated a good deal of respectful and interesting dialog which I hope will continue.
There may be places where accessibility preferences, widgets, or controls are justified. My point is that they always come at a very steep cost – and that developers should balance the possible advantages of web accessibility preferences with the significant disadvantages.
Consider font resizing widgets – the stack of letter A’s that allow one to increase or decrease the font size for a particular web page or site. First, if your font size is too small, why not simply make it adequately sized rather than forcing the user to make it bigger? But assuming that your page’s font sizing is already adequate, who would benefit from a font resizing widget? Users with poor vision, right? But users with more extreme low vision will already be using a screen enlarger or some other mechanism for zooming the page or increasing the font size, so your widget does them little good. Many users who prefer or need larger text will be using the zoom function that is available in all major browsers to provide the larger text on all web pages they encounter. The more accurate response to the question is users who have low vision or who might prefer larger text, but who are not already using technology or browser functionality to provide it. This is a rather small body of users.
Now, who gains no benefit from or could be potentially disadvantaged by a font resizing widget? The short answer is EVERYBODY ELSE!
As noted above, many users with low vision will already have larger text. Users who are blind generally don’t care how big the text is, yet they must listen to and navigate through the widget controls on every page. Users with motor disabilities who use only the keyboard must also ‘tab’ through these controls while gaining no benefit from them. Users with auditory disabilities gain no benefit. Users with cognitive disabilities must handle the additional cognitive load of these controls (what does a stack of increasingly sized A’s mean anyway?). And most notably, users with adequate vision gain no utility from the widget (again, assuming your default font size is adequate), yet are still presented with the control on each and every page.
So, while the font resizing widget has potential to provide some benefit for a small number of users, it serves no benefit and can only make the experience less accessible for everybody else.
The same can be said for nearly every other type of accessibility preference. A preference to enable a high contrast view is provided to either account for poor default contrast or to provide accessibility to a small group of users at the cost of burdening all other users with the contrast control. Text-only versions are typically provided to account for poor accessibility of a main page and may benefit some users (though our surveys indicate they are rarely accessed by these users anyway), but they increase the complexity of the page to everybody else. Even something as seemingly innocuous as an accessibility statement link or badges stating your compliance with standards come at a cost while providing negligible benefit to end users. The cost and benefit of each of these should be considered.
There may be exceptions to the “web accessibility preferences are for sissies” rule, but they are few. “Skip” links are one possible exception, but their days are numbered. They remain necessary only because most browsers have yet to provide meaningful methods of keyboard navigation within pages. Sites that target people with disabilities may find such preferences to be acceptable.
Universal design, like most aspects of web accessibility (consider alternative text for images), is about making solid decisions that are enforced upon users to ensure a highly effective user experience. These decisions must be informed and are often difficult to make. The idea that using accessibility preferences, widgets, or controls to account for poor accessibility or design decisions is a dangerous one that rarely results in overall improvements to accessibility.