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

Re: Correction: User Agent Accessibility Guidelines Last Call

From: Ian Jacobs <ij@w3.org>
Date: Sat, 04 Dec 1999 18:07:17 -0500
Message-ID: <38499EA5.DA6EFDEF@w3.org>
To: Richard Premack <richardp@akamail.com>
CC: jbrewer@w3.org, w3c-wai-ua@w3.org
Richard Premack wrote:
> Last Call review of User Agent Accessibility Guidelines 1.0
> W3C Working Draft-November-1999
> Prepared by:
> Richard Premack, interNext
> richardp@inter-next.net
> 1-888-576-8932 (USA) 1-727-578-1059 (Int'l)
> The following is our response (attached in both Microsoft Word and HTML
> formats) to an invitation by Jon Gunderson, Chair -- W3C WAI User Agent
> Working Group to review and provide comment on the " User Agent
> Accessibility Guidelines 1.0 - W3C Working Draft-November-1999".

Thank you for the comments, Richard. I will add issues that
you raise to our issues list [1]. My comments are below. For
your comments that are purely editorial, I will make the
appropriate corrections.

Thank you,

 - Ian

[1] http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html

> 2.1 Legal Considerations
> In any event, I think it would be advisable to have the draft  document
> reviewed by W3C legal counsel or an attorney well-versed in web  content
> copyright law to determine if there might in fact be a conflict  between
> providing accessible functionality in user-agents and the rights  of web
> content authors.

These comments are very interesting and I will take them to the
W3C Team for discussion. Though I am not a lawyer, I would
split the issue into two:

1) Rendering changes

The HTML specification describes in very few places how content should
be rendered. Therefore, anyone who writes a Web page in HTML and
expects it to be rendered in a specific way is using the wrong language
for designing their page. The fact that HTML says so little
is one reason why browsers differ in behavior today. 

If we extend the discussion to style sheets, user override of style
is built into the CSS specification (CSS2 reinforces the override
by ensuring that users can have final say). Therefore, anyone using
CSS who expects to have final control over styles is using the wrong
language for style.

In short, I don't know how one would defend an argument that user
agents MUST render content in a particular manner. 

2) Content changes

It is possible for users to add content to Web pages (through
transformations, style sheets, and other mechanisms). If I make
these transformations for my personal use but do not republish
them, do I infringe the author's copyright? Is it illegal
to tear pages out of a book because it has been bound too tightly
and I can't read the inside margin of the pages?

I look forward to interesting discussion on this topic.

> 3.0 Specific Comments
> The abstract, in an effort to define/distinguish between  "user-agents" and
> "assistive technologies" cites several examples in  each category. However,
> the glossary definition seems to imply that  both components are
> (necessarily?) part of the user-agent. This may be  a nit to some, but the two
> sections do seem a little inconsistent with  each other.

