Chair: Jon Gunderson
Date: Thursday, 6 January 2000
Time: 2:00 pm to 3:30 pm Eastern Standard Time, USA
Call-in: Longfellow Bridge (+1) (617) 252-1038
Chair: Jon Gunderson
Scribe: Ian Jacobs
Present:
Kitch Barnicle
Harvey Bingham
Gregory Rosmaita
Dick Brown
Denis Anson
Jim Allan
Mickey Quezner
Marja Koivunen
Rich Schwertdfeger
Regrets:
Charles McCathieNevile
David Poehlman
Agenda [1]
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0018.html
1.IJ: Draft a statement for time of publication, there is no authoritative
body that validates claims of conformance
Pending
2.IJ: Repropose the delivery mechanism of conformance statement to allow
documentation as an option
Pending
3.IJ: Propose a technique for using XSL to transform content
Done
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0030.html
4.IJ: Follow up on EH's e-mail with some comments from this meeting related to issue LC#138 (will post as new issues if any)
5.IJ: Publish a new draft of requirements document that incorporates JG'sand other comments.
6.IJ: Send this resolution of issue LC#158 to the list for comment.
Done
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0020.html
Objections from JG, DP.
7.JG: Review techniques for Guideline 8.3, 8.4, 8.6 to 8.9
Done (or almost).
8.JG: Draft a preliminary implementation report for CR consideration
Not Done.
9.DA: Identify the general items that apply to all software from ones in
the current list in Ian's requirements proposal.
Done
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0028.html
10.DB: Ask IE Team about publication of review of IE 5 and Pri 1
checkpoints.
Pending.
11.DB: Find out how developers find out which appropriate triggers to use in Windows for using built-in accessibility features (i.e. sound sentry, show sounds, ...)
12.DP: Propose new Checkpoint 1.5 for access to system messages
13.GR: Send to the list techniques for how to use and control focus to not have new windows cause problems for usability. In particular, how this will work with ATs.
14.GR: Write a technique on how to create accessible installation Satus: May already be integrated.
15.MR: Review techniques for topic 3.1 (Multi-media)
16.MR: Review techniques for Guideline 4 (Multi-media)
17.MR: Run a multimedia player through the guidelines for January.
18.MQ: Ask Mark about meaning of comment raised in Issue #167
19.RS: Send editorial comments on Ian's proposal.
Done
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0029.html
20.WC: Take form submission to GL WG to discuss issues related to
inadvertent submission.
Pending
21.EVERYONE: Review the "Unknown" category of Ian's proposal and
we'll discuss them at tomorrow's meeting.
Done.
1.Extra UA telecon scheduled 12 January 2000 at 12:00 pm to 1:30 pm Eastern
Standard Time, USA
http://www.w3.org/WAI/UA/2000/01/wai-ua-telecon-20000112.html
2.Protocols and Formatting are holding a FTF meeting on 26-27 January 2000
at Sun's Microsystem in Cupertino - Silicon Valley
http://www.w3.org/WAI/PF/Group/2000/01/agenda.htm
http://www.w3.org/WAI/UA/1999/12/ua-resp-19991228
DA: Recall, some of the "native" checkpoints apply to every app.
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0028.html
IJ: I may implement DA's list with, e.g., an asterisk to indicate which ones may be system-wide.
GR: I think this info should be put in the Techniques document.
KB: Don't forget that the UA may do it better than the OS...
IJ: On to the "Unknown list"
KB: Since we require device-independent access to active elements, I need to get at these with the keyboard.
KB: There's a debate on the "CHI" list about whether content brings interface.
GR: This fits in with the argument that UI provided by the author is on par with UI provided by the UA.
Resolved: Navigation of active elements required because these are user interface elements. If you can't identify an active element for activation, it's useless.
Add to category "Requirements for content rendered natively", though it's UI in nature.
IJ: This is just a special case of 7.3 and so once 7.3 is settled, this one will follow.
DA: If the content is streaming and it hasn't arrived yet, is it available for searching?
IJ: Searching is done in a time-independent manner.
MK: You can interrogate the server of the streamed text.
Action MK: Find out techniques for sending text search requests to servers of streamed text.
HB: Rendered text excludes many attribute values.
Arguments:
a) UAs already do this.
b) Searching is essential for people with disabilities and a convenience for
all users.
c) Users render the text content.
Notes: NN, IE, Opera don't allow you to search for it today.
Issue: Should searching equivalent text be an AT responsibility?
KB: Is it an argument that because ATs do this today that means that mainstream UAs should not?
RS: Suppose you have images turned on and search for alt text. You may confuse users by landing on the image.
IJ: But the text isn't rendered in that case. The goal is that: as soon as any user has access to the content, all users should have access to it.
Resolved: Create a category "The WG felt that this functionality is essential to users with disabilities."
Thoughts:
a) User shouldn't have to understand underlying structure of a document to navigate it, but should be able to navigate. Thus details of "structural navigation" left ambiguous.
b) No minimal requirement obvious except that navigation is required as an essential functionality, otherwise too burdensome to have to reread the page from top to bottom.
c) ATs may provide specialized navigation, but some native implementation of navigation essential for access.
d) Structure available through the DOM. The Guidelines should encourage navigation in a manner appropriate for the rendering handled by the type of user agent being used.
DA: If we say that you have to do something natively, we have to be able to say what to do.
JG: This is closely linked to 7.6 for me. Like searching, it's a way to access content.
JG: Structured navigation hasn't been a requirement for desktop user agents.
IJ:
- Backwards compatibility issue? Require structured navigation until the DOM is
available.
JG: This functionality is useful for different media. Opera does this. Auditory browsers do this. We think that general purpose user agents should incorporate these for general audience.
IJ: Native structured navigation gets you part of the way for others.
KB: Structured navigation will help some users with disabilities: low vision, motor impairments.
Resolved: Essential functionality for some users with disabilities (low vision, physical).
IJ: This one follows 7.6
KB: The UA should convey all of the information specified by the author. I don't think we can ask the UA to go beyond what the author has specified.
IJ: Agreed. This is a special case of "access to all content".
DB: What does "purpose" mean? There's no "purpose" attribute?
GR: Minimal satisfying of this checkpoint: tool tip of the "summary" attribute.
Resolved: This is an important special case of access to content.
GR: (For the record, I think 8.3 (link info) should be P2).
DA: As user agents start to render summary, etc. authors are more likely to provide the information.
IJ: I think that it's important to make relationships inherent in markup available to all users, and developers may not realize this.
RS: Does 8.1 mean through programmatic means?
IJ: Not specified.
Action IJ: Make clearer that this is "information provided to the user."
DB: I'm not sure this should be P1. This is a tricky one since I don't think it's impossible to get at the information.
Summary:
1) WG decided that table navigation was important, but could fall under general structured navigation provided that table semantics be preserved in a checkpoint as a native requirement.
2) This is important to render, whatever medium you're rendering to.
3) Important for users with blindness, motor disabilities, and cognitive disabilities since you have to memorize header information.
IJ: In this case:
- Render to user in the way you're rendering (e.g., graphically).
- Provide programmatic access (covered by DOM).
(In short, IJ doesn't think a change necessary since rendering is always "However you render it...")
Action Ian: Harmonize language in the spec so that a single expression is used to indicate "provide information to the user". (as opposed to programmatically). Indicate both explicitly when both.
Resolved: Leave "unknown" for now.
DA: This is a P2.
Resolved: Essential functionality for some users that must get through content serially or cognitive disabilities.
IJ: If native configs only, the issue is resolved (since configs provided natively).
DA: You could have a macro program that intercepts your keystrokes before they get to the UA.
Resolved: Required natively since it mostly addresses natively provided functionalities.
IJ: This is a special case of 10.8.
Resolved: These controls are provided natively by the UA.
Action IJ: Indicate that this is a special case of 10.3
Adjourned 15:38 ET