- From: Charles McCathieNevile <charles@w3.org>
- Date: Wed, 19 Jul 2000 00:18:10 -0400 (EDT)
- To: Al Gilman <asgilman@iamdigex.net>
- cc: w3c-wai-er-ig@w3.org
My thoughts and recollections, vague as they may be
No, I think GL is correct - it is to identify for user agents (ie through
markup such as map). We have asked for both handling of map, and the more
general structural navigation you speak of.
The specific reasoning was that a title or class was not going to be
consistently recognised by a user agent, and there exists a perfectly good
HTML element (first class element no less) that does what we want - the map
element.
This is how I recall it anyway. (The trigger is that Nir pointed out that
trying to reserve a class to meet the function of the map element was
reinventing wheels and making them square)
Charles
On Wed, 19 Jul 2000, Al Gilman wrote:
[First -- sorry Wendy, my bad -- I misread ATAG10-TECHS as a reference to
the WCAG [HTML] Techniques and so my references to ATAG10-TECHS were
nonsense. But I still have a slightly different idea of what WCA agreed
with UA back then.. Read on]
However, [Expletive!]. That "identify the group (for user agents)" bug is
in the WCAG itself. The "for user agents" is a mistake. The "identify the
group" was supposed to be for users: the TITLE on the grouping element. I
fell down in not reading the drafts closely and often enough as it went on
to final.
How to put it...
Did we ask UA for special handling for MAP or did we not?
Does a DIV, TABLE, or UL with a good TITLE meet the checkpoint?
What is the status of MAP on this point? It is the preferred grouping
element, it is suggested in the advisory technique in the Techniques document.
[so far these are WCA questions, so far as I can see.]
This leaves it open to interpretation just when replacing a DIV or OL with
a MAP is to be considered an improvement. [ER issue]
I misunderstood which Techniques document you were comparing with. But the
example AERT technique 13.6.1 goes beyond what I would consider reasonable
intervention, and I _would_ like this particular technique coordinated with
_GL_ based on the concerns outlined above. Sorry the example threw me into
a tangent vs. the methodological discussion you were trying to start.
Al
At 01:16 AM 2000-07-18 -0400, Charles McCathieNevile wrote:
>My 2 bits...
>
>I think Al is correct that we can get a long way without well-defined
>semantics marking collections of links, but my recollection of what was
>actually decided is the same as Wendy's.
>And there is value in having more specfic markup, when we try to make
>reasonably complex transformations. A list of links in a page that can be
>navigated is great, but a list where we additionally know whether some links
>are explictily grouped or just happen to occur in some order is even better.
>So I do prefer the approach that Wendy has proposed for HTML. Having a title
>means it might be human recognisable, but won't be machine-recognisable -
>that comes from predefined semantic terms, which is what the markup elements
>of HTML are.
What is machine recognizable is not the contents of the TITLE, but rather
whether it has a TITLE or does not. That is machinable, and is one of the
things that I would have the automatic table of contents extractor (also
know as structural navigation function) sensitive to.
If you actually thought that we were asking for machine recognition of MAP
as this function at that time, I think we blew it. Does the UAAG reflect
any special processing for MAP?
Al
[a few details below, but I think the sense is all above.]
>
>cheers
>
>Charles McCN
>
>On Tue, 18 Jul 2000, Wendy A Chisholm wrote:
>
> 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.
Here is a point of difference: I believed the consensus to be, and the
writeup that Wendy did then to mean, that MAP should be used when a new
element was required to achieve grouping; not as the grouping element in
all cases.
>
> 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.
Here is a source of a lot of the confusion. I misread which techniques
document you were addressing. I meant to say that the WCAG Techniques was
the baseline and WCA should be asked if we are going to recommend something
at variance with that.
>
> 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
> /--
>
>
>--
>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
>
--
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 Wednesday, 19 July 2000 00:18:16 UTC