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.