WebAIM - Web Accessibility In Mind

E-mail List Archives

RE: Font Resizers (WAS RE: back to top)

for

From: Jukka K. Korpela
Date: Jan 12, 2006 1:00AM


On Wed, 11 Jan 2006, Austin, Darrel wrote:

>> Now you are saying that you design something that duplicates
>> browser functionality in one way, and if you are logical, you
>> won't stop there but will create your version of many other
>> functions as well.
>
> I'm not saying that. I'm saying this particular browser functionality is
> rather useful, and not apparent to a lot of folks that will be visiting
> our site.

But if you are logical, you will make a similar conclusion about many
other features.

Besides, you are duplicating a browser functionality _in one way_.
Your widget does _not_ have the same effect as font size control,
since your widget only affects viewing your site. Maybe the site even uses
fixed font size, with a widget to change it to another fixed font size,
thereby breaking (on IE at least) the functionality of the browser's font
size control. You would be teaching people _not_ to use that control but
to find and use a site-specific control if they can.

Suppose that NN is using a browser that has the basic font size set to
somewhat too large (this is more common than too small, though of course
too small a size is more serious when not overridden). On all pages that
do not set font size at all, or set it to 100% or 1em, NN finds himself a
little inconvenienced. Let us suppose that NN knows nothing about font
size control in browsers. Then NN visits your site and finds a font size
control there. He uses it to decrease the font size. After leaving your
site, NN notices no change on _other_ sites.

You have made it more difficult to NN to learn about the basic features
of browser usage. Before seeing a site-specific control, NN may have
thought that there might (or should) be a way to change the font size
in general. Visiting a site with a special control _inside a page_
enforces the idea that there is no general control - why else would
some pages contain their own controls for that?

>> What makes you think that you will have
>> much better success?
>
> Well, for starters, it will be visible by default. Which gives us a
> slight advantage already.

Over current browser defaults, you mean.

It is easy to make improvements to software if you take one feature and
change it one direction and declare that as an improvement. The user
interface needs to balance between different needs, such as making
functions directly and visibly accessible and making the interface simple
and easy to manage (even to people with cognitive disabilities). In user
interface, more is usually less, but there's of course a limit somewhere.

Probably we all think that it's a mistake that IE does not contain a
visible font size control by default (previous versions did not, and
future versions might). But that's mostly because we think about
accessibility. While the Microsoft decision was wrong, it was not absurd,
and it had reasons. Removing elements from a user interface tends to make
it better, except for the functionality that becomes invisible.

Thus, there is no way around the principle of customization. The real
solution is easy customization of browsers' user interfaces, either
by users themselves or by some more experienced people that help them.
People who _really_ need control over font size (such as people with
considerable vision impairment) must have the basic issue solved for them,
or they don't surf at all. Page-specific control is just a nuisance to
them. People who just _benefit_ from such control might like page-specific
controls - until they learn they have been deceived into thinking they
_need_ to use such controls because there is no general tool in the
browser.

> Secondly, observation. We implemented this feature on our intranet and
> within a week we had a few folks...software developers for that matter,
> thank us for such a great feature.

You can add almost _anything_ in terms of controls and _some_ people will
say it's great - because they are the people who need it.

Adding new controls (to a browser) is fine as long as the user stays in
control and decides what's good for him. (This typically involves removing
some other controls. Less is more. When you need a control, you find it
much more easily among six buttons than among dozens of buttons,
dropdowns, and other controls.)

>> Would your strategy really be suitable
>> for web authoring in general? That would typically mean that
>> one underpaid employer, allowed to spend a small amount of
>> his working time to web stuff, reinvents the wheel that was
>> designed by a large number of computer professional over the years.
>
> I think that's a larger discussion...and an interesting one to be had.

This _is_ the larger discussion.

>> What is "simple" and "intuitive" is not a simple question at all.
>
> Nope. But in this case, it's not too big of a stretch. As mentioned,
> just showing the option on the screen puts it ahead of the built in
> browser controls.

Assuming the builtin control is not visible. When two similar-looking
controls with similar functionality are visible, you are creating
confusion and uncertainty. Within an intranet, at least in a centrally
managed fairly homogenous company network, it would be easier to configure
the browser (IE) so that it has the font size control among the basic
buttons. This would help people in the company not only when viewing
intranet pages but also when viewing WWW pages.

And making something visible all the time means that it remains visible to
people who don't need it. So it's _always_ a decision with pros and cons.
If a company makes the decision in its browser configuration, individual
users can (unless you wish to make company police prevent that) remove
the font size control if they think they don't need it or they need it
rarely. They can't do anything about font size controls on intranet pages.
(Well, they perhaps can, using a user style sheet, but it becomes much
more difficult than simple tuning of the browser's controls.)

--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/