Chair: Jon Gunderson
Date: Tuesday, 2 May
Time: 1:30 pm to 3:00 pm Eastern Standard Time, USA
Call-in: Longfellow Bridge (+1) (617) 252-1038
Chair: Jon Gunderson
Scribe: Ian Jacobs
Present:
Gregory Rosmaita
Denis Anson
Mark Novak
Jim Allan
Al Gilman
Kitch Barnicle
Harvey Bingham
David Poehlman
Rich Schwerdtfeger (late)
Eric Hansen (late)
Regrets:
Dick Brown
Absent:
Tim Lacy
Charles McCathieNevile
Mickey Quenzer
Hans Riesebos
Madeleine Rothberg
Next teleconference: May 4 at 2pm ET. Agenda [1] [1]
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0248.html
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#207
Refer to proposals:
GR: Discussion of property sheets.
JG: Scroll bars are important.
IJ: This is in the definition of "viewport". I don't think this needs to be a UA Guidelines requirement since it affects all users.
Resolved: No need to include a "scrollbar note" since it's in the definition of viewport.
Proposed: One goal of 2.1 is to make equivalent alternatives readily available in the same view.
AG: Does this cause us to exceed the scope of Guideline 2? The proper composition of views gets into presentation, whereas G2 is just about exposure (you have to get to it).
IJ: I see no problem with moving it to another checkpoint.
AG: You might want to organize the objective of "staying close to the
author's view" in another checkpoint.
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0269.html
/* Discussion of view as a "take on the data" (e.g., table of contents view) */
AG: The term "view" in the database community means something different: checklist of what's presented.
Resolved: Split 2.1 into: 1) Ensure that the user has access to all content. 2) Make equivalent alternatives readily available in the same view.
IJ: 'The term view is used in this document to describe the purpose of a particular rendering (e.g., "outline view", "table of contents view", "links view").'
AG: The user agent must support permutations of an object ('equivalents') within the same view.
AG: I think the objectives are valid, but may need to go somewhere outside of G2. Proposed: Provide synchronized views of content. (In the sense of coordinated but different views of the same content.)
JG: Should this be a checkpoint to make it easier to find information in views? Or just a technique?
IJ: 1) If you have synchronized views, you are supposing at least two views. What are those views?
MN: Most browsers already provide at least one view.
GR: It's important that synchronization is important if you provide an outline view.
GR: Issue of different levels of detail in views and how those are coordinated.
JG: Both Amaya and Jaws offer synchronized views.
JG: Are synchronized views important for accessibility?
GR: Yes.
DA: Yes, but P2.
DP: Yes, at least P2. E.g., from a link list, you need to be able to find out where the link occurs on the page.
MN: I can see accessibility issues, but not sure this requirement part of G2.
JG: Maybe part of the orientation guideline.
KB: Without having views synchronized, the value of the additional view might be substantially lowered.
IJ: I think this a new requirement and would pretty much guarantee that we will have to go back to last call.
KB: (to GR) What additional functionality would this requirement offer that's not covered in other checkpoints?
GR: What's missing is that there's no explicit requirement that alternative views be synchronized with an original view. I think it's also related to point of regard.
IJ: We also need to consider the impact of how focus is controlled among synchronized views.
JG: How crucial is this requirement for UAAG 1.0? Can it wait?
/* IJ forwards that a last call means we might get to Rec at the beginning of September */
Resolved: - Add a checkpoint to G8 requiring synchronized views when more than one. - Review this change alongside other changes to the document. - Evaluate later whether this is the make-or-break checkpoint for advancing quickly; decide then whether to keep it.
JG: We might also consider highlighting this as part of 8.6, then making a more general requirement in another version.
Proposed: Add access to only the attributes of a selected element.
JG: I withdraw this proposal since I've not heard much support for it.
AG: I think this is a useful technique, though.
Action IJ: Add this as a technique.
IJ: By the way, how have we resolved the original question about a source view?
AG: Move all discussion of source view and property inspection to techniques discussion in the guidelines document. This section should say the following things: - Property inspection is expected to be significantly more usable than source view for many properties. - Source view may be the most usable readily-achievable view for some content such as embedded fragments of style and script languages. (quoted from http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0269.html)
JG: A source view is part of a solution, but is not a solution in itself. Resolved: A source view is part of a solution for providing access to content, but is not a sufficient solution on its own.
IJ: The question from the start, to me, was "how much content has to be made available through the primary view"? How have we answered that?
IJ: I've heard us answer "we draw the line at alt content" in the primary view. And the rest of the content is available through the sum of all views.
AG: Yes.
Action IJ: Update the document with these resolutions.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#233
AG: I propose that in techniques we move away from headers as containers and towards headers as good starting points. The guideline should be to use what the author gave you as structural clues (even in preference over what the spec says). I think that the DOM as the basis of doc structure is insufficient (due to real-world "mis"-usage). Use what the author gave you.
AG: You can even reasonably guess that headers used to change font sizes are still important starting point.
AG: User agents should be encouraged to provide navigation among starting points marked up by the user. Headers or structuring elements such as forms and tables. E.g., MAP with a "title" for navbars.
IJ: What's the minimal requirement if we ask user agents to do what is not defined in the spec?
AG: I'm not suggesting that we should require UAs to follow heuristics. Only to accept that this document will not meet all requirements, and that we have to address repair strategies and possibly consider more in later versions.
AG: However, you can do a lot to call out important elements/structures in the techniques document. The HTML spec may not go far enough to highlight what's important for structured navigation.
DP: I think Phill has said that you have to remain close to what the markup language spec says. I think we are saying "If a document conforms to WCAG, please render it appropriately."
IJ Summarizing: - Minimal requirement is navigation of document structure. (elements). However, you need to add filtering before its useful. - This will not solve all accessibility problems today due to how markup is used in practice that doesn't conform to specs. - We should not try to solve all these problems in this version.
AG: Minimal requirement is navigation of document structure. (elements). However, you need to add filtering before its useful.
IJ: What about the proposal from last week? "Allow the user to navigate efficiently to significant parts of content."?
AG: Yes, I like the idea of including something about some of the goals.
AG: Hitting the high spots is only part of structured navigation. Tables is an exception. But in general, the table of contents structure will do: and the definition is recursive (what is important changes as you change contexts, go deeper).
/* RS joins */
Proposed: "Allow the user to navigate efficiently to significant parts of content." NOTE: "significant" changes as you navigate.
AG: Hit both TOC and table example in the proposal.
Action IJ: Propose checkpoint rewording to list.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#279 Refer to RS proposal: http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0232.html
RS: I wouldn't mind leaving 9.2 as is and stating that to minimally satisfy the requirement, a user agent can prompt for all form submissions. I looked at IE, and based on what they have, it doesn't look difficult to do.
IJ: I agree that RS's proposal would satisfy the requirement of 9.2.
Resolved: Leave checkpoint as is. Checkpoint satisfied if the user can configure prompts for all form submissions.
Action IJ: Modify document accordingly.