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 20:54:51 UTC