These are three options I am aware of for markup related to navigation bars
or in general grouping of links. Please respond with your own ideas or
comments. FOllowing the options is a list of some of the archived e-mail
discussion on the issue.

Option 1:
Using the DIV element and some type of CLASS or NAME identifier:
PROs: Easy to implement and author
CONs: There is no mechanism to reserve class names in HTML, there could be
conflicts if specific class names are usedOption

2:MAP element
PROs: Currently used for image based navigational barsCONs:
1. More complex than DIV to author
2. What if authors did not want to use images in their navigation bars

Option 3: Schema
Schemas are a potential way to indicate the purpose of content or structure
PROs: Proclaimed as the right method for the job
CONs:
1. New technology and still under development
2. Not currently supported by UAs,
3. Not clear how easy to author
4. Not clear how easy for AT to decode and use information

Comments: The attributes for a form control include references to labels or as part of a collection that is defined by other HTML markup.
The attribute values of label can be part of the list of form controls.

Comments: The definition of a block level element or what navigating a block at a time needs careful definition. There are many blocks like list and tables that would be useful to give summary information when the block is first encountered. Like saying a "list of 12 items" when the block is first encountered, and then the next block navigation command would read the first item in the list and so on....

Comments: This is primary using HTML markup to indicate the function or purpose of a link for creating sub groups of links to let the user navigate. For example navigation bars, and other logical groupings of links in a document. It will be part of a more general checkpoint on searching based on attribute values

Resolution summary: This is issue is out of scope for our working group right now. PF is aware of the issue and made recoommendations to the XML working group reguarding this issue

Resolution URL: Not resolved

First working draft: No reference

Comments: This issue cannot be resolved right now. The XML working group is currently dealing with the issue and the WAI UA group is also aware of the issue and may include recommendations.
The most UA would do at this point is include recommendations on recognizing or retreiving XML markup to allow semantic information to be available locally.

Comments: PRO: Allows user to know all elements that could potentially change content of document
CON: Many elements may be included in the list of active elements that do not respond to events (event bubbling) and some events may be decorative and therefore not important for people to have access

Comments: 2) Modify Guideline 7.1 to include these checkpoints:
a) Implement W3C specifications when they are
available and appropriate for a task and
implement the latest versions when supported.
Note. Some W3C specifications are
cumulative (e.g., HTML 4.0, CSS, DOM).
b) Implement accessibility features defined by supoprted
W3C Recommendations. [The techniques would provide
links to documents where these are defined.]
c) Support deprecated features of W3C Recommendations.

Comments: Currently compiling a list of meta data and make sure we have appropriate examples in techniques document.
Conference call with gl at:
http://www.w3.org/WAI/GL/meetings/19990909.html#agenda
The had no general ideas

Comments: Should we have a checkpoint explicitly for text renderings of client-side
image maps (e.g., using "title" in HTML) to match with WCAG 1.0 checkpoint
1.5? OR should this be a technique for checkpoint 1.2?
Need a technique for technique document

Comments: Checkpoint 5.11 in 9 August draft talks about turning on/off support
for spawned windows. I propose that we rephrase this as "Ensure that users know
when new windows are spawned or allow them to turn them off." The goal is
to prevent disorienting behavior. This may be achieved by a number of mechanisms,
such as a history mechanism, a warning mechanism, or turning off spawned windows.
Refer to proposal to delete this checkpoint and ff.
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0212.html

Comments: Specialized browsers support speech and Braille primarily and therefore are not "graphical". While they are an assistive technology, they typically are not dependent on a "graphical" browser for rendering accessible information

Comments: Proposed:
Refer to [1] http://www.w3.org/WAI/UA/WAI-USERAGENT-19990809
We could either:
a) Expand the scope of the guideline to something like
"Support Open Specifications and Known Accessibility Features"
We might add a checkpoint to the effect of "Support open standards",
but I'm not convinced of the necessity.
b) Reduce the scope of checkpoint 11.1 to be: "Implement
accessibility features defined for supported W3C technologies."

Resolution summary: IJ: Proposed a) Move dependent-UA checkpoints to an informative appendix of the Guidelines. b) Add checkpoint about requiring a selection (structured or unstructured). c) People will review the next draft and decide whether the split is ok.

Comments: Based on Thatch issue: What does selection mean?
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0110.html
See also Charles proposal:
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0245.html

