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

At 10:48 AM 2000-07-17 -0400, Charles McCathieNevile wrote:
>Actually I may partially disagree I think (but we may just be matching
>terminologies here) - the following are first response thoughts...
>
>The map element identifies the semantic of a collection of links. So if
>that's what there is, it should be used - it is more than a case of being
>able to identify a group element for skipping them, although that may express
>the requirement at a more basic level.
>
>There are though many cases in hypertext where there are not a particular
>collection of links - whether in a heavily linked paragraph, a list, or
>whatever.
>

My suspicion is that you may partially disagree.  This distinction is
_very_ subtle and it is easy for reasonable people to partially disagree
thereon.

The MAP element may be considered to connote the semantics of a navbar or
similar functional navaid unit.  It will be hard to get the great mass of
authors to understand this, but as theory it makes eminent sense.  As used
with sensitive images, that is the function it fulfils.

However, I am arguing that what we should best ask the User Agent for is
not special processing for MAPs but rather slightly more generic processing
for a weaker concept of which these MAPs are a more particular case.  And
it is a mixed blessing at best to advise authors to observe distinctions
that don't show up in the User Agent behavior.  The special semantics of
MAP will be valuable a) when the consumer actually inspects the page
structure carefully, i.e. learns the element type as well as its title as
well as b) for special-purpose algorithms in disability-market software.
But effective relief is gained by a slighly weaker concept and broader
technique which should be in effect anyway, or at least with higher
priority than the difference between MAP-as-navaid processing and the more
general "labeled subtree as functional unit" processing.

The unit that I am suggesting should be the meeting ground between the
author responsibility and the User Agent responsibility is the labeled
subtree in the DOM or parse tree of the document.

The user agent is asked to provide two functions with regard to labeled
subtrees:
1) expose the label [possibly on condition of where the user is in the page]
2) provide a navigation function to step past the subtree as a unit.

This makes how you get past the navbar the same function as how you move
between chapters in a book or sections in a chapter in the consensus
digital book model.

With this support from the User Agent, the author is asked a) to recognize
navbar-like groups as functional units, b) to ensure that these units have
their own subtree delimitation in the markup and c) to ensure that the
identification of this subtree by its TITLE label is descriptive of the
function of this unit.

In the joint discussion with the User Agent group, I argued against asking
the User Agent to provide navigation functions for MAP and MAP only.  The
value of a "step to next peer subtree" move in the navigation repertory is
just too valuable in too many other places, and it is sufficient to get the
job done here.  I believe that this argument carried the day at that time.
The group consensus could come back and reverse this, but it is not as
though the question has never been considered.

I believe that applying the above two functions to the broader, weaker,
concept of a functional unit within the document a) is effective as a
remedy for the "head links tank trap" barrier and b) has better
cost/effectiveness for the User Agent provider because it adds value in
more situations than just this one.  As a result, it seems it would be a
better choice of "reasonable accomodation" on a balanced interpretation of
the interests of all stakeholders.  It is fully good enough for the
consumer and more gain with comparable pain for the supplier.


So, although MAP carries the more specific connotation, the "more specific"
semantics of MAP over any container element with a well-written TITLE
attribute does not bear on the definition of the reasonable accomodation
technique.  It is gravy over and above what is required to make the
accomodation work for consumer, vendor, and author.

This is very subtle and open to debate.  The author probably will relate to
the "navbar-like navaid" concept as the natural level of granularity in
their concept space.  The "labeled functional unit" idea is more vague than
they can get their head into right away.  But if asked "is this group of
links a coincidence in a larger continuous flow, or is it a separate navaid
chunk?" the author will probably comprehend what they are being asked and
respond appropriately.  Then, once the scoping of functional units has been
confirmed [and optionally adjusted] it is easy to ask for a TITLE for the
unit, whether pre-existing or newly introduced.

Above I described a strategy which involves 

a) the labeled tree as the structure communicating between author and user
agent; 
b) the user agent providing tree-oriented structural navigation aided by
label-oriented orientation; and 
c) the author checking the goodness of fit between the syntactic labeled
tree and the author's concept of functional units in the page.

This strategy is rooted in genuine consumer experience with talking books.
It applies in a very wide range of circumstances.  In looking at access to
scientific information to be published via the Web, this principle fits
throughout.  More specific rules don't port well across differences in
content subject matter.  

I believe that along with the strong position of text as cross-sensory
content, this strategy merits preferred treatment as a universal design
strategy.  These strategies should be tried first, and more specific
remedies should be proposed only after these more general strategies
clearly don't get the job done.  It's almost as though our mantra could be
"TEXT and ToC" [except for the injury that slogan does to people with
reading-related disabilities].  For content, say everything in text that
you can.  It is never bad to improve the verbal or textual expression of
the message of the page.  For the user who finds words harrassing, we need
to provide filter methods that focus a user view on the non-textual
representation of the message.  Not kill the words out of the resource
altogether.  For structure, say everything in the implicit Table of
Contents, formed by the labeled subtrees in the parse tree, that you can.

Process notes:

1) I think that the established agreement is that in cases where the
alignment between AERT and WCAG is in question, the content guidelines
working group should be asked for their interpretation of the WCAG.

2) The ideas discussed above are some I want to offer to the content
guidelines working group for their consideration as they try to abstract
general principles or strategies that integrate and motivate the practices
mandated in the guidelines.  Later, when the dust settles a little here.


Al

>cheers
>
>Charles McCN
>
>On Mon, 17 Jul 2000, Al Gilman wrote:
>
>  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
>  > /-- 
>  
>  
>  
>
>--
>Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134 136
>W3C Web Accessibility Initiative                      http://www.w3.org/WAI
>Location: I-cubed, 110 Victoria Street, Carlton VIC 3053
>Postal: GPO Box 2476V, Melbourne 3001,  Australia 
>

Received on Monday, 17 July 2000 12:21:53 UTC