RE: Proposal to Delete or Keep 2.4.1

Loretta wrote:

<blockquote>
The description of this SC
says: "The purpose of this success criterion [SC 2.4.1] is to ensure
that user agents, including assistive technologies, can recognize any
navigational mechanisms that may be present in the content, beyond those
perceivable structures required by 1.3.1. 1.3.1 requires perceivable
structures such as headings, labels for form controls, lists, etc. to be
programmatically determined."
</blockquote> 

SC 1.3.1 no longer includes the terms "perceivable structures." On the 9
March call the WG adopted the following wording:

1.3.1 Information and relationships conveyed through presentation can be
programmatically determined.

I think this makes it clearer that the ability to navigate by headings
is by-product of satisfying SC 1.3.1 rather than a core purpose of that
SC. 
For example, if visual formatting (presentation) implies that a given
phrase stands in relation to succeeding paragraph(s) as a heading, the
phrase must be tagged as a heading so that that relationship can be
programmatically determined. This *also* makes the heading available to
user agents as an aid to navigation, but that is not the point of the
markup


Let's jump a couple of years ahead. The current working draft of XHTML
2.0 includes a navigation list element (<nl>), sort of like the old
<menu> element. It also includes an attribute called role, one of whose
values may be "navigation."

Use of the <nl> element and the role attribute is arguably more
appropriate to SC 2.4.1 than to 1.3.1. The same might be true for
keyboard shortcuts (e.g., accesskey), whatever the eventual solution
turns out to be (accesskey is currently broken, but there is ongoing
work to address the issue). There are also specifications such as XLINK
that may belong more preoperly to SC 2.4.1 than to 1.3.1.

But maybe there are other SC where all these things can be (or already
are) properly addressed, in which case 2.4.1 is redundant and should go
away.

Thoughts?

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: Tuesday, March 14, 2006 9:43 am
To: Christophe Strobbe; WCAG
Subject: Re: Proposal to Delete or Keep 2.4.1


"Skipping link groups" and "Grouping links" are both SC 2.4.3
techniques. As far as I can tell, they don't belong in SC 2.4.1. Neither
is about recognizing navigational features.

It isn't clear to me that "Using the link element and navigation tools"
fits this SC either, but I will defer to those more knowledgeable about
HTML.

"Failure due to using structural markup for presentation effects" sounds
more like a SC 1.3.1 failure to me than a 2.4.1 failure.

"Failure due to Header misuse" is a 2.4.1 failure because we are
recognizing the headers are especially valuable for navigation. But the
technique of using headers is a SC 1.3.1 technique, not a SC 2.4.1
technique. (The use of headers was proposed as a 2.4.1 technique
initially, but rejected by the working group since it was a SC 1.3.1
issue.) The description of this SC
says: "The purpose of this success criterion is to ensure that user
agents, including assistive technologies, can recognize any navigational
mechanisms that may be present in the content, beyond those perceivable
structures required by 1.3.1. 1.3.1 requires perceivable structures such
as headings, labels for form controls, lists, etc. to be
programmatically determined."

We could keep this success criterion just to highlight the misuse of
scripting to create links in HTML. I still think that this issue is
covered by SC 4.1.2. 

Loretta

On 3/14/06 5:39 AM, "Christophe Strobbe"
<christophe.strobbe@esat.kuleuven.be> wrote:

> 
> 
> At 03:38 14/03/2006, Gregg Vanderheiden wrote:
> <blockquote>
> We need to decide to delete or keep 2.4.1  Navigational mechanisms 
> within the content can be programmatically determined. [How to meet 
> 2.4.1]
> 
> There was a proposal to delete it because there were no techniques for

> the SC.
> 
> All techniques for 2.4.1 in the How TO Meet doc are either techniques 
> for other success criteria as well,  (so they are already covered) or 
> they are just a title with no techniques (in sufficient section).
> </blockquote>
> 
> I have edited the stub
> '<http://trace.wisc.edu/wcag_wiki/index.php?title=Failure_due_to_Heade
> r_misuse
> >Failure
> due to Header
> <http://trace.wisc.edu/wcag_wiki/index.php?title=Failure_due_to_Header
> _misuse>
> misuse' 
> and the two empty ones:
> <http://trace.wisc.edu/wcag_wiki/index.php?title=Failure_due_to_using_
> structur al_markup_for_presentation_effects>Failure
> due to using structural markup for presentation 
> <http://trace.wisc.edu/wcag_wiki/index.php?title=Failure_due_to_using_
> structur al_markup_for_presentation_effects>effects
> and
> <http://trace.wisc.edu/wcag_wiki/index.php?title=Failure_due_to_using_
> scriptin
> g_events_instead_of_anchors>Failure
> due to using scripting events instead of anchors. The only one that is

> still empty is 
> <http://trace.wisc.edu/wcag_wiki/index.php?title=Programmatically_expo
> se_commo n_navigational_features&action=edit>Programmatically
> expose common navigational
> <http://trace.wisc.edu/wcag_wiki/index.php?title=Programmatically_expo
> se_commo
> n_navigational_features&action=edit>features:
> I don't know what we can put there beyond creating links/navigational 
> features according to spec (in HTML: the a, area and link elements; 
> possibly also the base element, although that affects the behaviour of

> certain links rather than being a navigational mechanism in its own
right).
> 
> I'm not sure if 'Failure due to using structural markup for 
> presentation effects' should map to 2.4.1. How about 1.3.1 or 1.3.4?
> 
> 
> Gregg also wrote:
> <blockquote>
> The last poll was 12 to delete and 1 to keep and 2 who "could live 
> with deleting it".
> 
> If there are techniques for the doc prepared and polled by Thursday we

> can discuss and see if new techniques change the picture. Otherwise we

> will need to delete as having no documented techniques to meet.
> 
> If there are techniques that are not already covered by other 
> techniques - then the group can discuss and see if they feel it should
stay or not.
> </blockquote>
> 
> If there are failures that are not covered elsewhere, then the SC has 
> a reason for existence. I don't think that the other success criteria 
> cover all situations (see especially the example in the third
failure).
> I will now withdraw to my bunker and wait for the bombshells ;-)
> 
> Regards,
> 
> Christophe
>

Received on Tuesday, 14 March 2006 16:12:14 UTC