Comments: From 9 August version, 9.3
http://www.w3.org/WAI/UA/WAI-USERAGENT-19990809/
Thatch: The wording is not good. Don't we already have a
'navigate' by structural elements. Is this a technique for 8.6?
CMN: I agree.

Comments: Detailed Issues list:
7.2 For dependent user agents. Ensure that the user has access to the content of
an element selected by the user.
The word "selected" gave me lots of problems. Since "selected" has a very
different and very common meaning, I wish a different word or phrase could be
found. I tried using "the current," rather than "selected by the user" and in
HPR I think that works.
9.16 Identify a link selected by the user.
9.19 Identify a table selected by the user.
9.23 Make available the coordinates in the current table of a selected table
cell
9.22 Identify the table containing a table cell selected by the user.
9.2 For dependent user agents. Provide the user with information about the
number of viewports.
Probably one example would clarify this for me.
9.10 Make available the number of links (to distinct targets) in a document.
9.11 Make available the number of visited links (to distinct targets) in a
document.
Why is this accessibility? Who cares about the number of visited links. And the
requirement of distinct targets vs links seems out of line as a guideline.
9.17 Make available whether a chosen link (target) is local to the document.
This does not seem to be an accessibility requirement. Does it have something to
do with "downlevel" browsing configurations.

Comments: Group could not reach consensus on:
1. Author and user agent input configuration information have the same importance for accessibility
2. Are author defined input information support by the user agent part of the UA functionality or separate functionality from the UA
One proposal has been: a single P2 checkpoint.
And from Martin Duerst:
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0614.html
> - 10.1/10.2: I personally feel that showing author-set
> configurations is at least as important as user-set;
> many (not all) users may be able to remember to their
> own settings, while nobody will know author settings.
Discussion 10 December in Austin
http://www.w3.org/WAI/UA/1999/12/ftf-19991210#issue-112
Resolution proposal by chair
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0145.html
5 voted to accept proposal
3 voted to not accept the proposal
Chair overruled 3 objections and asked them to develop a minority opinon on the topic

Comments: 1) Taken to PF.
2) AG feels should be in UAGL/UAT
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0374.html
3) Proposed checkpoint from Al's distillation of Todd's comments:
Furthermore, we should consider adding a checkpoint abstracted from Todd's
techniques to the effect that there should be one control in the UI which
accomplishes a general increase or decrease of the font sizes throughout
the document, while preserving size ordering of different text fragments to
the maximum extent with user directives.

Comments: Proposed change:
"If a user agent offers a functionality, it must ensure that [CHANGE]
people with disabilities [/CHANGE] have access to that functionality or an
equivalent alternative." (my revised definition of "Applicable
checkpoint"). This change from "all users" to "people with disabilities" is,
in my view, essential because:
1. It keeps the UAAG document within scope. We have no authority except as
it relates to accessibility, i.e., use by people with disabilities.
2. It may limit the unintended negative consequences by potential reducing
(or minimizes increased burden) on developers.
ALso: Since people can't find this definition, put back in conformance section.

Comments: Refer to Earl's proposal for creating two "buckets" within each
Guideline: one for Content, one for UI. WOuld there be other buckets?
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0560.html

Comments: > Checkpoints for the UI - a major design access problem we run across is
> windows that don't give an object input focus when they're made
> activate. I'm not sure if it should be here or under guideline #7, #8,
> or #9 but a checkpoint should say that a component needs to be assigned
> input focus for the content -and- feature control portions of the UA
> UI.

Comments: Refer also to comments by Martin Duerst
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0614.html
> - 10.3: Single-stroke/single-key: Does this include modifiers
> or not? There are in general not enough keys to have one
> (unmodified) for each function.
Proposed: We need to clarify that 10.3 does not refer to ALL functionalities
being bound to a single key.

Comments: Comments also from Chuck Hitchcock:
> Guideline 8: In the paragraph that follows the 3 bullet items, I would
> change "learning disabilities" to "cognitive disabilities". This is a bit
> broader and will include those who have orientation problems that are not
> related to specific learning disabilities.

Comments: > 1.5 Says that all messages to the user must be available via all output
> device APIs. [Priority 1]
> That sounds like the UA must talk (to send messages out of the audio
> channel) if it beeps (uses the audio channel for beeps). ??
Refer to ftf discussion
http://www.w3.org/WAI/UA/1999/12/ftf-19991209#issue-142

