Developing an effective text-resizing widget

The grand old question concerning techniques and choices in web accessibility which, while common, are not necessarily helpful is a popular subject which is always around in accessibility circles. It’s certainly not a new topic for me to write on, but one which (for whatever reason) I’m going to go ahead and write about again.

In this case, I’m going to take a single commonly implemented method: the text-resizing tool, and discuss the advantages and disadvantages in some depth.

This article isn’t intended to espouse the use of text-resizing tools, but it is intended to try and describe how you can best implement a text-resizing tool to provide for your users.

Offering a text-resizing tool on a website is commonly considered a benefit to users on the grounds that it offers an easy, obvious, and intuitive (ideally) method to change the size of page text. The same method is often condemned on the grounds that it replicates existing browser functionality (breaking the normal user interface), and may cause more problems than it solves.

The first issue, replicating browser functionality, can’t really be denied. At the core, there can be no question that a text-resizing tool is unnecessary. The functionality already exists, and all the implementation can do is make it easier to find. However, making text-resizing easier to find isn’t something you can scoff at entirely. This is an area where it may be worthwhile to carefully consider the nature of your expected site visitor and their level of technological understanding.

An important issue to keep in mind is that people who need to enlarge text most likely need to do it frequently — it is highly probable that they have needed to learn how to do this in their browser already.

The other major issue is one which needs to be discussed in depth: whether a text-resizing tool causes more problems than it solves. This is a question of implementation. A well-implemented text-resizer should not create issues.

Javascript or server-side scripting?

Both options have advantages. Server-side scripting provides functionality which will work regardless of user-agent; no extra support is required. However, it will also require a page refresh. As such, server-side scripted text-resizing tools should not be provided on pages containing forms, unless they have been programmed to preserve the data in the form following the refresh. It’s not any kind of service to your users to allow them to resize the text, but cause them to lose their work.

Client-side scripting saves the trouble of worrying about page refresh, since client-side scripting is able to effect the page in place. However, given that it won’t function when scripting is not available, care needs to be taken to ensure effective fall back options. There are two basic choices: degrading to a server-side method, or allowing the option to disappear entirely if scripting isn’t available. Either choice is fine (as long as your server-side method doesn’t interfere with forms, as mentioned above!); but the most commonly seen choice is something else: the still-visible resizing tool which doesn’t do anything. That is the wrong choice.

User-interface design

It’s all well and good to say that a site widget to adjust text-size may be more “obvious and intuitive” than using browser functions, but this is actually entirely dependent on your design choices. I’ve seen a lot of different choices:

  1. The differently-sized “A” method.
  2. The “plus” and “minus” method.
  3. Drop down menu with different font-sizes specified
  4. “Larger” and “Smaller”

Are the symbols images? If so, do they have alternate text attributes which describe their behavior? Is this text readable and understandable if the images are unavailable? Have the symbols been designed through stylesheets? Is it clear which control is which if styles are disabled? Is the sizing functionality one which will actually work when styles are disabled? If not, has text been provided which will explain that the tool is unavailable without styles?

Do the controls actually do what is expected? A “plus” and “minus” indicator, for example, is expected to essentially increase and decrease the current size of the text, continuously. I have, however, seen an example of this which used those symbols to indicate two fixed states of text-sizing. The variously sized “A’s”, on the other hand, are generally expected to simply adjust the text size to various fixed states.

Placing limits on the text-sizing possible with a resizing widget is a major issue. Are you actually providing any help if you’re only allowing a single increase in size? With no resizing option visible, a user needing larger text may explore their options and discover their browser functionality; with it present, they may use it, but still be frustrated by the limitations it has placed — but not expect to find additional options.

Remembering your settings

This is one place where a text-resizing widget has advantages. Browser controls are inconsistent — Internet Explorer will remember your last setting, and apply it for all sites. Firefox, however, always resets to the median text-size. A web site specific text-resizing tool gives you the option to allow users to save their preference for your site, specifically. And it should. Don’t provide a text-resizing tool which doesn’t save the users preference; this is what will generally be most expected.

Furthermore, any text-resizing choice must be global across the site. I have seen web sites which implemented text-resizing which was specific only to the page you were currently on — navigate to a new page, and you need to adjust the size all over again. This is a great way to frustrate your users.

Providing a reset

Particularly of a concern for methods which provides continuous increase and decrease, it can be a major annoyance not to be able to easily reset your choice to the default. This may not be an issue for the current user — but it certainly might be for the next person to use the same site at the same computer!

