RE: Proposal to Delete or Keep 2.4.1

What I'd like to be able to say is something like "You can reach any
content in a web unit in Log N keystrokes, where N is a measure of the
length of the web unit." The reason we want things like Skip Groups,
Access Keys, and Headings for navigation is to be able to move in larger
chunks than the next focusable item, or the next item in the content.
This is especially the case when you know where you are trying to get in
the content, but there is no efficient way to get there from here.

The Log N requirement really requires some kind of hierarchy in
navigating the content. 

Loretta Guarino Reid
lguarino@adobe.com
Adobe Systems, Acrobat Engineering 

> -----Original Message-----
> From: John M Slatin [mailto:john_slatin@austin.utexas.edu]
> Sent: Wednesday, March 15, 2006 1:14 PM
> To: Loretta Guarino Reid; Michael Cooper; w3c-wai-
> gl@w3.org
> Subject: RE: Proposal to Delete or Keep 2.4.1
> 
> Loretta writes:
> 
> <blockquote>
> I actually think there is a class a problems related to
> navigation that
> we don't address, related to how to make it practical to
> navigate to
> information via the keyboard. However, I haven't been able
> to formulate
> a testable SC for this problem. But programmatically
> determining
> navigational features doesn't help with this issue.
> </blockquote>
> 
> Loretta, can you characterize these problems *without*
> (for the moment
> at least) worrying about writing a testable SC? What do
> you think the
> problems are that we haven't yet addressed?
> 
> For example, a keyboard user with painful karpal tunnel
> syndrome wants
> to move from a link embedded somewhere in the main content
> area to a
> link that comes midway into the navbar. This is
> comparatively trivial
> for mouse users *and* for people whose user agents provide
> navigable
> links lists. But how does a keyboard user do it? Is this a
> content issue
> or a user agent issue? What should authors do to avoid
> creating such
> barriers?
> 
> John
> 
> 
> 
> "Good design is accessible design."
> John Slatin, Ph.D.
> Director, Accessibility Institute
> University of Texas at Austin
> FAC 248C
> 1 University Station G9600
> Austin, TX 78712
> ph 512-495-4288, f 512-495-4524
> email jslatin@mail.utexas.edu
> web http://www.utexas.edu/research/accessibility/
> 
> 
> 
> 
> 
> -----Original Message-----
> From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-
> request@w3.org] On
> Behalf Of Loretta Guarino Reid
> Sent: Wednesday, March 15, 2006 2:55 pm
> To: Michael Cooper; w3c-wai-gl@w3.org
> Subject: RE: Proposal to Delete or Keep 2.4.1
> 
> 
> I still do not understand what problems this SC is trying
> to address
> that are not already addressed more clearly by other SC. I
> think some of
> it stems back to the lack of a clear definition of
> navigational
> features, so that I could understand what needs to be
> programmatically
> determined, and why. But if navigational features are
> controls, I think
> 4.1.2 states the requirements more clearly. If
> navigational features are
> not controls, I don't know how to characterize their
> "navigational"-ness, since we know that things like
> structure can be
> helpful in a number of ways.
> 
> I actually think there is a class a problems related to
> navigation that
> we don't address, related to how to make it practical to
> navigate to
> information via the keyboard. However, I haven't been able
> to formulate
> a testable SC for this problem. But programmatically
> determining
> navigational features doesn't help with this issue.
> 
> Loretta Guarino Reid
> lguarino@adobe.com
> Adobe Systems, Acrobat Engineering
> 
> > -----Original Message-----
> > From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-
> request@w3.org] On
> 
> > Behalf Of Michael Cooper
> > Sent: Wednesday, March 15, 2006 12:41 PM
> > To: w3c-wai-gl@w3.org
> > Subject: RE: Proposal to Delete or Keep 2.4.1
> >
> >
> > A major reason to delete 2.4.1 that I am hearing from
> people is that
> > there are no techniques. That is not exactly accurate:
> > there are plenty
> > of techniques, as the current How to Meet document
> (thanks for
> > enhancements Christophe) shows. The concern people have
> is that all of
> 
> > the techniques also map to other success criteria. They
> therefore
> > believe this SC is redundant and should be removed.
> >
> > I have said before and will say again, and again, and
> again, that it
> > is not a problem that techniques that map to 2.4.1 also
> map to other
> > SC. We have a great number of techniques that map to
> multiple SC, and
> > it would be difficult in many cases to say that they
> have any special
> > home in a particular one of the SC. There is even a SC,
> 2.1.2, that
> > has _no_ techniques listed at all [1]. 2.1.2 explicitly
> says the
> > techniques are the same as 2.1.1, except that the
> exception in 2.1.1
> > is not applied. We contemplated removing 2.1.2 on the no
> techniques
> > argument and it was rejected. Therefore I believe there
> is precedent
> > and that lack of unique techniques is not, in itself,
> justification to
> 
> > remove 2.4.1.
> >
> > I believe navigation is an extremely important aspect of
> using the
> > Web, and an area full of problems for people with
> disabilities.
> > It merits
> > some special treatment in WCAG, even if the way to meet
> the SC is the
> > same as the way to meet some other SC. I haven't heard
> an argument
> > that is consistent with other decisions we have taken
> that convince me
> 
> > it should be removed, and I think it would greatly
> weaken WCAG 2 if we
> 
> > did.
> >
> > Michael
> >
> > [1]
> >
> http://trace.wisc.edu/wcag_wiki/index.php?title=How_to_Mee
> > t_Success_Crit
> > erion_2.1.2
> >
> >
> > > -----Original Message-----
> > > From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-
> > request@w3.org] On
> > > Behalf Of Christophe Strobbe
> > > Sent: Tuesday, March 14, 2006 12:27 PM
> > > To: w3c-wai-gl@w3.org
> > > Subject: Re: Proposal to Delete or Keep 2.4.1
> > >
> > >
> > >
> > > Since I defended keeping this SC, I had to put my
> money
> > where my mouth
> > is
> > > and write the technique that remained empty:
> > > http://digbig.com/4grxr (Programmatically expose
> common
> > navigational
> > > features).
> > >
> > > Apart from this technique, only two other items seem
> > unique to this
> > > success
> > > criterion (see Loretta's mail):
> > > * Using the link element and navigation tools.
> > > * Failure due to using scripting events instead of
> > anchors.
> > >
> > > Since the last survey on this success criterion (GL
> 2.4
> > Issues and
> > > Techniques, 16 February), 4.1.2 has been reworded and
> is
> > no longer
> > > restricted to components that respond to user input,
> so
> > it now seems
> > to
> > > cover the two items above.
> > >
> > > I assume that XLink and XHTML 2's nl element (see
> John's
> > mail) will
> > > probably be rendered through a presentation that
> conveys
> > relationships, in
> > > which case they are covered by the reworded 1.3.1
> > ("Information and
> > > relationships conveyed through presentation can be
> > programmatically
> > > determined.")
> > >
> > > It seems that my case against deleting 2.4.1 is
> overcome
> > by events
> > because
> > > my concerns against deleting it have been addressed
> > elsewhere. (Unless
> > I
> > > overlooked something.)
> > >
> > > Regards,
> > >
> > > Christophe Strobbe
> > >
> > >
> > > --
> > > Christophe Strobbe
> > > K.U.Leuven - Departement of Electrical Engineering -
> > Research Group on
> > > Document Architectures
> > > Kasteelpark Arenberg 10 - 3001 Leuven-Heverlee -
> BELGIUM
> > > tel: +32 16 32 85 51
> > > http://www.docarch.be/
> > >
> > >
> > > Disclaimer:
> > http://www.kuleuven.be/cwis/email_disclaimer.htm
> > >
> > >
> >

Received on Wednesday, 15 March 2006 21:36:38 UTC