- From: Ian Jacobs <ij@w3.org>
- Date: Thu, 15 Mar 2001 16:03:39 -0500
- To: w3c-wai-ua@w3.org
15 March 2001 UA Guidelines Teleconference
Agenda announcement:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0409
Reference document 9 March 2001 Guidelines:
http://www.w3.org/WAI/UA/WD-UAAG10-20010309
Minutes of previous meeting 8 March:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0357
Next meeting: 22 March teleconference:
Present:
Ian Jacobs (chair, scribe), Gregory Rosmaita, Eric Hansen,
Charles McCathieNevile, Tim Lacy, David Poehlman, Aaron Leventhal,
Harvey Bingham, Denis Anson
Absent: Rich Schwerdtfeger
Regrets: Mickey Quenzer, Jon Gunderson, Jim Allan
----------
Discussion
----------
0. Who has read the 9 March draft?
Yes: None
Partially: IJ, CMN, EH, GR, DP
No: TL
IJ: Has anyone found any show-stoppers?
/* No one has come across any show-stoppers in their partial
review */
**********
IMPORTANT:
**********
All editorial issues with the current document should be sent to the
list before 21 March. At the 22 March teleconference we expect to
vote to return to last call.
1.Issue 466: What are the priority of the accessibility issues and
user agent minimum requirements for checkpoint 9.3
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#466
Question: Is there a real-world example of why it's necessary to turn
off automatic onFocus and onBlur triggering?
AL: I talked to one of the guys at work yesterday. He said the most
common uses: onFocus for selecting, onBlur for validation.
TL: I wrote some DHTML that implements a toolbar. It relies on onBlur
and onFocus to do rollovers (i.e., replace one GIF with another).
AL: Web designers usually do this for the pointing device.
IJ: I've heard rationale for doing things manually, but less for not
doing things automatically.
GR: Recall that navigation sequence changes when you turn off all
script supports.
IJ: If onFocus causes a change to the document such that you can't
activate the other handlers, then this would be a destructive case.
/* GR raises this email message from Al:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0407.html
*/
CMN: The form case (don't trigger on enter key) is a separate case, I
think.
IJ: If you do a destructive onFocus manually, you still have to
undo the action. Is there a difference between undo after automatic
behavior and undo after manual behavior?
CMN: There is a difference: Auto behavior can make it hard to
undo (e.g., chaining, refreshing pages).
CMN: There aren't enough people writing accessible pages to give
real-world examples of using focus/blur. If we are successful, then
perhaps we will need this requirement more than today. Perhaps it's
easier to have a general event trap and not exclude specify types of
events.
AL: But I think that today the big issues are mouse overs and form
submissions.
IJ: In the past, we've said that automatic behavior may be
disorienting, thus we've required configuration to suppress automatic
behavior.
Rationale:
* Automatic behavior can be disorienting.
AL: But we can't think of an example where this would happen.
CMN: When people include focus handlers, they have usually done a job
to make those handlers useful. One problem is that part of a page
changes, but the user is not aware of it.
AL: Screen reader gives you a review cursor.
CMN: I use a variety of browsers because a single one does not meet
all of my needs.
IJ: I don't think that there is a guarantee that if you can't prevent
auto-triggering, that access will be impossible. This is unlike form
submission, where you can't finish filling out the form.
CMN: But there are examples where onFocus causes, e.g., a list of
choices to be updated automatically. Every one of the different
players (author, user agent, authoring tool) can help solve the
problem.
GR: Another example: when I was trying to configure a computer online,
a lot of forms used magic links that appear when you do an
onFocus. There is assumption in authoring that you are using a
pointing device: if you navigate to a link that has appeared
dynamically, the rest of the page fails. In other words, the focus
and the pointing device establish context; not the focus alone.
CMN: Part of this is an authoring requirement.
IJ: It seems like:
1. This is not a widespread problem in practice.
2. Not clear to me that automatic triggering is an accesibility
problem that is a P1 problem.
CMN: Think of the structured navigation requirement in conjunction
with 9.3: You navigate around a "static" tree and fire at well. The
P1 problem is that self-customizing content becomes inaccessible.
/* Denis joins the call */
AL: I'd like to satisfy this requirement so that a screen reader could
do this, by letting the user zap mouse to focus (technique).
CMN: Blind users don't know what they've missed as they're navigating.
Rationale for P1:
* Handlers may cause inaccessible changes to content.
Rationale for P2:
* Not widespread in practice
* People who write onFocus handlers may be aware of accessibility
problems.
* This is a repair functionality if changes cause inaccessible content
IJ: It's hard for me to include a P1 requirement for extreme cases.
DP: How does this affect access to all content? Would you not fail 2.1?
IJ: Who can't live with it as a P2?
Resolved:
* Make checkpoint 9.3 a P2 checkpoint.
IJ: Note that an objection will be strengthened by evidence that this
is widespread in practice.
2. Comments from Denis Anson:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0425
IJ: Any statements the WG needs to review here?
DA:
* In section 1.1: change "support authoring practices" to
"addresses authoring practices."
* Checkpoints 1.1 and 1.3: The way I read these, it's not
clear you always have to do the keyboard.
CMN: I want to see 1.1 say: you have to do the keyboard.
I want to see a new 1.2/1.3 with input modality labels.
IJ: I don't think you need a label if it only appears once.
This is why it's different than content type labels.
EH: Even a set of one, for the sake of consistency, to use a label.
DA: I agree that it sounds contradictory to say "you have do to
this but you don't have to."
CMN: I have two parts to what I'd like to see:
* Split 1.1 into two different checkpoints (you get
a sense of two classes of requirements.)
IJ: The input labels are conformance labels. The content type
labels are next to the checkpoint labels for convenience
only.
IJ: All the checkpoints are accessibility requirements, not
conformance requirements.
Resolved: (this is issue 465)
* Split 1.1 into two checkpoints.
* Add to introduction of Section 2 that content type
labels after checkpoints are for convenience only.
* Include an example of evaluting a browser for
conformance.
CMN: If I'm not satisfied with the wording, I'll send
a new proposal.
Revolved:
* For checkpoint 2.2, move text format requirement from
the note to the checkpoint.
* Make clearer the "additional bonus should" of the Note.
DA: In checkpoint 2.3, why not have notification to AT that something
is there and unrendered?
IJ: The checkpoint says "alerts the user" as well.
/* No change */
DA: 2.4: Does this include the condition where there are embedded
links inside a QuickTime movie, for example, that allow a user to
further explore building shown in the movie?
/* The WG thinks that Denis' example is covered by 2.4 */
DA: I'm not sure what this checkpoint means.
Action IJ:
* Work on editorial changes to 2.9
* Include an example (e.g., "alt" for IMG in HTML).
DA: Checkpoint 3.1: What about condition where you have a table with a
background image?
IJ: That's a chosen limitation of this document.
Action IJ:
* Add to the beginning of the document (limitations)
that 3.1 doesn't cover layers.
DA: What if text is bigger than the space alloted for the
scrolling area?
CMN: You have to come up with some solution. It might be that you
re-render the content. It's the same as when you fire up a page
without images that chop off alt content.
IJ: The unblinking text doesn't have to be in context.
Action IJ:
* Add to the techniques document that it's ok to render
the unblinking text not in context.
DA: Checkpoint 3.5: How do I get content after I said no?
DP: Manual refresh is ok.
IJ: By saying no, you may miss some content. But I don't
think we are asking the UA to save 600 versions of a page.
CMN: There is an essential limitation that we can't stop the external
world.
DA: This is like frame-dropping.
/* No change */
DA: Checkpoint 3.7: [SUBSTANTIVE]. When you do this, there should be
an option that when I render "this image" it dismissive the previous
image. Too many images are two many images, whether they all appear at
once or serially one after the other.
IJ: One way to achieve this is to reload the page with images turned
off. We already discussed this and decided that toggling back off was
not considered a requirement.
/* EH leaves */
DA: I think it is, though. I worked with a guy who could hold 5 cards
in his hand, but couldn't hold 6 (he started playing as though he had
9 cards). You need a way to resimplify the page.
IJ: Why so burdensome to turn all images off?
DA: This is burdensome for someone with a cognitive disability.
IJ: This would apply to 3.2 as well (same reasoning: turning on video
and animated images).
AL: Implementation note: Netscape 6 or any Mozilla lets users turn
toggle images on/off on a per-image basis.
DP: I often browse without images turned on. When I'm working with a
sighted user, they often want to view images individually without
having to turn them on globally.
CMN: I do this in Lynx - run Lynx and view images one at a time.
DA: It would also satisfy the user requirement to show an image
temporarily and when you're done, make it disappear.
Action IJ:
* Add to techniques to show images "temporarily" and when you
leave the image, it goes away.
DA Proposal: Add toggle-off requirement to 3.2/3.7.
Action IJ: Write a proposal for what the new wording might be
for these checkpoints.
No resolution for now.
------------------
Proposals from Ian:
------------------
Proposal from IJ to delete 1.2:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0415.html
Resolved:
* Delete 1.2 and
* Make it clear that 1.1 (or sons of 1.1) cover
both content and UI.
-------------------
Action Item Summary
-------------------
-----------------
Completed Action Items
-----------------
3.IJ: Propose text for how other documents should reference UAAG 1.0
Source: http://www.w3.org/WAI/UA/2001/03/ua-minutes
Done in 9 March draft.
4.IJ: Distinguish techniques for fast forward versus faster palying
(digital talking books), and point to digital talking books
Source: http://www.w3.org/WAI/UA/2001/03/ua-minutes
9.JG: Write a proposal related to the expected actions as the result of
triggering events associated with the focused element.
Source: http://www.w3.org/WAI/UA/2001/03/ua-minutes
Done: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0408
-----------------
Open Action Items
-----------------
1.IJ: Coordinate usability testing of the guidelines (JRG volunteers to
be one of the testers).
Source:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0137.html
2.IJ: Write an executive summary appendix.
Source:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0200.html
REFER TO PROPOSAL FROM EH:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0413.html
5.IJ: Add a Note to checkpoint 4.4.pointing to applicability provision
about streaming and whether slow/etc.control enabled by the format.
Source: http://www.w3.org/WAI/UA/2001/03/ua-minutes
6.IJ: Take to the cross-WG WAI list the issue of how to refer to UAAG
(or other WAI specs) in non-W3C documents
Source:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0357.html
7.JG: Propose text for the techniques document about synthesized speech
implementation issues. Notably UA and AT wanting to use the same
synthesizer engine.
8.JG: Create issue list for things that need to be addressed in the
next version of the document
10.JG: Take to WAI PF the requirement that formats need to provide a
more precise means for specifying events (than HTML allows for).
Source: http://www.w3.org/WAI/UA/2001/03/ua-minutes
11.JG: Create a wish list of other requirements not in UAAG 1.0,
including those that might fall under this Guideline.
Source: http://www.w3.org/WAI/UA/2001/03/ua-minutes
12.JG: Write up some techniques for checkpoints on scripts on/off about
subsetting the configuration.
Source: http://www.w3.org/WAI/UA/2001/03/ua-minutes
13.JG: Take to the WAI CG the question ofpursuing the DOM Views and
Formatting module.
Source: http://www.w3.org/WAI/UA/2001/03/ua-minutes
14.JG: Call Cindy King about formats that support separate windows for
captioning information
Source: http://www.w3.org/WAI/UA/2001/03/ua-minutes
15.GL and TL: Ask someone from Microsoft whether they will evaluate the
guidelines with a product.
Deadline: 2/1/2001
Source:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0137.html
16.CMN: Find out from SYMM WG whether repositioning of objects will
appear in the spec (or should be in UAAG).
Source:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0357.html
17.TL: Report to WG on discussions at Microsoft about keyboard
emulation.
Source:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0227.html
18.RS: Send pointer to information about universal access gateway to the
WG.
Source:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0258.html
--
Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 831 457-2842
Cell: +1 917 450-8783
Received on Thursday, 15 March 2001 16:03:43 UTC