User Agent Accessibility Guidelines comments: font-size UI

Warning: I am on the font-size warpath again. The eyes you save could 
be your own.

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

Contains these bits:

http://www.w3.org/TR/1999/WD-WAI-USERAGENT-19991105/#gl-user-control-styles

http://www.w3.org/TR/WAI-USERAGENT-TECHS/#tech-control-text-size

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

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 circularity, 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
    (http://www.w3.org/TR/1998/REC-CSS2-19980512/intro.html#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!



Rationale

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 - incuding 
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 Tuesday, 16 November 1999 17:56:22 UTC