Testing the sizing format

If you’re providing text-resizing, you should damn well make sure that the size choices you’ve provided will work. Make sure there’s no text overlap, text continues to have acceptable background/foreground contrast, and that clickable areas continue to be accessible. If you’re in control of the resizing, you should absolutely make certain that the size change works. This is not to say that you don’t need to test text resizing through browser controls — but if you’re offering limited choices, those choices should be absolutely effective.

In conclusion…

It is possible that implementing a web site specific method to resize text can be useful for your web site. It shouldn’t, however, be considered an automatic choice when implementing accessibility. For some groups of users, it may provide a small benefit by making the option to resize text more obvious — but on the whole, it’s a major duplication of existing functionality.

There a number of pitfalls in implementing this kind of site functionality, as described above, so if you do make the choice to use something like this, you need to be very careful. Without caution, it’s easy for the added functionality to be more frustrating than useful.

Have something to contribute?




« Read my Comment Policy

9 Comments to “Developing an effective text-resizing widget”

  1. I’m not totally convinced by the implementation in web browsers. Zooming an entire page can make it very hard to use as you might need to scroll horizontally just to find the text, or on small screens the line length may end up wider than the users visible screen area. I’ll make an assumption that people who do need to enlarge text are often less tech-savy or less comforatable using computers so by zooming the entire page it can make the experience harder for them. So I think just resizing the text can be valuable. Okay, the images are not resized but on information lead sites they are often secondary and used to make it look pretty as opposed to offering content required to understand the page.

  2. Thanks, Shawn! Selectively resizing content is definitely a boon. Although it can be done with custom style sheets in most modern browsers, that’s generally beyond the skill level — and well beyond the “reasonable expectations” level — for most web users.

    Yes, the distortion of pages with text resizing is an issue — although, to be frank, it’s an issue with both systems. I’ve seen no shortage of text resizing widgets which failed to accommodate for that kind of thing, as well!

  3. Couple things to add:

    1. With resizing controls you have ability to selectively resize page content. You can let user resize article content but not the navigations, menus etc. So it is more flexible;

    2. Not all browsers are born equal as others already mentioned. FF 2 does not offer page wide zooming, a page can be greatly distorted; One should consider offering or coding the page to reduce distortion upon text resizing. IE 7 does a much better job here.

    Tip to accommodate browser’s resizing: explicitly specify image width in em.

    This will force FF to resize images along with text to minimize distortion.

  4. Thanks, Dennis — browsers aren’t really doing us a favor by emphasizing these “Zoom” tools so much. If they were less buggy, it would be better, but until then…

  5. Great article Joe. There’s definitely a lack of consistency in text resizing tools/widgets, and I agree it should be up to the browser to handle that functionality. Adding to the mix is that in IE7, there’s a Zoom menu in the bottom right, but no easy text-resizing tool.

  6. That is incredibly irritating…the kind of so-called accessibility innovation which makes me scream. I can just imagine the developer putting in hours of labor just to create more frustration. (Well intentioned, of course.)

    Thanks, Stevie

  7. I’ve lost count of the number of times I’ve come across a site with the text illegibly-small, and used the on-screen text resizer, to bump it up to far-too-small-to-read-comfortably, but it wouldn’t go any further than that.

    A widget that only allows “a little bit smaller than default” and “a little bit larger than default” is worse than useless. Ideally it should infinitely resize text, but realistically it needs to have small, normal, large, x-large and xx-large as a minimum.

  8. Huh. That’s interesting – I like the fact that Firefox 3 will remember the setting, but I’m less thrilled by the “zoom” feature. Although, with the option to preserve the site width, that’s not so bad. The question, of course, will be how easy it is to configure those settings…

    Yeah, I saw what Dan had written…I can’t say I’m sure what he means by that…

    Understand that when building an already-wide layout, it’ll get really wide, really fast. That’s OK. Wide is the new drop shadow. Dan Cederholm

    Personally, while a little wide is fine, you’ve got to draw limits somewhere. Horizontal scrolling continues to suck!

  9. Firefox 3 will remember the zoom level on specific websites.

    Interestingly, this will be a zoom though, as used by Internet Explorer 7. I’m not 100% sold on this at the moment, and it could be another reason to use a widget on your site. It would enable you to set it up so that the text size increases but the width of the site stays the same.

    Having said that, Dan Cederholm has proclaimed that “Wide is the new drop shadow“.

Return to Top