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

Re: last call comments on User Agent Accessibility Guidelines 1.0

From: Martin J. Duerst <duerst@w3.org>
Date: Tue, 07 Dec 1999 16:28:45 +0900
Message-Id: <199912070823.RAA18173@sh.w3.mag.keio.ac.jp>
To: Ian Jacobs <ij@w3.org>
Cc: w3c-wai-ua@w3.org
Some comments on Ian's comments, and the rest of my comments.

At 09:35 1999/12/06 -0500, Ian Jacobs wrote:
> "Martin J. Duerst" wrote:

> > - Several guidelines are virtually identical or very close to
> >   general UI guidelines. This observation should be made early
> >   on.
> A couple of comments here:
> 1) Several reviewers have wished that UI checkpoints (and Guidelines
>    I suppose) be distinguished from content-related checkpoints.

Good idea, but not my point.

>    The solution we have in mind (identifying classes of checkpoints
>    as UI- or content-related within the existing guidelines) may
>    contribute to your suggestion that some are close to general
>    UI guidelines.
> 2) Are you suggesting that we emphasize that good UI design  is
>    also related to accessibility? 

Well, in some way yes, of course. But not exactly my point.

> 3) The following statements appear in section 1.1 under
>    "Ensure that the user interface is accessible":
>           The general topic of user interface accessibility for 
>           computer software exceeds the scope of this document. 
>           The guidelines do discuss some important user interface 
>           topics such as device-independence, configurability, 
>           and accessible product documentation. 
>    Is this the type of statement you're looking for? 

I'm looking for two things:

- A statement that some of this stuff is close to, or related
  to, general guidelines for user interface design (which is
  more general than the (still general) topic of user interface

- Removal, or rewording, in cases where the accessibility
  guideline coincides with general user interface guidelines,
  for example like the next point, or things like 'state
  (e.g. of input devices) should always be 'visible'. That
  the state should always be visible is something very basic,
  and it might sourd as if e.g. Mac and Windows users (as
  opposed to Unix or DOS command users) all have some
  disability if you state that so generally.

> >   Some things seem so general that I wonder why the turn up
> >   in Accessibility Guidelines. For example, should 'general'
> >   users not be informed when following a link implies a fee?
> >   That should depend on the depth of the pocket of the user,
> >   not on accessibility issues, it seems.
> We need a "pocket-depth" attribute, I guess!
> Such checkpoints exist so that developers will not assume, for
> example, that color alone is sufficient to indicate that 
> following a link will cost money. 

I see. In that case please change the wording to say so.

> I also believe that not all developers would find this as
> obvious as you do.

Do you care if a developer provides a product that won't
tell you whether you are charged for following a link or not?
I guess you do. But is this an accessibility issue, if the
developer decides to not show this info at all? I very
clearly think no. He may not sell the product, but it
should still conform to the guidelines, because it in
no way disadvantages people with disabilities.

> > - The document contains a lot about deprecated technology,
> >   e.g. frames. There should be a comment saying that mentioning
> >   something does not necessarily mean it's a good feature for
> >   accessibility (see xxx guidelines), but that things are
> >   mentionned here nevertheless if they are sufficiently
> >   popular to justify support.
> Frames are not deprecated in HTML 4.0.

They are not deprecated in HTML 4.0, but there is general
agreement that they are not a good idea, for various reasons
(URI problems, accessibility problems,...). I mean deprecated
in this sense, probably there is a better word for it.

> However, a note under
> checkpoint 6.2 about support for deprecated features might
> be useful. I propose:
>    For reasons of backward compatibility, user agents should 
>    to continue to support deprecated features of specifications. 
>    The current guidelines refer to some deprecated language 
>    features that do not necessarily promote accessibility but
>    are widely deployed.

I think the main reason is not backwards compatibility, but
the amount of contents that still doesn't conform to e.g.
the content authoring guidelines. And the note should be
at the beginning of the document.

to continue -> continue

> > - Guideline 9.2: I don't get this. Do you want to say tha
> >   it is in the currently selected viewport, i.e. that the
> >   viewport may have to be changed? Or that the point of
> >   regard has to be changed?
> Suppose that the user is tabbing through links and the next
> link is outside of the current viewport's contents. When
> the focus is moved, the viewport should be scrolled so that
> the focus is in the viewport afterwards. 

Got it. Can you please make sure that the doc says that?

> > - 10.3: Single-stroke/single-key: Does this include modifiers
> >   or not? There are in general not enough keys to have one
> >   (unmodified) for each function.
> No, this doesn't include modifiers. The requirement of 10.3 is
> not that each functionality be bound to a single key, only
> that users be able to activate a functionality with a single
> key. For example, the user could select the 20 most important
> and configure the user agent for those 20.

So the requirement is that the user must be able to configure
shortcuts, and in particular must be able to map some of  them
to single keys (i.e. one key without any modifier).
So just change the text to make this clear.

> > - On Netscape 4.0, the boxed Guideline titles disappeared when
> >   printed.
> You mean the entire title disappears, or just the box?

The entire title. Some of the box is still visible.

> Note that we provide PS and PDF versions for better printing. 

That should be enough. missed them, sorry.

> > Double-A and Triple-A should also provide the original
> > spelling (AA and AAA), to make sure users understand what
> > is referred to.
> The original spelling is Double-A, not "AA". The WCAG WG
> decided not to use "AA" at all for reasons of speech
> synthesis, and we adopted their decision.

I understand that. The main reason I'm a bit worried is
that while in the US, everybody might easily immagine
AA when reading Double-A, I'm not sure people all over
the world will make this association as quickly. Mostly,
they just have seen AAA and AA, and read it according
to local conventions.

> >         output device-independent: weird grouping/use of space and hyphen
> >         There are more of these, e.g. user agent-initiated
> Is this incorrect? We use "device-independent" and "output device"
> so why not "output device-independent"? 

No space between two words is the stronges binding. A hyphen
is the next looser binding. A space is even looser.
In 'output device independent', the binding is stronger
between output and device than between device and independent,
which is not matched by using a space for the former and a hyphen
for the later. I suggest using something like 'independent of'.

> > Sorry, I have a few more points, mostly minor, but I have
> > to leave now. Will send them tomorrow.

Here we go:

Definitions, active element: with associated scripts ... associated
     repetition, remove one 'associated'.

Assistive technologies:
     In the area of Web Accessibility, common
              software-based assistive technologies include assistive
              technologies, which rely on other user agents for input
              and/or output. These include:
     In the area of Web Accessibility, common
              software-based assistive technologies include
              technologies that rely on other user agents for input
              and/or output, in particular:

Continuous equivalent track:
  captions are rendered by being superimposed: on TV, of course they
  are superimposed, but on a PC, there is no need to superimpose
  them, usually there is enough space elsewhere.

Control:   Within the limits offered by the operating system or the
           user agent.  I suggest you add hardware limits here.

Documents,...: haveattributes: space missing
               is that which: improve wording.

Events: 'Note.': wouldn't 'Note:' look better?
    this document will only refer to: change future tense to present.

Focus: generally presented (e.g. highlighted) in a way that makes it
   stand out: highlighted is already defined to make things stand
   out, in a very general way, so you can just say 'The current focus
   is usually highlighted.'.

Properties: Should 'ascribed' be changed to 'ascribed to'? Not sure.
     property'sdefault: Space missing.

User Agent-initiated: space/hyphen problem again.

Views,...: a window, frame, a piece:  frame -> a frame
    The view is how -> The view corresponds to how, the view defines how,...
    user'spoint of regard: space missing.

That's it.  Regards,   Martin.

#-#-#  Martin J. Du"rst, World Wide Web Consortium
#-#-#  mailto:duerst@w3.org   http://www.w3.org
Received on Tuesday, 7 December 1999 03:23:48 UTC

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