Raw minutes from 26 September UA Guidelines WG teleconference

Date: Tuesday, 26 September 2000
From: Eric Hansen 
To: w3c-wai-ua@w3.org
Subject: Raw minutes from 26 September UA Guidelines WG teleconference Eric
Hansen

Present:
Jon Gunderson (chair)
Ian Jacobs
Eric Hansen (scribe)
David Poehlman
Al Gilman
Gregory Rosmaita
Tim Lacy
Richard Schwerdtfeger
Mickey Quenzer (last half of meeting)

Regrets:
Jim Allan
Kitch Barnicle
Denis Anson
Charles McCathieNeville
Harvey Bingham

Next meetings: 

  Tuesday, 3 October (extra, 13:30 - 14:30 ET)
	Ian will try to attend.
  Thursday, 5 October (regular, 14:00 - 16:00 ET)
Ian may not attend.
  
Agenda:
  http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0423.html

Minutes of previous meeting 21 September:
  http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0415.html


Announcements

    1.Extra teleconference scheduled for 3 October 2000 at 
      1:30-2:30 EST USA

    2.Face-to-face meeting update

	JG: Judy is contacting AOL and Adobe about hosting a face-to-face
meeting. Possible dates are about 16-17 November 2000. That meeting would
hopefully be fore processing Last Call issues. Or we could also talk about
what to do after recommendation.

	2. Proposal to Chairs -- Dates for going to Last Call

IJ: I proposed to the Chairs a range of dates for going to last call. We are
getting near the end.

Discussion

    1.Issue 314: How to distinguish "important elements" (not just type?) 
Comments from Al Gilman on 7.6
      http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0312.html


JG: Charles sent a proposal then withdrew it. Al is heavily invested in
this. Charles wanted some kind of hierarchical structure. I sent memo that
distinguished between explicit structure (e.g., H1, H2, etc.) and implicit
(e.g., style-based indications of structure). I wanted to include a list of
important elements. I want a Priority 3 set for important _style_ elements.
I would like to have the user agent user able to find out the number of
things of a certain type (orientation section). Al had comments.

AG: I want to tie together orientation and navigation. Starting points are
important for orientation. Explicit indications of a structural role are now
there. What is missing, if there is no structural navigation, is the ability
to have effective control over what they see. People design for a GUI and
put in a lot of extra data that is beyond the main payload [content].
Headers are high quality locations to start reading, but they are not
containers.

GR: We had a joint meeting with WCAG. I looked at vendors to support jumping
to headers. I asked [vendors] about mechanisms, but have not received
feedback.

AG: I think that checkpoint 7.6 includes too much. We need the "seven league
boots" version -- [i.e.,] something with a coarser grain. Need to be a
manageable number of chunks for a quick overview. Top view is the most
important. The user agents should be able to find a table of contents and
tell you that there is one. My solution would be to skip the sub-tree.

JG: We could have a capability for skipping an author-identified site
maps/tables of contents. 

AG: Yet we have a capability for navigating between parent and child,
[etc.].

EH: Would this be DOM-based?

AG: It could be DOM-based. Minimum requirement could be [to navigate] the
DOM. WCAG should require putting NAV bar in a MAP.

GR: MAPS could be used to contain the table of contents. But Mozilla will
not now render this.

JG: That [Mozilla] could be changed.

*** Mickey Quenzer joins. ***

JG: We might require an author-defined collection of links. 

AG: I would settle for substructures within the page.

JG: Will this be H1 and H2?

AG: I claim that they are hotspots.

MQ: Yes!

AG: They are good starting points [but not containers]. If you look at front
page of a Web site, down the left side you see a list, such as of
"departments". On the right side you see [hot items for] "sales". We should
include both.

MQ: Navigation is important.

*** Ian rejoins ***

MQ: With WebSpeak we can look for almost any HTML. But we also look for
subheadings (H2, H3, etc.). People [users] don't use them but _we_ use them.
For devices with small displays, navigation is more important. A screen
access program does not tell what is on left and what is on right; I cannot
tell. We still get things linearly with JFW and WebSpeak.

GR: Evaluation and Repair Techniques document [calls for] a repair view.
Suggests an outline view. 

JG: We should point to techniques for repair. 

Action: JG will send to IJ and the group information about the Evaluation
and Repair utility. 

IJ: I want to converge [on a solution for this issue]. That information
[about evaluation and repair] is not crucial to last call.

JG: (Summarizes). These are important elements. Al says elements should be
informative, not required.

