Re: Guideline 3.4 comment (ralative vs. absolute units)

WCAG working group -- whose job is it to respond to these?  I have a
response below, which I have written and sent to you, but not to the
original querent, since I'm not sure what our protocol is on responding.

At 11:09 PM +0000 12/10/01, Vadim Plessky wrote:
>I have a comment on guideline 3.4 of WCAG 1.0
>http://www.w3.org/TR/WAI-WEBCONTENT/#gl-structure-presentation
>[...]
>IMO this is really wrong.
>You can design web page which doesn't use text at all (pure
>formatting/presentation purpose), like:
><html>
><style type="text/css">
>   div { border: 10pt solid blue; background: silver;
>          width: 100pt; height: 80pt }
></style>
><div></div>
><body>

I'm not sure I understand the purpose of such a page, though; for what
is it intended?  Is this to put a silver box with a blue border on
the page?  If so -- is there any particular meaning associated with
it, or is it just a blue box of a particular size?

>Using 'em' for defining width/height iof DIV element here is really NONSENSE
>- as *there is no font used in that page at all*.

That's incorrect, as a default font is always defined in CSS, and
should be based upon the user's default settings.  Is there some reason
the size of the box should not be relative to the rest of the presentation?
The user may have chosen, for example, to increase the font size to some
large number.

>Besides, you can't use percentage here - as you never know what is the
>browser's screen width (especially if you you XHTML basic - as <script> is
>not supported in XHTML basic, you can't get screen.width and screen.height.

What kind of application do you envision in which the exact size is
necessary and cannot be provided in percentages or em units?

>If there was something wrong in using 'pt' or 'cm' in CSS definitions - than
>'pt' and 'cm' could be just excluded from CSS specifications. As they are
>present in CSS1/CSS2 - there is nothing wrong in using them.

This isn't necessarily true -- there are many things you can do within
the context of the specifications which may lead to accessibility
errors.  They are allowable via the spec (CSS, XHTML, whatever) but
they can produce inaccessibility for many users.

However, this may be a point in which the techniques should be
clarified -- "pt" or "cm" should be acceptable within certain media
types (for example, setting a left page margin to 2 cm in print
media).  This is implied in the techniques document for CSS at
http://www.w3.org/TR/WCAG10-CSS-TECHS/#units

>Besides, using 'pt' (instead of 'px') is the only way to get font size
>*right* - and current CSS specification *doesn't recommend* using 'smaller'
>or 'bigger' - as these properties are device-dependant, so using them you
>limit your page portability and possibility to view it on different kind of
>devices.

The problem is that a desire to "get font size *right*" implies a desire
to override the user's preference for default font size. What makes you
think that "smaller" or "bigger" are device-dependent?  Font values of
"smaller" or "bigger" do not limit the portability of a page; they
encourage it, more than explicit, fixed font sizes set with "pt".

>Therefor, I suggest that Guideline 3.4 should be excluded from WCAG 1.0 (or
>latest WCAG 2.0). If it's already done in Errata, please let me know URL of
>that Errata - so far I was not able to find any correction for this GL.

Why do you think it should be excised?  Without such a guideline, users
with visual disabililties who need to change their default font sizes may
not be able to do so.

--Kynn

-- 
Kynn Bartlett <kynn@idyllmtn.com>                 http://kynn.com
Chief Technologist, Idyll Mountain            http://idyllmtn.com
Web Accessibility Expert-for-hire          http://kynn.com/resume
January Web Accessibility eCourse           http://kynn.com/+d201

Received on Monday, 10 December 2001 15:47:12 UTC