Your comments on WCAG 2.0 Last Call Draft of April 2006

Dear Marco Bertoni ,

Thank you for your comments on the 2006 Last Call Working Draft of the
Web Content Accessibility Guidelines 2.0 (WCAG 2.0
http://www.w3.org/TR/2006/WD-WCAG20-20060427/). We appreciate the
interest that you have taken in these guidelines.

We apologize for the delay in getting back to you. We received many
constructive comments, and sometimes addressing one issue would cause
us to revise wording covered by an earlier issue. We therefore waited
until all comments had been addressed before responding to commenters.

This message contains the comments you submitted and the resolutions
to your comments. Each comment includes a link to the archived copy of
your original comment on
http://lists.w3.org/Archives/Public/public-comments-wcag20/, and may
also include links to the relevant changes in the updated WCAG 2.0
Public Working Draft at http://www.w3.org/TR/2007/WD-WCAG20-20070517/.

PLEASE REVIEW the decisions  for the following comments and reply to
us by 7 June at public-comments-WCAG20@w3.org to say whether you are
satisfied with the decision taken. Note that this list is publicly
archived.

We also welcome your comments on the rest of the updated WCAG 2.0
Public Working Draft by 29 June 2007. We have revised the guidelines
and the accompanying documents substantially. A detailed summary of
issues, revisions, and rationales for changes is at
http://www.w3.org/WAI/GL/2007/05/change-summary.html . Please see
http://www.w3.org/WAI/ for more information about the current review.

Thank you,

Loretta Guarino Reid, WCAG WG Co-Chair
Gregg Vanderheiden, WCAG WG Co-Chair
Michael Cooper, WCAG WG Staff Contact

On behalf of the WCAG Working Group

----------------------------------------------------------
Comment 1:

Source: http://www.w3.org/mid/2006620142025.935521@ocram
(Issue ID: LC-1050)

I think that we need some clarifications about the terms "relative",
"absolute" and "relative positioning", expecially when they are used
regarding both font sizing units and CSS positioning rules.

In the "Comparison of WCAG 1.0 checkpoints to WCAG 2.0" [1] appendix
we can read:

In General (Priority 2):
3.4: Use relative rather than absolute units in markup language
attribute values and style sheet property values.

that is is related to:

WCAG 2.0 Success Criteria:
This maps to an advisory technique (Using readable fonts) for Guideline 1.4.

Guideline 1.4 refer to visual and audio contrast [2] and I've not yet
found, even in the "Techniques for WCAG 2.0", the advisory technique
mentioned (Using readable fonts).

Even in the "CSS Techniques for WCAG 2.0" draft [2] - in which is
correctly introduced the idea of "Using em or percent for properties
that need to change" instead of "Use relative rather than absolute
units..." - the corresponding guideline mentioned is "1.3" ...that
refer to the separation of structure and presentation.

However, as Gregg Vanderheiden told: "Most advisory techniques have
not been written yet".

Having said that, I must point up that using terms like "relative
units", "absolute units" or "relative positioning" maybe somehow
confusing.

I'll start from the following assumptions:

1) The general accessibility principle in question is that users
(expecially partially sighted people) must be able to enlarge fonts
using their visual UA tools.

2) Microsoft Internet Explorer 6 for Windows - and all the previous
versions - is not able to enlarge text if it is sized in pixels. But
pixels are "relative" lenght units (they are relative to the viewing
device resolution) [4].

3) On the other hand there are some CSS absolute-size values that
IE/WIN can perfectly enlarge: the absolute-size keywords (x-small,
small, medium etc.) [5].

So, it is really confusing to advise CSS designers that they should
use relative length units to size fonts.

CSS Techniques correctly tell us to "Use "em" or % for properties that
need to change". But we should make another stride to avoid to mention
a specific unit identifier: e.g. here in Italy, in our recent
accessibility law [6], we have introduced a requirement (Requirement
12) that says: "The presentation and textual content of a page must be
able to be adapted to the dimensions of the browser window used by the
user, without superimposing objects present or loss of information
such as to render the content incomprehensible, including in the case
of resizing, enlargement or reduction of the display area or
characters in relation to the predefined values of these parameters.".
In other words, with this approach we say that the designer must size
characters with a unit of his choice that guarantees the enlargement
of text in every UA. This is expecially useful to ensure forward and
backward compatibility. We cannot forget that, at the time of this
writing, IE 6 cover almost all the market.

Cynthia Shelly suggested the term "scalable" to describe this text
resizing function.

Summarizing, there are relative and absolute CSS units that are
scalable (also in IE6/WIN):

1) for fonts: em, percentages and absolute-keywords (e.g. medium,
small, x-small etc.)
2) for containers: percentages and em.

But we have to think about the near future when IE/WIN will be able to
make pixels scalable. So we definitively should talk about *functions*
rather than units, and I agree with Cynthia that "scalable" is the
right term to use.

Therefore I suggest to tell designers something like "Use scalable
units for CSS properties that need to change: font-size and
line-height" rather than "Use these units...".

Directly following that we must also clarify the use of the phrase
"relative positioning": when a CSS designer hear that words he think
about a CSS rule like this: #box { position: relative; } [7]. But, in
itself, a positioning scheme isn't related to accessibility.

When you talk about relative positioning I think that you mean a
concept like "use liquid design" rather than a specific CSS
positioning scheme. It is wrong to advise designers to use a specific
positioning scheme. Instead, i.e., we should tell them that a liquid
design is more accessible than a fixed design, no matter which
technique they use to obtain that. Obviously we must first justify
this suggestion!.

These terminological problems are really serious: I've hardly
discussed, here in Italy, with tricky designers that keep on using
their beloved pixels for text sizing because these are relative units
as checkpoint 3.4 of WCAG 1.0 suggest (no matter if partially sighted
people using IE/WIN cannot resize them).

Marco Bertoni
-- 
Referente Regionale IWA Liguria
International Webmasters Association ITALIA
Fax Verde: 800 12.64.96 - Web Site: http://www.iwa-italy.org

[1] http://www.w3.org/TR/WCAG20/appendixD.html
[2] http://www.w3.org/TR/WCAG20/guidelines.html#visual-audio-contrast
[3] http://www.w3.org/TR/WCAG20-CSS-TECHS/#syntax-data-types
[4] http://www.w3.org/TR/CSS21/syndata.html#length-units
[5] http://www.w3.org/TR/CSS21/fonts.html#font-size-props
[6] http://www.pubbliaccesso.it/normative/DM080705-A-en.htm
[7] http://www.w3.org/TR/CSS21/visuren.html#relative-positioning

----------------------------
Response from Working Group:
----------------------------

Although text resizing is primarily a user agent function, we have
added new success criteria to address the author's responsibility for
supporting text resizing:

Level AA: Visually rendered text can be resized without assistive
technology up to 200 percent and down to 50 percent without loss of
content or functionality.

Level AAA: Visually rendered text can be resized without assistive
technology up to 200 percent and down to 50 percent without loss of
content or functionality and in a way that does not require the user
to scroll horizontally.

Received on Thursday, 17 May 2007 23:41:59 UTC