GR: I propose that the list of elements become informative.

JG: The minimum requirement should be forward and backward. In 8.4 we have
outline view.

IJ: 8.4 and 7.6 are separated for a reason. The two are not inherently
bound.

AG: [Comment not heard due to line noise.]

IJ: I am not against merging 8.4 and 7.6.

AG: Nothing in 8.4 talks about summarizing. 7.6 does not mention
abbreviating the list. That is too bad. We need to abbreviate 7.6.
Summarizing needs to show up in 7.6. A possible minimum implementation would
include orientation to what is in a page. Require the user agent to select 7
plus or minus 2 major navigable points in an overview of the page, [perhaps
with additional] alternate starting points.

EH: (Summarizes)

IJ: We have heuristics. 

IJ: We have a proposal. Pull out the normative list and make them
informative. Increase navigation through forward and backward. In 7.7
configuration is already in. I am not sure about 8.4 and 7.6.

JG: Allow forward and backward movement. 7.7 allows one to control important
elements.

MQ: I like Al's suggestion about "departments" and "specials".

AG: [The principles are] chunking and repair. The pattern that I described
is descriptive of half the Web, yet [the mechanisms for implementing vary
greatly -- tables, frames, absolute positioning. The design style itself is
quite consistent and stable. 

IJ: Al will send some HTML code. Len [Kasday?] is making a counterproposal.

JG: Proposal for linking 8.4 and 7.6. I like them separate. They can have
the same configuration phrases. Both provide summary and navigation.
Eliminate 8.4. Configuration for 8.4 would be done through 7.7 (as for 7.6).

Again, for 8.4 and 7.6, share the configuration. Get rid of 8.5. These
changes will allow 8.4 and 7.6 to concretely work together. I like them [as]
separate [checkpoints]. 

AG: I would _like_ to have a sliding scale that would allow users to adjust
between nearly all "orientation" and nearly all "navigation". 

IJ: That would be good, but I would not know how to encode.

AG: (Agrees that that is a real problem.) 

IJ: To summarize, we will make "important elements" informative [rather than
normative]. Thus, there are two dimensions. On the "set of elements
navigated" dimension, we "punt", [that is,] provide [non-normative] clues.
On the "navigation abilities" dimension we make a specific requirement. 

AG: I [still] think that we can put in a minimum requirement in the
configuration [capability] to "be brief" [e.g., (?) make brief (i.e., 7 plus
or minus 2)].

JG: Thus, important elements will be informative. Navigation will go both
forward and backward. The some configuration requirements will apply to both
7.6 and 8.4. We also need to talk about requirements for identifying what
Al's functionalities are.

RS: Keep in mind that in an audio browser the capability for looking
[moving?] forward and backward may be mode-dependent.

JG: Home Page Reader (HPR) has allows forward and backward movement in a
list.

GR: I will send to the UA list refinements to the wording of 7.6 that I
think fit with the resolution.

JG: Resolution (is as I have said [see below]).

JG: The only other thing is this possible requirement to tell the user how
many instances there are of a certain thing.

IJ: For context [background information], earlier requirements to indicate
the "number of things" have been removed.

AG: (Indicates that there were reasons to remove such requirements)

Resolved:

	For issue 314:

      1. Make lists of important elements informative
      2. Make minimal navigation requirements forward and backward
      3. Use same configuration for important elements 7.6 and 8.4
      4. Talk about Al's and others functional requirements for identifying
important elements (element type and number of resulting navigable elements)

Open Issues:

    1.Issue 317: Proposal to reduce number of applicability clauses for
conformance to a checkpoint
      http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0388.html

    2.Definition: Use of the term primary content
      http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0178.html

Open Action Items

    1.IJ: Propose text for a note explaining the implementation issues
related to providing user agent generated content through the DOM

    2.GR: Proposed repair checkpoints

    3.KB: Submit technique on providing information on current item and
number of items in search

    4.RS: Send information (if you can) about tagging for information for
improving performance

New Action Items

	1. JG: Talk to Ian about adding a column to the impact matrix for
supporting authors in creating accessible content.


===========================
Eric G. Hansen, Ph.D.
Development Scientist
Educational Testing Service
ETS 12-R
Princeton, NJ 08541
609-734-5615 (Voice)
E-mail: ehansen@ets.org
(W) 609-734-5615 (Voice)
FAX 609-734-1090

Received on Tuesday, 26 September 2000 17:25:15 UTC