W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 1999

User Agent Accessibility Guidelines comments: font-size UI

From: Todd Fahrner <fahrner@pobox.com>
Date: Mon, 22 Nov 1999 09:14:11 -0800
Message-Id: <v04220802b45f29369d98@[]>
To: w3c-wai-ua@w3.org
I sent the stuff below to the wrong address. I expect some of you saw 
it anyway. Just to be sure, I send again.


This document: http://www.w3.org/TR/1999/WD-WAI-USERAGENT-19991105/

Contains these bits:



...which are less than usefully explicit for "priority 1" items, and 
unfortunate implementation precedent proves that elaboration is 

Currently, the only techniques cited to assure user control of font size are
"...[A]llow the user to control font size through style sheets or the 
user interface. Or allow the user to magnify text." and "Implement 
the CSS 'font-size' property."

I can think of at least one implementation [WinIE5] which arguably 
passes muster under such lax language, which nevertheless presents 
serious usability problems in this area. The result is that many 
authors are less ready to embrace accessibility-conscious visual 
design techniques.

The problem lies in the details of the CSS font-size property 
implementation, for which no explicit normative references exist. The 
CSS Recommendations, for their part, have tended to avoid UI 
specifics that might offend some members' sense of "turf", as it can 
affect competitive issues such as look-and-feel, OS integration, 
etc., or so it seems to me. This W3C product, however, seems like the 
right vehicle.

For the sake of "getting to the point", I'll suggest 
additions/revisions first, with discussion of rationale to follow:

*  Implement the CSS 'font-size' property as follows:

    *  When a single font-size value is solicited in UI, the font-
       size choice must define the value of the 'medium' font-size
       keyword. Larger and smaller absolute size keyword values must be
       computed relative to the user-chosen 'medium' value.

    *  To avoid confusion, circularity, and indeterminacy, user-chosen
       font-size values should not themselves be given in keyword
       terms (e.g. 'medium', 'smaller', etc.), but in length units
       appropriate to the media type (e.g., 16px for the screen media
       type, 12pt for print, etc.).

    *  UAs should take available resolution into account when
       calculating the CSS absolute font-size keyword intervals, such
       that, e.g., the three size values below 'medium' remain legible
       and distinct from one another as long as the user-chosen 'medium'
       value is itself at least three steps above the legibility floor,
       as determined by device and font design constraints.[1]

    *  the font-size choice exposed to the user in UI must provide a
       font-size value for the root elements of documents to be rendered.

*  Implement the CSS2 Processing Model
    such that a font-size specified on the document root (e.g., HTML)
    will inherit predictably per the CSS cascading and inheritance rules
    (http://www.w3.org/TR/1998/REC-CSS2-19980512/cascade.html) to all
    children, including HTML TABLE elements.

The reason for most of these elaborations should be clear upon 
considering their *lack* in practice. If an author wishes to respect 
the font size needs of the user, s/he must be able to assume certain 
sympathetic correlations between hir stylesheet rules and those of 
the user, as well as predictable cascading and inheritance rules. 
This is common sense, yet implementations are in chaos for lack of 
norms here, and a lot depends on cleaning things up.

Need I say more than that "medium" used by an author as a font-size 
value maps to a size ONE STEP LARGER than the "medium" selected by 
users as a default font size in WinIE5? Of course, this throws off 
the meaning of SMALL and all the rest rather absurdly. This renders 
the keyword system unusable in commercial Web design practice. And 
the weirdly tenacious table-related inheritance bugs in WinIE and 
Netscape 4.x render the other font-size schemes equally useless.

You don't want to see more slow, inaccessible GIF/pixel text? Then 
help fix the CSS alternatives by explicitly stating the font-size UI 
requirements in CSS terms!


The WAI Authoring guidelines wisely discourage the use of absolute 
length units (e.g., "points") for font-size values in the screen 
media type, instead favoring relative units (e.g., ems) for their 
supposed reference to a UA default font size, presumably under 
control of the user.

The trouble with relative length units, however, is that they are 
*not* relative to the font size set by the user. They are instead 
relative to the font size of the parent element in the document tree, 
which itself may or may not refer to a user-set font size. 
Accessibility-conscious use of relative length units thus requires a 
more confident knowledge of how user style rules (e.g., preference 
settings) are resolved against author style rules and the document 
tree than is warranted either by normative references or deployed UAs.

It is nowhere specified, for instance, that the font size exposed in 
the UI is understood to be to 1em on any document node, and in fact 
UAs vary significantly both in how they parse documents into trees 
and in how style rules inherit through said trees.

Most Netscape and Microsoft products, for instance, fail even to 
consider the root element of HTML documents (i.e., HTML) to be part 
of the parse tree, susceptible to formatting rules. More 
significantly, they fail to inherit many style properties - including 
font-size - into TABLE elements, instead setting these back to the 
user-set size by default. Other, less idiosyncratic UAs such as 
MacIE4.5 and Opera *DO* inherit font-size into TABLE elements, 
presenting accessibility conscious authors with an awful dilemma: 
either specify font size in relative length units redundantly for 
TABLE elements as the most popular UAs require, thus screwing things 
up badly for Opera and MacIE4.5, or abandon CSS and stick with 
good-old BIG/SMALL or deprecated FONT tags in every last cell.

The reason that FONT tags and the like succeed where CSS relative 
length units do not is that FONT tags, per HTML 3.2, take scalar 
values 1-7, and relative values along this scale. These scalar values 
are anchored (at size "3") to the font size chosen by the user, and 
are *exempt from document tree inheritance issues* ("absolute"), 
making them far-and-away the most useful and accessible scheme 
currently implemented. Commercial sites that must work use them, and 
will continue to do so ad infinitum unless CSS implementations (and 
their UIs) are brought to a similar standard of usefulness.

CSS superceded the FONT size system with 7 keyword sizes of its own, 
but the scheme is underspecified and has been badly botched in 
implementation. There are no really good alternatives - you can't get 
by with ems/percentages, especially not before the sacred table bugs 
are crushed. This must be fixed. Hence my proposed amendments to the 
WAI UA guidelines.

ps: I am no expert in aural stylesheet concepts, but it seems to me 
that what goes for font size might just as readily go for, say, 
"volume". The user must be able to define the value of "normal" in 
absolute terms in order for authors to make meaningful use of, e.g., 
"loud" and "quiet"....

[1] http://style.metrius.com/font_size_intervals/altintervals.html#st
Todd Fahrner
Received on Monday, 22 November 1999 12:14:21 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:25 UTC