Re: last call comments on User Agent Accessibility Guidelines1.0

"Martin J. Duerst" wrote:
> 
> 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:

[snip]

> 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
>   accessibility).

Ok.
 
> - 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.

Ok.
 
> > 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.

A tool that doesn't tell you about a fee link at all is a bad too.
A tool that tells some users but not users with disabilities
is an inaccessible tool.

 
> > > - 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.

You can use frames and make them accessible. I don't think
that the WCAG says that frames are inaccessible (though
they may not be a good idea). Authors need to make them
accessible by providing alternatives that don't rely
on 2-dimensional layout, etc. And user agents needs to give
access to frames in a serial manner for those without
graphical displays.

> > > - 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?

Ok.
 
> > > - 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.

Ok.
 
> > > - 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.

Argh. I'll talk to the Webmaster about this.
 
> > 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.

Ok.
 
> > >         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'.

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

I'll incorporate your editorial comments below into the next
draft.

Thank you, Martin.

 - Ian
 
> 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:
>     rewrite:
>      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

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel/Fax:                     +1 212 684-1814
Cell:                        +1 917 450-8783

Received on Tuesday, 7 December 1999 10:59:40 UTC