Hi All,
It's not entirely clear when reading the guidelines that the examples are
non-normative. In the 4/6 conference call there was some discussion of how
508 contained language that had merged a normative guideline with it's
non-normative example and codified that as law. I'm concerned about that
sort of thing happening again. If we can't make it clear (including to
someone who doesn't read the introductory material) that the examples are
non-normative, then we should not include them in the guidelines, and move
them to technology specific techniques documents.
As part of our goal to make the guidelines more technology generic, we may
also want to add more non-HTML examples.
In addition, I have some comments on the following specific example text.
3.4
Use relative rather than absolute units in markup language attribute values
and style sheet property values.
For example, in in CSS use 'em' or percentage lengths rather than pt or cm,
which are absolute units. If absolute units are used, validate that the
rendered content is usable....
The CSS2 spec defines <absolute size> as the [ xx-small | x-small | small |
medium | large | x-large | xx-large ] syntax, which DOES scale based on
browser and OS font settings (I've tried this in IE on both Windows and Mac,
and in Nav 4.08 on Windows. Does anyone know of a platform where this is
not true?). It behaves pretty much the same way as the old html <font> tag.
I've found this to be a very effective way to specify fonts with some
precision in my targeted environment, but have them be resizable for those
who need to do so. I don't think we should be prohibiting this.
<relative size> is defined as [ larger | smaller ] syntax. I haven't used
this much, but I just tried it in IE5 and Nav 4.08 on win2k, and it resized
correctly.
ems, pts, and cms are all examples of <length>, and em is the only one
that's effected by user font settings. The others should be avoided.
An author should be able to use a combination of <absolute size> <relative
size> <percentage> plus length using ems, to build an attractive and
accessible document.
3.7
The example text says not to use blockquote for indentation, which is
totally valid. Is there a recommended way to do indentation? Adding a
table would also be inappropriate (not to mention a bandwidth waste). It
would be nice, where we say not to do something, to offer a suggestion on
how the author can accomplish the same goal in an accessible way.
--Cynthia