Chair: Jon Gunderson
Date: Wednesday, March 1st
Time: 2:00 pm to 3:30 pm Eastern Standard Time, USA
Call-in: Longfellow Bridge (+1) (617) 252-1038
URI: http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#190
Proposed Resolution:
Full read access DOM and write to UI controls:
Checkpoint 1. Provide programatic read access to content by conforming to DOM level 2 core and HTML modules and exporting... [Priority 1]
Checkpoint 2. Provide programatic read and write to author supplied user interface controls by conforming to DOM level 2 core and HTML modules and exporting... [Priority 1]
Other checkpoints affected: Requires modifying new checkpoint for general access to read only , instead of read write
URI: http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#190
Proposed Resolution for MM:
1. Only for synchronized MM
2.
Includes both space and time
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#195
What does this checkpoint mean:
Does this require text equivalents or not?
Are text equivalents the best we can do right now?
Does this mean that if you make a sound you do something else too and if you do something visually you also make a sound?
Currently Proposed Resolution Options:
Option A: Checkpoint 1.5 Ensure that user agent-initiated messages to the user (e.g., informational messages, warnings, error messages, etc.) are available through all output channels supported by the user interface.
Option B: Checkpoint 1.5 Provide a text equivalent for every non-text user interface component available to the user through the user interface.
Note: This does not require descriptions of images or sounds, but a redundent text message of the information the graphic or sound was trying to convey to the user.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#196
Proposed Resolution:
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#197
Proposed Resolution:
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#198
Proposed Resolution:
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#199
Proposed Resolution:
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#200
Resolution Options:
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#201
Resolution Options:
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#202
Proposed Resolution:
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#204
Proposed Resolution:
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#205
Resolution Options:
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#206
Resolution Options:
Chair: Jon Gunderson
Scribe: Ian Jacobs
Present:
David Poehlman
Mickey Quenzer
Gregory J. Rosmaita
Dick Brown
Denis Anson
Harvey Bingham
Mark
Novak
Rich Schwerdtfeger
Hans Riesebos
Regrets:
Kitch Barnicle
Madeleine Rothberg
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0400.html
1.IJ: Find out whether rendered content from style sheets appears in
the document source.
Status: Done. The answer is no (from Philippe Le
Hegaret).
2.IJ: Propose checkpoint to address event notification timing issue
Status: Not done.
3.JG: for 5.3: Find out windows/mac accessibility guidelines.
Status: Done.
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0409.html
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0405.html
4.JG: Check with Ian about adding reference in 4.5 to 4.6 in regard to
stepping through animation/video/audio.
Status: Done.
5.DB: Ask IE Team about publication of review of IE 5 and Pri 1
checkpoints.
Status: Pending.
6.JA: Rewrite techniques for 3.3 (see minutes)
Status: Done.
(refer to minutes of last meeting).
7.MK: For 4.8 check if any media players do this?
Status: No info
8.MK: Find out techniques for sending text search requests to servers
of streamed text.
Status: No info
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: Done.
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0253.html
12.RS: Take timely and synchronization issues to WAI PF. Get input from MSAA developers as well. Craft email to PF WG with Ian
RS: I've been working this from another angle.
ACTION DB: See if "MS Developer Accessibility Guidelines" can be made available as HTML.
IJ: We can meet at RF and D in New Jersey. If we get the issues resolved and the document ready, we'll have the meeting on 10-11 April.
JB: Possibility of additional teleconf on Friday? (Some people can't attend)
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#190
Proposed: Split 5.1 into:
a) Read-only for XML/HTML DOM 2 core
b) Write for ui controls available through content.
IJ: I think that "b" is fairer than full write since that means that you can do through API what you can do through the UI.
RS: Javascript can change menus on the screen. Is there an accessibility issue that ATs be allowed to do the same thing?
MN: Why is this not covered by 2.1?
JG: I think 2.1 is primarily UI.
GR: In my post on NOFRAMES, I quoted the HTML 4.0 spec: (talks about configured not to display frames).
DP: What do we lose if we don't allow write access to the full core spec?
JG: Not clear.
DP: What about "Begin Table/End Table"? Are those written in the document tree by the AT, or added by the AT?
IJ: If they are walking the DOM (and not getting info from graphical rendering), then don't need to write. AT can prepend itself.
Resolved: Split 5.1 into:
a) Read-only for
XML/HTML DOM 2 core
b) Write for ui controls provided through content.
Action Ian:
- Make this change.
- Add a
cross-reference from 2.1 to 5.1 and say in 5.1 that this is a special case of
2.1
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#194
Proposed:
1. Only for synchronized multimedia
2. Includes
both space and time
DP: Problem of streaming media. It's possible for downloadable media.
IJ: I think that the applicability clause and a comment in the techniques document could clear this up.
DP: If a multimedia presentation stops when you leave the page, then you should be able to return to it.
IJ: I don't know why disorientation doesn't apply to multimedia.
GR: I agree.
Resolved:
- Add an examples of multimedia/time to
"point of regard"
- Add a technique for multimedia tools about:
a) If
the presentation stops when you leave a presentation, bookmark and return.
Distinguish running in "background" from paused.
b) Comment about
inapplicability for streamed media.
Action Ian: Add these to techniques document.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#195
JG: Question of what exactly is meant by 1.5. Is this a UI checkpoint or an API checkpoint?
Proposed 1) Ensure that user agent-initiated messages to the user are available through all output channels supported through the UI.
Proposed 2) Provide a text-equivalent in the user interface for every non-text user interface component. (Based on WCAG 1.1).
DA: What about the case where the UA emits a beep?
JG: Message on the status bar.
IJ: Components work in tandem: the sum of the components around a given functionality must be accessible together (and have a text equivalent).
GR: Problems of access to colors.
IJ: Not a problem: Either text is there for everyone, or you can query. But you can't make the color alone accessible to all people.
Proposed 2) Ensure that every functionality available through the user interface is represented in the user interface as text.
DB: For IE colors, nicknames should be available for main colors.
MQ: Allow users to name colors that they create....
Proposed 2) Ensure that every functionality available through the user interface is represented in the user interface as text.
IJ: Note that I'm talking about functionalities. Also, note that that text needn't be available at all times; just available at some time.
RS: What about basic colors?
JG: What if we scale this back to messages.
IJ: Note that we push to P2 the general case of user interface in 5.6. Do Windows guidelines talk about text equivalents of non-text controls?
DB: Yes, talks about item names.
Questions:
- How much has to be available through the UI?
-
Just for messages? For all UI components?
- Does text meet the
expectations of the WG?
DP: The reason we talked about messages was that they are transient. Maybe not available through an API.
Resolved: Ensure all non-text messages (e.g., prompts, alerts, etc.) available through the user interface are also represented in the user interface as text.
Action Ian:
- Ensure that techniques for this
checkpoint talk about status bar.
- Incorporate proposal.
- Add
rationale: if you're deaf blind you might need this (Braille display).