Chair: Jon Gunderson
Date: Wednesday, January 5th
Time: 12:00 noon to 1:30 pm Eastern Standard Time, USA
Call-in: Longfellow Bridge (+1) (617) 252-1038
Chair: Jon Gunderson
Scribe: Ian Jacobs
Present: Jim Allan
At the face to face, we decided to make incremental a technique (issue
In the 20 December 1999 UAGL, checkpoint 4.6 includes generic forward and
reverse. Techniques included in 20 December Techniques document.
1.JG: Review techniques for Guideline 8.3 to 8.9
Status 8.3/8.4: Cancelled, though JG may check into Opera capabilities.
GR: Refer to my evaluation of Opera
Status 8.5: Done
2.JG: Draft a preliminary implementation report for CR consideration
Status: Not done.
3.DB: Ask IE Team about publication of review of IE 5 and Pri 1
4.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
Status: Pending. I've asked an MSAA developer for this information. See thread from Jim Allan and Ian Jacobs.
DA: There's information at the IE site on this: http://www.microsoft.com/enable/dev/guidelines/software.htm (Follow Section 1)
5.DP: Propose new Checkpoint 1.5 for access to system messages
Status: No info.
6.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.
Status: Not done. Will ask RS a question offline.
7.GR: Write a technique on how to create accessible installation
Status: May already be integrated.
8.GR: Run LPPlayer through the guidelines. Verify with Productivity Works.
Status: Pending. Talked with both Ray and Mark. He'd prefer that the analysis be done internally by Productivity Works. They would contribute an evaluation. GR will keep us in the loop on this.
9.MR: Review techniques for topic 3.1 (Multi-media)
Status: No info.
10.MR: Review techniques for Guideline 4 (Multi-media)
Status: No info.
11.MR: Run a multimedia player through the guidelines for January.
Status: No info.
12.MQ: Ask Mark about meaning of comment raised in Issue #167
Status: Mark is still travelling.
13.WC: Take form submission to GL WG to discuss issues related to
Status: Not done. Ian reminded her today.
14.IJ: Refer to
a) Propose a technique for using XSL to transform content
b) 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)
1.New UA weekly scheduled telecon (tommorrow) 6 January 2000 at 2:00 pm to
3:30 pm Eastern Standard Time, USA
2.Protocols and Formatting are holding a FTF meeting on 26-27 January 2000
at Sun's Microsystem in Cupertino - Silicon Valley
JG: Henter-Joyce is implementing their own DOM-like API.
RS: IBM is looking at DOM for HPR.
JG: Work at CAST in their e-text reader also involves DOM.
MQ: I'll ask Mark if PWWebSpeak is using the DOM. JG will email as well.
IJ: To get to CR:
a) Resolve outstanding issues.
b) Prepare an implementation report
c) Schedule a meeting with the director.
d) Target start date: 14 January.
e) Target duration: will be determined based on implementation report, but if DOM implementations are working, then starting point would be one month.
a) Is this useful?
b) What's missing?
c) How to resolve remaining ones?
DA: I think "AT" definition is too fuzzy. I think that AT's provides functionality for which an able-bodied user doesn't require extra software. Not necessarily a plug-in, may be a wrap-around. Some things that are conveniences for an able-bodied person (e.g., TV Remote control) are not just conveniences for someone with a disability because they don't have another way to do it. This may comprise the group of requirements that should be built-in natively to the desktop user agent.
DB: This document is useful for developers as well as for "critics" of the guidelines.
Action IJ: Publish a new draft that incorporates JG's comments.
DA: Some of the "Apply to all user agents" are actually "Apply to all applications". I suggest creating a "Requirements for all software" category. And these shouldn't be native but in the OS.
Action DA: Identify the general ones from the list.
Action EVERYONE: Review the "Unknown" category and we'll discuss them at tomorrow's meeting.
Action RS: Send editorial comments.
JG: Håkon Wium Lee thinks DOM should be P2, since it turns a browser into an editor.
a) Change to P2 as HWL suggests.
b) Change to P2 for write access.
c) Change requirement to be more general (as we did for UI access).
d) Leave P1.
RS: You can't fill out a form with write only access.
JG: I'm not sure that physical memory concerns is an issue. In the past, we haven't made human resource limitations a high criterion.
DA: The DOM is a special case. We're not talking about functionality here, but implementation.
JG: We've talked about this and since the DOM is platform-independent and vendor neutral, we felt is was necessary for interoperability.
HB: We may not be able to paste into the DOM something that is an audio source. The error control process has to be invoked to ensure validity.
DA: I don't think this is a big issue. Speech input is a wrap-around technology converted to movement or keyboard input.
/* DB and JG leave */
GR: My concern is time lag to implementation by ATs. People are looking to these Guidelines for quick improvement to the Web experience (say, a year). I think that we should send the "UA Responsibilities" document to reviewers of the document so we can "show them the money". (Add this concern to the "UA Responsibilities doc?)
DA: I think the time lag issue is valid for *any* standard we would promote. Therefore, we can "arbitrarily" choose the DOM.
IJ: Sounds like a FAQ: "When will browsers be accessible?"
1) Leave P1 for reasons of interoperability and requirement for write access.
DA: I have a hard time arguing that it's P1. It is difficult, but not impossible.
IJ: What about some ornate font family?
DA: There are probably a few people for whom it's gibberish. But if you don't have the appropriate font on your computer, your browser will choose another anyway.
GR: Important for low vision and cognitive. But my gut feeling is P2.
JA: You can always find a font family that makes it impossible for someone to read the text. Take wingdings, for example. There may be font families that are easier or less easy to read.
DA: There are inefficient ways, but not impossible ways, to read the text (e.g., cut and paste)
1) Change to P2.
2) Action Ian: Send this resolution to the list for comment.
DA: I think start and stop (video, audio, animation) is P1. "Start" means "start from the beginning".
IJ: You can restart from the beginning by reloading the page. Why is it P1 to stop?
DA: It may be distracting you from other things on the page.
JA: I've visited sites where audio was rendered and you couldn't stop it; different audio clips overlapped.
DA: I don't think that slow compensates for pause. Pause should be P1 as well.
HB: If you're working an audio or braille stream that is pouring out and synchronized with other content, you need to change the rate of the audio controls and stay synchronized.
IJ: Pause isn't P1 - you still have access to the content; you can start from the beginning.
DA/GR: Lack of pause may make access to content impossible for some users with disabilities. If they don't have time to stop and are forced to start again, they will never get to the end of the content.
1) Move "start, stop, pause, rewind, advance" to P1.
IJ: This checkpoint means "Let me know which elements are active".
DA: Some users with cognitive disabilities need this.
JA: If the user can't find it, the function is not there.
Resolved: Raise to P2.