Eric Hansen has pointed this out as well ([2], Issue #1) 
and the definitions will be cleaned up in future drafts.

[2] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0338.html
> [Checkpoint 1.3]
> Be careful that when converting/rendering one content object as  another the
> object's original characteristics are maintained.

I'm not sure what your comment refers to. Checkpoint 1.3 in the
last call draft [3] reads:

   "Ensure that the user can interact with all active 
    elements in a device-independent manner."

[3] http://www.w3.org/TR/1999/WD-WAI-USERAGENT-19991105/
> [Checkpoint 2.8]
> What about so-called "proximal text" that may be used to describe a  link
> when no ALT text is available? This is text that occurs  immediately after or
> before the HREF tag. In this case of either  unspecified ALT text or specified
> null ALT text we would use proximal  text to describe the link if available.

Checkpoint 2.8 reads:

     When alternative text has been specified explicitly as
     empty (i.e., an empty string), render nothing.

Authors should be able to specify empty alt text when they mean,
for example, "this image is purely decorative and has no function
in the page." Thus, we ask UAs to not attempt to guess what the
function of the image is since the author has (we hope) meant
"no function" by specifying empty alt text.

Our current techniques for checkpoint 2.7 (missing Alt text)
refer to the "altifier" tool heuristics [4]. Your suggestions could
be added as another technique.

[4] http://www.vorburger.ch/projects/alt/

> [Checkpoint 2.9]
> The changing from a supported natural language to an unsupported  language
> could be very disorienting to a user and therefore the user  "should" (Priority
> 1) be notified.

Are you suggesting that the priority of checkpoint 2.9 be
raised to Priority 1?

> [Checkpoints 3.5 & 3.6]
> As mentioned previously, inhibiting blinking or animated text (or  images) as
> suggested in this checkpoint could have the effect of  inhibiting a copyright
> notice, or more commonly, a paid advertising  "banner".

Ignorance of the copyright statement doesn't mean that it doesn't apply.
Important information on the screen might just as easily be obscured
by the placement of my windows.

> [Checkpoint 3.8]
> The ability to turn on and off [foreground] images "should" (Priority  1) be
> provided and is at least as important as checkpoint 3.1.

The Working Group elected to reduce the priority of turning  off
(static) image rendering because rendering images did not raise barriers
accessibility. Background images may make text impossible to read and
thus the WG made checkpoint 3.1 a priority 1 checkpoint.

Do you have significant arguments for raising the priority level of
checkpoint 3.1?

Please refer to the 12 October WG face-to-face minutes [5] for
about this resolution. The checkpoint number in the document under
review at that meeting was 4.1.

[5] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0105.html

> [Checkpoint 4.1]
> While Checkpoints 4.2 - 4.4 address important controls for site  impaired
> (low-vision) users, it is unclear to me that font family plays  a Priority 1 role in
> ensuring readability. I would recommend Priority  2, although I understand the
> tendency to want to group font type and  size together.

I'll add this as issue 158

> [Checkpoint 4.13]
> Normal audio playback controls are important and should have the same 
> priority (Priority 1) as playback controls on Text-To-Speech  (checkpoints
> 4.14 & 4.15). Certainly these controls would be  considered more important
> than say, changing the gender of  Text-To-Speech output.

Added as issue 159

> [Checkpoint 5.1]
> This checkpoint is much too vague to be useful to a developer without  further
> elaboration. What are "accessible APIs" as opposed to standard  APIs? Which
> "other technologies" are being referenced? This checkpoint  deserves a more
> complete explanation in view of the fact that it is  fundamental to other
> checkpoints involving APIs and carries a Priority 1  rank.

This checkpoint is already on our issues list as issue 125

> [Checkpoints 5.4 & 5.5]
> The more I read checkpoints 5.4 and 5.5 the less difference I can  discern
> between them. 

You should stop reading them. That helped me. <wink>

> If Checkpoint 5.5 was embellished slightly to  clarify that
> Checkpoint 5.5 is a superset of Checkpoint 5.4, this would  improve the clarity
> of both checkpoints.

Good idea. That's how we handle other checkpoints that are important
special cases. However, I think 5.4 is more a special case
of 5.3 than 5.5 (which is more about change than read/write access).

> [Checkpoints 6.1 & 6.2]
> Again, the distinction between these two checkpoints, besides their  priority,
> is barely discernable from the description. Both call for  implementation of
> applicable accessibility features except that one  enumerates the
> specifications.

6.1 is specifically about accessibility features.
6.2 is about conformance to specification; all features
    in addition to accessibility features.

I agree that 6.1 is a special case of 6.2 for W3C specifications.
However, 6.1 is not limited to W3C specifications (it would include,
for example, Java, in my opinion).

> [Guideline 7. Provide navigation mechanisms]
> "So that users of serial devices are not required to view an entire  page or
> presentation to find information, user agents should provide  more direct
> navigation mechanisms"
> The statement above has definite legal implications that should be  apparent
> from the previous discussion of copyright law. It is important  to remember that
> when viewing a page visually, almost all of the  information is presented to the
> user instantaneously through their eyes.  In this case, the use of direct
> navigation mechanisms does not prevent  the user from processing the other
> information contained within the page  since that information has already been
> viewed.

I don't think that's true. If I enter a long page (that requires
to view the entire contents) but I leave the page via a link at the
top of the page, there is no guarantee that I have viewed anything below
the first screen (nor that I have viewed a piece of content in the
first screen that I may have missed, or understood if written in a
language I don't understand, etc.)

>  In contrast, direct  navigation features on a page presented serially,
> such as through  Text-To-Speech conversion may cause entire sections of
> content to be  missed and "context may be lost".

I think the Web is mostly about direct access through links and
there are few guarantees of sequential access to information. 
The traditional narrative structure is lost (or rather augemented) in
hypertext model.
> [Checkpoint 7.5]
> Navigating just among active elements seems at least as important as 
> navigating through the elements of a table (Checkpoint 7.3).

Checkpoint 7.3 is already up for discussion. Refer to issue 160
> [Checkpoint 8.8]
> This checkpoint appears to be a fundamental mechanism and deserving  of at
> least a Priority 2 ranking.

Added as issue 161
> [Checkpoint 8.9]
> Software re-usability and backwards compatibility are important  features to
> provide and "should" be 
> provided.

Added as issue 162.
> [Missing Checkpoint 10.X ?]
> It seems there should be a checkpoint in this section describing a  feature
> similar to the "Favorites" folder implemented in some browsers  whereby
> previously visited links may be stored, named, categorized and  retrieved with
> a single keystroke or a single voice command.

I think that a "Favorites" functionality is useful (like a Back/Forward
functionality) but is probably a technique for another checkpoint
related to navigation.

Added as issue 163
Received on Saturday, 4 December 1999 18:07:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:24 UTC