Comments: > For convenience here are the guidelines in question.
>
> -----
> Guideline 3. Allow the user to turn off rendering or behavior that may
> reduce accessibility
>
> Ensure that the user may turn off rendering or behavior specified by the
> author that may obscure content or disorient the user.
>
> -----
> Guideline 6. Implement open specifications and their accessibility features
>
> In particular, implement W3C specifications when they are appropriate for a
> task and follow accessibility guidelines for those specifications.
>
> -----
> Guideline 5. Observe operating system conventions and standard interfaces
>
> Communicate with other software (assistive technologies, the operating
> system, plug-ins) through applicable interfaces and observe conventions for
> the user interface, documentation, installation, etc.
>
> -----
> Guideline 9. Notify the user of content and viewport changes
>
> Alert users, in an output device-independent fashion, of changes to content
> or the viewport.
>
> -----
> Guideline 10. Allow the user to configure the user agent
>
> Allow users to configure rendering, mouse, keyboard, the user interface,
> etc. to facilitate daily use of the software.
>
> Compare these to the rest where the titles really are short enough or
> telegraphic enough that they look like titles instead of guidelines.

Comments: > For example, even though a sighted user has to explicitly scroll to see a
> page that is longer than a screen, a blind user should not have to worry
> about scrolling a "screenful" vertically. Similarly, the blind user should
> not have to scroll horizontally if the display is wider than the physical
> screen, or scroll through selection lists a chunk at a a time.

Resolution summary: Change 10.5 to P1 "Avoid default input configurations that interfere with operating system accessibility conventions." and Move first sentence of note afterwards to techniques for 5.6

Resolution summary: Changed text to 2.4: When no text equivalent has been supplied for an object, make available author-supplied information to help identify the object (e.g., object type, file name, etc.).

Comments: What if the resource is not easily nameable (e.g.,
the URI is part of a query to a database)? (The same argument may
be made for object type, but there may be more information, e.g.,
"type" attribute HTTP headers, etc. to identify object type).

Comments: I'd suggest that if the user interface here is designed with
accessibility in mind, the user should not have to know about
the object technologies. "Please turn off blinking things" would
be a convenient request to the user agent. If the user agent
allows the user to turn off the objects through other means
(e.g., by turning off scripts), then this would also be
sufficient, but the user agent should document that this is
how the user can achieve this particular goal.

Comments: From Mark:
> My suggested policy (and one that I would certainly include in any fine
> > print regarding conformance), is that the content is only certified
> > accessible using my UA IF the content being rendered meets the WAI Content
> > Authoring Guidelines. Of course my UA will do the best it can with
> > inaccessible content, but I cannot guarantee accessibility to all content.
> > Can this be expressed clearly in the Guidelines where conformance is
> > discussed?

Comments: > GV#13 -----------------------------
> 3.4
> What does natively rendering audio mean? A browser can't make a sound
> except by doing it through the speaker. Does this refer to directly
> driving the speaker -- not through the operating system? Is that
> possible anymore? Does anyone do that?
>
> Techniques document should explain what "natively rendering audio" means.

Comments: Refer also to Wendy's comment from
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0544.html
1. Checkpoint 1.1
I found it very confusing to have so many special cases for checkpoint
1.1. Parts of the checkpoint are too generalized. I think it would be
hard to determine when it was satisfied. Therefore, I suggest breaking it
out into X number of separate, stronger checkpoints.

Comments: First, regarding Guideline 4.18, user control over UA-spawned
viewports: seems to me that this needs to be a Priority 1
guideline. Currently, UA-spawned viewports "break" the
history mechanism completely, and they provide the user with
no cue(s) for understanding why basic UA functionality has
suddenly stopped working. Further, I can't see how it'd be
possible to implement Guideline 7.2 (a Priority 1) without
*also* implementing 4.18; a promotion is clearly in order.

Resolution summary: 1) Add (back the old) checkpoint for visited/unvisited links P2. If you don't have access to that information is to follow a link and then return. For complex pages, this becomes an unreasonable burden for people with non-graphical browsers or cognitive disabilities. 2) Leave 8.3 and 8.7 as is (removing visited).

Comments: > Second, regarding Guideline 8.7, user control over information
> regarding links: again, I wonder if a promotion (to a Priority
> 2) isn't in order. It's easy to imagine several scenarios in
> which user control over link information would be crucial to
> maintaining the overall "visibility of system status," which,
> in turn has been extensively documented as a key element in
> software usability. For example, consider UAs that do not
> support a particular scripting language; a page full of links
> that, in turn, rely on that scripting language will be
> utterly unusable, and the user needs the ability to discover
> *why* the page in question is "broken."
>