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 – 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.
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 this 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.
As related to the zoom function in browsers, they do not all work, and try taking an online class if you depend on them, or logging into your bank account. I admit, I am only aging, not low vision yet (or perhaps not admitting it), and I need larger fonts when I prefer.
I prefer to set my own preferences. I prefer companies make all options available for me. Could you imagine software without usability preferences? I cannot, because I do not believe we are all the same!
Cheers
@Jared
Great article and I agree with you in principal. My question is, what then happens to the small minority who require these widgets and preferences when they are not available?
Require is a strong term for me to use here. As an example, likely someone who requires text to be enlarged is using a browser that supports such a function. What if they know how to use the resize widget, it’s right there in front of their face, and everyone elses; but, they don’t know how to use the zoom function of their browser?
To what extent is the obligation for understanding how to make the information available online accessible to oneself that of the user and not of the content provider?
Rob-
Thanks for your comment. I agree that there are issues with the zoom functions in browsers, but they are almost entirely issues with inaccessible and poorly designed sites (e.g., online classes and bank accounts), not the browser itself. If a site is inaccessible when text is increased in the browser, I don’t see how providing a site-specific font resizing widget is going to be any better.
Certainly there are places for global preferences. They are in all of our software. But specific, user-targeted preferences come at a cost, and my opinion is that the cost of most web accessibility preferences outweigh any benefits they might provide.
Good points. If site developers want to add that stuff to their site though, why not put it on a settings page instead of having every option on each page. It’s a whole lot easier to deal with one link instead of a ton of them for font, contrast, etc.
I forgot to say: Any desktop application lacking a preferences dialog is poorly developed. I understand how websites can do with out them, but in a desktop app, preferences are essential. Every part of that type of program should be customizable.
Everett-
Very good questions. These are exactly the questions I was hoping this article would provoke. Certainly there is a large burden on end users that authors should not have to take upon themselves (e.g., I don’t make my web page self-voicing for blind users, I just make it work for their screen reader). But there are some users that don’t understand how to modify their browser (or whatever) so as to make the content optimally accessible. Do we ignore these? My argument here is mostly yes, at least in the page itself – because providing a control, widget, or preference to that particular user will almost certainly result in a worse experience for all other users.
Still, there’s much we can do to make native accessibility more apparent to end users. Certainly making our pages very accessible to begin with is the most important. Assistive technology needs to be more readily available – and native in the things people already use (see Mac OS X for a good example of this). Browsers need to do a MUCH better job of revealing functionality like zoom. Would you have asked the question if every browser had a font resizing control in the default view?
And we can also work on educating users. Check http://www.ssa.gov/ for a very good alternative to a font resizing widget. The likelihood of needing bigger text is quite high for the Social Security Administration, so rather than providing a site-specific widget, they instead teach users how to increase the font sizes in their browsers, thus empowering them with this ability on all sites.
Thanks for the good article. BTW when testing I have encountered people with diminished vision who don’t trust the browser resize tools, largely because in the past they didn’t work with poorly made sites. I have noticed that these test participants do use on-page resize tools (like the different sized ‘A’) because, it seems, they feel they are more likely to work. With more browsers supporting page zoom this I expect will probably change in the future.
Jared – thanks for the provocative post. Great discussion around accessibility preference availability vs. greater, more universal native accessibility.
God I’m glad I’m not the only one who sees a problem with these gimmicks. Thanks for speaking up; about time someone did.
@Jared
Thanks for the response, thinking about it I likely wouldn’t have asked my question if font resizing controls were accessible (P.O.U.R.) to users on all browsers. That being said maybe they are and they are just not accessible to screen-reader users, but I doubt this is the case.
This question of user obligation comes up from time to time in the accessibility work I do with the Drupal CMS, particularly around making complex drag-and-drop UI components accessible to keyboard and screen-reader users. The question that I have regarding the complex UI component issue in particular is if it is reasonably easy for a sighted mouse user to understand how to perform a function with the UI component, should it also not be reasonably easy for a keyboard only or screen-reader user to gain the same information? We haven’t yet decided on a practical answer to that question.
Thanks again not only for the article, but for the ongoing discussion.
Great article. I think users not knowing how to use certain accessibility features on their browsers or other software is an issue too, but a seperate one from web accessibility, and rather one of the need for better education availability and rehab training.
Well said.
Another problem with widgets like rows-of-As is that they’re different – and in different places – from one site to the net.
As a wheelchair user for 50+ yrs, I have been confronting accessibility for a very long time. However, however I was happy that did not transfer to the computer until recently — I am losing strength and movement in my hands/arms.
I dodged a bullet with a laptop by purchasing a USB mini-mouse to replace the touch pad I could not get used to. Now, as touch screens move toward dominance I worry about their impact on my computer usage.
Thanks for bringing the discussion to the table — It seems clear that there are plenty of things which need addressing as technology moves into the future and more toward convergence!
Increasing the font size also benefits dyslexic, poor/emergent readers, and folk with intellectual disabilities. The ID group (my interest) rarely have ‘ownership’ of their desktop, consistent browsers, AT, local styles etc and typical usage modalities tend to be confined to what’s immediately in front of them onscreen, even for experienced users – placing restyle options a click away also limits their employment. You’ll find almost all sites targeting and user-tested with ID folk include these widgets – while alternate contrasts and [much rarer] page simplification and a sans-serif face choice are more measurably effective adaptations, sizing controls are both useful to and used by this group – its 1.5% of the population so worth thinking about.
In print publising for education there’s always been a correspondence between font size and targeted chronological reading age for similar reasons.
We made this same design decision at Ai Squared last year and have never looked back.
http://www.aisquared.com/textsize
If I use an insite Zoom tool, I know that the sight designer has considered this, and that when I zoom I can expect all elements of the site to work together in a harmonious fashion. If I use the generic zoom in my browser, I have no such garauntee, and text expoldes, out of boxes, columns and butons dissapeer of screen while site usability disapeers out the window.
Just my 2c
Playing devil’s advocate here…
I certainly agree with your points, Jared, regarding the redundancy of text resize widgets for a large number of users, and further that a site that breaks when text resizing from the browser is implemented, has deeper issues that need to be resolved.
Allowing users to use your site with larger text is not just common sense, but a requirement under WCAG 2, however there is a sufficient technique for the relevant text zoom checkpoint which states that “Providing controls on the Web page that allow users to incrementally change the size of all text on the page up to 200 percent” (G178).
Cases where this might be an appropriate solution are for very graphically intensive sites (art\design studios for instance), where fluid design is simply not sufficient at coping with users resizing the text up to 200% via their browser. Having a text resize widget instead allows a seperate stylesheet to be implemented for each incremental text size. These stylesheets could call in different background images for instance, to get round issues of text resizing out of container elements. Obviously this has implications regarding overheads of creating additional stylesheets.
The argument that the text resize widgets provide additional keystrokes for keyboard users could be countered by (as Storm says above) having the text resize widgets on just a settings page instead of every page.
I’m not stating that all sites should have text resize widgets of course; teaching users how to set their own preferences via their browsers is a far better, and longer term, solution, but I don’t think saying there is a never a place for text resize widgets is correct either; it is not (As with so many accessibility issues) as clear cut as that.
I agree with the goal of this article; I also agree with most of the objections raised to the article.
It’s stated that “users who have low vision or who might prefer larger text, but who are not already using technology or browser functionality to provide it … is a rather small body of users.” I think it’s quite the opposite — this is a large majority of *potential* users, perhaps even the current users of any given site. Various demographic surveys estimate the number of people with low vision at up to 10M in the US. It’s doubtful that there are more than 100K third-party screen magnifiers in use. As to OS enlarger utilities and browser functionality, it’s all speculation, but I doubt it would add up to 10% of the intended beneficiaries. So 90% are doing without, or are not using computers and the web for this and other reasons. We technically proficient early adopters are failing to empathize with the vast body of consumers who are very reluctant to reach into the guts of products to make changes they fear they cannot unmake. This is another form of the “blinking VCR clock” problem. Who knows how many households are underutilizing settings of all sorts?
There’s no reason to speculate. Why not do the actual consumer research necessary to find out how many people fit into which categories of vision loss AND technological underadoption? It’s got to be rigorously designed and recruited for (not a survey of convenience on a website). I’m willing to bet we’d be amazed at the answers.
Jim-
Thank you for your comments. I don’t disagree with your estimates. Let’s assume they are all entirely accurate and that there are 9M potential users of your web site that might significantly benefit from font resizing widgets. Does that then suggest that embedding font resizing widgets is automatically a good idea when doing so would provide no benefit and could potentially be a detriment to the other 300M potential users of the site? It might be – I just hope that the decision to do so is thoughtfully balanced against the needs of all other users.
I absolutely agree that we need more research in this area. I also think we’d be surprised at the numbers. But any implementation of ‘features’ for that particular audience should be implemented with care. Sometimes I fear we focus so much on accessibility for particular disability types or categories that we lose site of accessibility in general.
If we simply implemented features because some potential audience might need or want them, our sites would soon be littered with so many preferences and controls (font size, zoom, contrast, color, language simplicity, layout control, line length, word spacing, etc., etc.) that users wouldn’t bother trying to find useful content or functionality amongst all the accessibility we’ve offered them, or, more accurately, forced upon them.
When using a foreign computer and keyboard, I make no attempt to set my preferences and am gtsteful for the text resizing widgets.
Zooming is not always a pleasure unless accompaied with wordwrap so the lines don’t run off the screen,
WHAT i WOULD REALLY LIKE is a way for my choice of font to be used in this text entry box. Very few sites enable my choice of font to be used. Compared to the rest of this page, whay I am entering now is pretty wimpy. If you ask for ‘TEB”, I’ll send you a screen shot that show what I see.
===gm===
Jim’s post also reminded me of the National Public Inclusive Infrastructure (NPII). This project aims to lower the barriers to end users in getting the assistive technology and customizations they need to better access electronic information. It has great potential to remove many of the barriers that are highlighted in the comments above.
I completely agree with this article. It’s the responsibility of the browser/user-agent to page zoom and adjust text size. If it’s built into the web site, it’s usually inconsistent with other sites, requires JavaScript, adds weight to the site, etc. By the way, I blogged about this 2 1/2 years ago: Don’t Use Text Resizing Widgets.
In general, I have to agree with Jared. However, we have included a text resizer on selected sites where the clients’ target audience is not generally browser-savvy or added contrast switchers at a client’s request. Sure, these widgets clutter the user interface but if they can assist a site’s target audience, I’m not convinced that’s a bad thing. Btw, I had to do a lot of looking for find the “Need larger text?” link on the http://www.ssa.gov/ site. Good idea, not so great execution.
I would like to add another voice of caution to people who otherwise care greatly about accessibility and an inclusive web experience, but who seem to want to play down the current problem we have with poor browser usability (well pointed out by Jared’s comment above) in favour of requiring more aware users.
I wrote a blog post a year ago which I’d offer as a more detailed response to this article (http://58sound.com/2009/02/23/in-search-of-conformant-users/).
In summary, I agree that in an ideal world, web content should not be the place for accessibility widgets that should be part of browser functionality.
But in the real world there are people who don’t know how to make the necessary adjustments to compensate for their accessibility needs; and there are people who don’t know it’s possible that they can make accessibility adjustments. And there are people who don’t know they have an accessibility problem that could be solved by adjustments to the browser or OS. These are not people with severe impairments – I’m thinking particularly of age-related capability decline where accessibility needs may gradually accumulate over time.
I’d prefer not to rely on someone somewhere providing ‘better user education’; instead I’d like to see better browsing technology – browsers that can expose its accessibility functionality more obviously so that people who need them can immediately recognise and use it (and if this process can be automated to some extent, even better). The NPII looks like a great initiative, as does the AEGIS project, and in the UK the SuS-IT project I’m involved in is also tackling the same issue.
Web site design is not the exclusive province of accessibility. Content accessibility is perhaps even more important for people with intellectual disabilities. Exhaustive, step-by-step instructions may be found by many people to be burdensome to read. This does not mean such content should not be presented in that way. I know this point may seem obvious, but I find discussions about Web site accessibility, like this one, always focus on design.
Also, I second Simon’s point that people with intellectual disabilities rarely have ownership of their desktop. Consequently, accessibility widgets built into Web sites can be very useful to them. It would be best if these widgets were common both in function and placement across Web sites. Perhaps then they would be less burdensome for all people.
Clear Helper wrote, “Consequently, accessibility widgets built into Web sites can be very useful to them. It would be best if these widgets were common both in function and placement across Web sites.”
My thoughts on the impact of preferences on users with intellectual disabilities could be an entire new post – or series of posts. This is an area where we need much more research – and this is work that we, and you, are involved in. Certainly many users with intellectual disabilities would benefit from certain types of widgets or preferences, but this is also the audience that can be most harmed by widgets and preferences they do not understand – especially if they gain no benefit from them. What a conundrum!
As you noted, better standards and consistency for implementing such controls will help, but leaving this entirely to developers will never result in something universally helpful to this audience. Clearly browsers and assistive technology can do much in this area. WebAIM is currently pursuing funding to develop tools that will allow users to easily apply the manipulations and customizations that they need to best understand and consume web content. We are involved in the NPII. Both of these efforts by WebAIM have the goal of improving web accessibility for distinct users without relying on page-by-page controls and customizations that so often can decrease accessibility for those who do not need them.
I agree with everybody’s comments. A resizing widget should not be necessary. A resizing widget by itself is unlikely to be sufficient.
But people like them. Most of the people I’ve seen use them don’t “need” to use them (or don’t believe that they need them) they just prefer a different size.
Maybe they would be better served by the superior accessibility features of their browser or computer, but it’s unlikely they will ever know they exist. In a world where a surprising number of people don’t know the difference between “The Internet”, “a browser”, and “Google”, the thought of relying on user education seem quixotic.
I’ve been all over the map on this topic over the years, but right now, I’m in favor of supplying it as another way of improving the user experience – for any user – whether they see themselves as having a disability or not.
All the more reason to delight our users by helping them discover the native ability of their browsers.
Sarah, I, too, was all over the map on this issue — until I saw the variation that Mike Gifford used on his site, openconcept.ca. Every page but one on Mike’s site has a link that says “AAA Text Resize?” (The size of the letter increases from the first “A” to the third “A.”)
The only page that lacks it is the target for that link. If you can, take a look and see what you think. (For the benefit of those who cannot see, that page has a video that shows how to use the native ability of your browser to resize Web content.)
That’s the way to go. Don’t give people a fish — or even a steamed lobster. Show them how to catch their own so they can feast wherever they go.