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:14:06 UTC