The Text Resizer Debate
	Posted by Brandy Reppy at May 07, 2009 11:57 AM CDT Categories: Accessibility, Usability

In a recent meeting, my team and I were taking a look at some wireframes and design comps for some current projects. Over the course of the discussions, a point was raised regarding the ever-popular “text resizer”, typically denoted with three capital A’s or plus and minus signs, denoting either a quick way to make the text larger, smaller, or reset to the original size. This practice, viewed most commonly as an accessibility feature, is probably one that you’ve seen on a few websites here and there, and maybe even played around with from time to time. But the debate in the meeting was whether or not this should be considered a best practice for website implementation. My answer, decidedly, is no.

The Argument

As you may or may not know, I compete with a team of other Convions in accessible website competitions. Because of this, I’ve spent what I’d imagine is a bit more time than most looking into features like this, trying to figure out what makes the most sense for users. And while I can still see some merits to including these components, I did want to outline a few reasons why I don’t encourage their use.

They are Unnecessary

Every major browser has native support for text resizing and page zoom. Individual websites who don’t provide on-site resizers are still able to be resized using the functionality inherent in the web browser itself. Spending time developing the functionality within the site is not a wasted effort by any means, but is redundant. Because of this, and for several other reasons, there is also a movement to provide information to users as to how they can resize web text in general. Check out the articles (and comments) about this practice at 456 Berea Street where Roger Johansson recommends scrapping text resize widgets and teaching people how to resize text or over at Accessify where Ian Lloyd talks about how to teach a man to fish (or how to resize text).

They are Difficult to Implement Correctly

In his article Developing an effective text-resizing widget, Joe Dolson states that, "A well-implemented text-resizer should not create issues." After that, he delves into five common considerations that need to be addressed when developing a text resizer. If you couple these issues with the added complexity of content management systems and form templates, you end up with a pretty major undertaking for functionality that already exists within the browser. (Note: For the sake of brevity, I won't get started on using ems instead of pixels to accommodate cross-browser differences.)

They Can Break Designs

Sure, we can test and retest text resizers, but the fact is that a lot of times, they will break a beautiful design. When it comes to website design, there's not a lot that is more disappointing than seeing a your work smashed to smithereens by a text resizing widget that breaks the framework. There are a lot of reasons why this can happen, and most can be solved with proper testing, but it's unfortunate to see a site rendered nearly unusable because of a built-in text widget.

The Cross

With all this being said, I do also want to include the argument for text resizers, because I realize there is still a case for why they are beneficial. I don't know if I've seen a much better argument than this one articulate by Grant Broome, entitled Text size widgits - quite useful actually. I will concede that there are elements of text resizers that, if implemented correctly and tested properly, can be really useful. I don't know if I've seen enough resizers that were implemented well to get totally on-board with this, but then again, I'm not exactly the target audience for the widget to begin with.

Wrap Up

My biggest concern with text resizers is what purpose they are meant to serve. I have too often seen text widgets serve as compensatory measures for bad designs and unreadable text. My main argument isn't that the widget is unusable. Rather, I'm opposed to the idea that the ends justify the means; simply implementing a widget like this doesn't get a site off the hook for looking at other usability and accessibility practices that are more effective for the site. Considering, however, that even my team can't fully agree on this issue, I'm sure some of you out there have opinions, too. Please feel free to leave your thoughts - and in the meantime, if you are having trouble reading this, try hitting Ctrl + +.

Nickname
Date:
Your Website's URL:	Enter your Web site starting with http://, example http://www.connectioncafe.com
Your Comment:	(some HTML tags, such as <b>, <i>, <a>, are supported)
Enter this word:	Change For security purposes.