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

Al,

You suggest that the WCAG group needs to be asked for clarification on this 
issue.  You also state that this is not in alignment with what was decided 
in a discussion with UA.

WCAG had a joint meeting with UA on how to markup "navaids" as you call 
them.  It was my interpretation of that discussion that MAP ought to be 
used.  I sent a proposal to the WCAG working group a while back and added 
what was agreed upon to the HTML Techniques for WCAG 1.0.

What I have proposed for the AERT is merely an extension of that 
proposal.  No where did I hear that the UA/WCAG agreed that a title on a 
container element was enough.  MAP needed to be used to contain the 
navigation bar links.

Note that I am not proposing that <em>all</em> links be enclosed in 
MAP.  Is that where the confusion is stemming from?  I am only referring to 
links that are used as "navaids."  Thus, it is up to the user interface to 
help the author decide if the identified group of links is a navigation 
bar-type thing or not.  If it is, then the proposed AERT technique would be 
invoked.

If there has been further resolution within the UA group (re: only using 
"title" on containers of navigation bars) I do not believe that either WCAG 
or ER has been made aware of these resolutions.

I disagree that what AERT needs to state is what is currently in the 
ATAG-TECHS.  All that the ATAG-TECHS says is " Ask authors if lists of 
links are a group and should be a map. "  The whole point of AERT is to 
provide algorithms sans interface descriptions of actions an evaluation 
and/or repair tool should perform.  Otherwise, there is no need for AERT 
and we can keep it all in ATAG-TECHS.

Note that the main point of this message is to determine what should be in 
AERT and what should be in ATAG-TECHS and how they ought to link to each 
other and WCAG and WCAG-TECHS.

The actual proposal for technique 13.6.1 is included in another message 
[http://lists.w3.org/Archives/Public/w3c-wai-er-ig/2000Jul/0026.html]. 
Please refer to that thread.  The text in this thread is what currently 
exists.  note that it has changed significantly.

--wendy

At 12:25 PM 7/17/00 , Al Gilman wrote:
>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
> >

--
wendy a chisholm
world wide web consortium
web accessibility initiative
madison, wi usa
tel: +1 608 663 6346
/--

Received on Tuesday, 18 July 2000 00:24:20 UTC