W3C home > Mailing lists > Public > w3c-wai-er-ig@w3.org > July 2000

Re: AERT and ATAG10-TECHS (using AERT Technique 13.6.1 as an example)

From: Al Gilman <asgilman@iamdigex.net>
Date: Mon, 17 Jul 2000 10:15:43 -0400
Message-Id: <200007171412.KAA3078922@smtp2.mail.iamworld.net>
To: Wendy A Chisholm <wendy@w3.org>, w3c-wai-er-ig@w3.org
The AERT has gone overboard.  What is in the ATAG10-TECHS is closer to what
the
AERT repair should match, as I recall the joint meeting with UA-WG.

For example, if the group of links is already the contents of a list container
such as OL, DL, or the like; the list structure is all the container you
need. 
It is unnecessary and therefore inappropriate to introduce a MAP here.

Detail:  I don't know where the "identify the group (for user agents)" clause
came from.  This is not, if I remember correctly, what we agreed with the User
Agent Working Group.  All the user agent needs to see is one parent node in
the
parse tree which covers the scope to be skipped.  This is what the inital
"group the links" phrase covers.  The TITLE is identifying the group for the
human user.  The syntactic container, whatever type of element it is, is
identifying the group for user agents.  The middle phrase "identify the group
(for user agents)" is redundant and/or misleading.

_If you need to add_ a container to separate such a group off from syntactic
elements that are (prior to grouping the links) peers in the parse tree but
not
part of this close-packed-link-group functional unit, use MAP as the container
introduced.  The question as to whether the link group is a functional unit
should be posed to the author, and the author allowed to easily adjust the
start and stop points of the range of  stuff enclosed.  If there is already a
container for the appropriate scope, confirm the TITLE with the author.  Do
not
introduce a redundant container nor force the type of the container to MAP.

Al

At 04:59 AM 2000-07-17 -0400, Wendy A Chisholm wrote: 
>
> As I was working on a proposal for Technique 13.6.1, I looked at the
sections
> in WCAG10-TECHS, ATAG10-TECHS, and AERT that are related to this
technique.  
> I am trying to figure out a proposal for how ATAG10-TECHS and AERT refer to
> each other.
>
> First compare what ATAG10-TECHS says for this technique vs. what currently
> exists in the AERT:
>
> ATAG10-TECHS checkpoint 3.2 
>
> [<http://www.w3.org/TR/2000/NOTE-ATAG10-TECHS-20000504/#gl-prewritten-desc
>
s>http://www.w3.org/TR/2000/NOTE-ATAG10-TECHS-20000504/#gl-prewritten-descs]: 
> <blockquote>
> WCAG Checkpoint 13.6 Group related links, identify the group (for user
> agents), and, until user agents do so, provide a way to bypass the group.
> [Priority 3] 
> Techniques for WCAG checkpoint 13.6 
> HTML 
> Ask authors if lists of links are a group and should be a map. 
> </blockquote>
>
> Note that it has an HTML specific technique.
>
> Compare this to the current text in AERT for Technique 13.6.1
> [<http://www.w3.org/>http://www.w3.org/TR/AERT#group-links]
> <blockquote>
> Suggested message:
>  Groups of links should be grouped with a structural element. 
>
> Suggested repair:
>  Ask the user if an identified list of links should be grouped. 
>  If the user wants to group the links, use one of the following techniques 
>  a MAP element 
>  SPAN or DIV with appropriate "title" 
>  Suggest that the user provide a link to bypass the group or that they move
> the group to the bottom of the page or that they use a high "tabindex"
> attribute value. 
> </blockquote>
>
> What is in ATAG10-TECHS is a watered down version of what's in AERT, what
> should really be there?   A link to AERT?  This works better with the
> proposal I sent to the list than with what currently exists in the AERT.  It
> also seems that the ATAG10-TECHS ought to link to the WCAG10-HTML-TECHS
> section on grouping links.
>
> Thoughts?
>
> --wendy
>
> -- 
> wendy a chisholm
> world wide web consortium 
> web accessibility initiative
> madison, wi usa
> tel: +1 608 663 6346
> /-- 
Received on Monday, 17 July 2000 10:11:56 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Thursday, 9 June 2005 12:10:36 GMT