Chair: Jon Gunderson
Date: Thursday, Feburary 24th
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
Gregory J. Rosmaita
No change on any of these:
1.IJ: Propose checkpoint to address event notification timing issue
2.JG: for 5.3: Find out windows/mac accessibility guidelines.
3.JG: Check with Ian about adding reference in 4.5 to 4.6 in regard to stepping through animation/video/audio.
4.DB: Ask IE Team about publication of review of IE 5 and Pri 1 checkpoints.
Status: notes have been reconstructed
5.JA: Rewrite techniques for 3.3 (see minutes)
6.MK: For 4.8 check if any media players do this?
7.MK: Find out techniques for sending text search requests to servers of streamed text.
8.MR: Review techniques for topic 3.1 (Multi-media)
9.MR: Review techniques for Guideline 4 (Multi-media)
10.MR: Run a multimedia player through the guidelines for January.
11.RS: Take timely and synchronization issues to WAI PF. Get input from MSAA developers as well. Craft email to PF WG with Ian
Resolved: Add this checkpoint, but say "access to content" only (don't emphasize "write"):
Provide programmatic access to content using standard APIs (e.g., platform-independent APIs such as the W3C DOM, standard APIs for the operating system, and conventions for programming languages) [Priority 1]
HB: Is it a problem that there is not a closed set of standard APIs?
RS: Do we want to say "standard or published"?
JG: Express preferences in the document:
- Expose information through accessibility APIs that are platform specific.
- Use formats based on XML.
Issue CR#190: Reduce the scope of 5.1 to say "write access only for
that which you can do through the UI."
Issue CR#203: Checkpoint for access to content for non-HTML or non-XML
WWW documents (i.e. Shockwave)
Resolved: Replace 5.1 with:
Provide programmatic access to XML amd HTML content by conforming to the W3C Document Object Model (DOM) level 2 Core and HTML module specifications and exporting interfaces defined by those modules. [Priority 1]
IJ: How do you define export? What's the scope of export?
IJ: Is content source content or rendered content?
Action IJ: Find out whether rendered content from style sheets appears in the document source.
/* DOM Level 2 CSS Module */
JG: Do we add a checkpoint to access style sheet information?
JG: May be useful since the AT may want to access style sheets that aren't used by the user agent.
RS: I think that this is important. For example, suppose you had an audio style sheet and the browser doesn't support it. You should be able to navigate the DOM and attach style.
IJ: Pseudo-elements are not in the DOM tree.
IJ: ATs definitely need to know 'display: none', for example.
RS: You might want to set high contrast through the AT.
IJ: But you also need to be able to do this through the browser's UI.
IJ: I'm not convinced of the need to write styles. I see the need for computed property values since the AT doesn't know the browser's default value.
IJ: This is tricky. We've talked about searching on rendered content. This is source + style sheets + user settings. So you need more than the source tree.
RS: Add caveat that if a browser support style sheets it needs to do this.
JG: That's part of the applicability clause.
DA: Should we have generic language that requires access to the rendering structure?
JG: I'm afraid to refer generically to the rendering structure.
a) You want to know what the host browser has rendered.
b) You don't want to depend on that rendering.
IJ: I think that the CSS DOM is not required for access by ATs because they either should apply style sheets themselves, of if they are relying on the rendered content, the access to style doesn't matter. I think you need access to style sheets, but not to edit them.
HR: Suppose I'm interested in rendered data. When I change the style sheets, I can make links stand out in some special way. I might want to change the style sheet to see that the rendering is a particular.
IJ: The browser needs to allow this through user style sheets. But you don't need to do this through the AT (programmatically).
IJ: In short: You need the style sheets, but I don't think you need the DOM CSS module.
RS: Have a general requirement that for other supported DOM modules, to export the information.
JG: Do we need a requirement that the AT have access to what's really being rendered? There's an issue of computation time required by the AT to come up with a rendering structure.
MQ: There may be contexts where you want the source (plus style sheets) and some where you want the rendered structure.
IJ: How do you provide access to what's rendered?
HR: Today, an offscreen model is used. How would programmatic access to the rendering structure help ATs? If the AT only gets the full content, it has to do its own rendering and becomes a full user agent.
DA: Can we talk about being able to write a style sheet? The Kurzweil 3000 is a screen reader/scanner for reading disabilities. Something that works well: having a word spoken and highlighted in the rendered document. Thus, the AT would like to have access to the rendered structure.
RS: One of the things the DOM WG is considering for DOM 3 is the concept of views. Related to rendered content. Maybe we should leave this until then.
JA: VIP Infonet already does this.
IJ: Style sheets and rendered content are distinct.
JG: I think that the CSS DOM module should be added as a P3 requirement to allow ATs to know what was rendered. (For those UAs that implement CSS). This will allow synchro between what was rendered visually and another rendering (e.g., speech).
IJ: I have doubts.
Resolved: Add the following checkpoint to guideline 5
Provide programmatic access to style sheet content by conforming to the W3C Document Object Model (DOM) level 2 StyleSheet and CSS module and exporting interfaces defined by that module.