Accessites.org
Wrangling Widgets

Sooner or later, you’re bound to come across an article, or blog entry, that talks about text size widgets. What exactly are these widgets and are they of any real use?

A text-size widget is a link, input or user control that allows users to view the site via an alternative style sheet with a larger, or smaller, relative font. The widget itself may be a short piece of text such as “Large Text” or it could be a small icon. Some sites offer a whole range of small, medium and large ‘A’ icons that change the text size. But, at the end of the day, it has to be said that this kind of accessibility option does replicate functionality that is probably best accomplished through the user’s own browser. So do these widgets offer any additional user support or is it just a case of designers showing off their cool alternative Cascading Style Sheet (CSS) skills?

The Arguments

In reality, that question isn’t easy to answer. This is a topic that often provokes strong responses from both sides. Let’s take a look at just a few of the arguments.

Argument 1

Text resize options are often buried in deep within the browser’s interface and are not readily available by default.

Response 1

By encouraging text resize widgets, we’re allowing the browser vendors to sit back and not do anything about it.

Argument 2

Browser vendors are observing the letter of the User Agent Guidelines.

Response 2

That may be so but they’re not observing the spirit of those same guidelines.

Argument 3

Users should learn how to use, and configure, their own software.

Response 3

Whose job is that? Site owners? Disability organisations? Browser vendors? Whilst no one group is willing to take responsibility, the onus tends to end up falling on the developer!

The more hardened amongst you might agree that this is not a developer’s problem but we also tend to forget just how daunting the web browser menus, and sub-menus, may appear to the average non-technical user. Grant Broome is particularly concerned about the less-confident users. Then there are the issues faced by switch users who may have major problems just trying to access their own browser’s controls. The user agent developers didn’t exactly make life easy for Joe Public when they tucked some of these options away within sub-menus.

The school of thought that you fall into probably depends on whether you once saw a user with poor eyesight give up on a web site or whether you recently staggered out of a developer’s meeting where everybody was complaining about all the demands being placed on developers and the added time and costs of accessibility. It may also depend on how we define what we do. Are we accessibility developers or are we “backenders”, sleeping during the day and putting together clever applications at night but only making them accessible when someone points a gun at our heads?

Like it or not, your opinion on text resize widgets is going to be coloured by the kind of demands (and opportunities) you normally face. However, given that we do have the technology to make life easier for users, can we honestly consider dropping text-size widgets altogether and just let users cope as best they can?

We don’t think so.

Who Uses Widgets?

When talking to, and observing, expert disabled users, we’ve noticed that many of them do not use the text resizing facilities within their own browser. In most cases, this is down to lack of knowledge, or confidence but, on occasion, there are good reasons why using the browser’s own menu system may pose a severe barrier. One of the main widget-using groups seem to be the dyslexic users rather than the visually impaired. This may come as a surprise to many designers but then you need to bear in mind that the latter group normally have their own magnification tools and methods whilst the former are not so well catered for.

User Education

We fully support Ian Lloyd’s call to Teach A Man To Fish . Longer term, the only real solution to this problem will be to try and educate users so that they learn to use the controls within their own browsers more effectively. To this end, Mike Cherim has provided a useful summary of controls already available within most browser interfaces. But no one said it had to be an “all or nothing” situation. What about a programme of user education across as many sites as possible whilst simultaneously making these widgets available until the user agents become easier to operate or more intuitive to use? Wouldn’t that offer the most considerate method of trying to educate users without forcing them to go “cold turkey”?

I’ve Decided to Offer Text Size Widgets. Now What?

The manner in which text size widgets are offered, however, is something that merits closer investigation. So far, we’ve identified two common problems.

To ‘A’ Or Not to ‘A’

As we’ve already mentioned, some sites use icons — typically small “A”, medium “A” and large “A”. But dig a little deeper and you’ll also find that the alt text for each icon is often a literal transcription of the icon’s text (i.e “a”). Ask a few screen reader users to evaluate these pages and all you’ll hear will be multiple renditions of “a…a… a” whilst confused users try to figure out what all of these “a”s are supposed to mean. Experience suggests that, at this point, only an explanation from a sighted person will be of any real help.

And whilst we’re on the subject of conventions, they can be dangerous. Many web sites spend significant resources on text-only site versions and BrowseAloud functionality because that’s accessibility whilst failing to deal with a whole raft of significant accessibility barriers like decent headings structure, colour contrast, explicit link text etc.

Ideally, we think that icons for text-size widgets should be dropped in favour of clear text. But if that’s not feasible, clear and informative alt text is a must.

Can There Be Too Much Choice?

We think so.

Does anyone really need the full range of “Small”, “Medium” and “Large” text offerings? Many sites seem to choose this multi-option route without ever thinking it through. We feel it’s often overkill. Multiple text-size widget links can cause problems for all non-mouse using groups but are unlikely to offer any additional benefits for visually impaired or dyslexic users who will just opt for the largest text size on offer.

A single “Large Text” option may be all that is needed with the corresponding “Normal Text” only available when the Large Text option has been selected. If you do think you need to offer other options, at least ensure that you have very good reasons for doing so first. Thus far, we’ve only come up with one possible scenario for offering a “Small Text” option. If a site’s default text size is quite large, some user groups (such as voice recognition software users) may benefit from an option that allows them to have more text within the browser window.

Better Options

Another approach is to stop trying to work out what text size your visitors might need and, instead, offer them the opportunity to simply increase or decrease text size by x% as many times as they want. The use of simple phrasing such as “bigger text” and “smaller text” should also be used to make the widget’s functionality as clear as possible. You could then take it one step further by setting a cookie on the user’s machine so that, on their next visit, their ideal font size is automatically rendered.

Server Or Client Side?

We don’t think it’s worth worrying too much about this. JavaScript isn’t “bad” per se — despite the knee jerk response from some accessibility quarters. Using it to do something, which perhaps we don’t really need to do anyway and which a browser can do already, isn’t wrong. We don’t want to second guess user scenarios but who would be affected by a JavaScript solution? Not screen reader users. Not mobile device users. Which leaves us with:

• Users who are on networks where support for JavaScript in the browser has been disabled by the corporate IT department.
• Lynx (text only browser) users.

Both of the above could be described as “a user choice”. Under those circumstances, should we even be aiming to support them? Server-side solutions have their downsides too. Some may require a page refresh before the text size change kicks in. Others “break” the Back button functionality by forcing users to view the same page but using a previous size which they didn’t like.

Over the next few months, we hope to present a few of our favourite approaches but there may be other methods out there that avoid the normal pitfalls. If so, we’d like to hear about them. Because whether or not you agree with the fundamental principles of replicating browser functionality, there seems little doubt that, for the time being, some users still need a helping hand.

And at the end of the day, if you are going to have a little piece of functionality on your site, you need to ensure that it’s usable — otherwise it just adds to the list of things on a page that could confuse users.

Note: This article was co-authored by Phil Smears and Mel Pedley who would like to extend their thanks to the members of the Shaw Trust’s Web Accreditation Team for their invaluable expert feedback.

Filed under Our Articles —

Bookmarking Links » del.icio.us | Digg | blogmarks | Ma.gnolia | StumbleUpon | Technorati | Help |

These posts may be related:

Due Chiacchiere »

WordPress and Accessibility »

Don’t Provide Text Resize Widgets — Educate »