- From: Ian Jacobs <ij@w3.org>
- Date: Wed, 12 Jan 2000 13:39:44 -0500
- To: w3c-wai-ua@w3.org
WAI UAGL Teleconference
12 January 1999
Participants:
Jon Gunderson
Ian Jacobs
Kitch Barnicle
Denis Anson
Harvey Bingham
Dick Brown
Charles McCathieNevile
Gregory Rosmaita
Jim Allan
Regrets:
Rich Schwertdfeger
David Poehlman
NEXT MEETING: 13 January 2000 @ 2pm ET for 90 minutes
Agenda [1]
[1]
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0050.html
1) Review of action items
Review Open Action Items
1.IJ: Draft a statement for time of publication, there is no
authoritative body that validates claims of conformance
Done:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0073.html
2.IJ: Repropose the delivery mechanism of conformance statement to
allow
documentation as an option
Done:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0073.html
3.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)
Note done.
4.IJ: Publish a new draft of requirements document that incorporates
JG'sand other comments.
Done.
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0048.html
5.IJ: Make clearer in Checkpoint 8.1 that it is "information provided
to
the user."
Done.
6.IJ: 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.
Done.
7.IJ: Indicate that this is a special case of 10.3
Done.
8.JG: Review techniques for Guideline 8.9
Done.
9.JG: Draft a preliminary implementation report for CR
consideration
Status: For this afternoon.
10.DB: Ask IE Team about publication of review of IE 5 and Pri 1
checkpoints.
Status: 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, ...)
Status: Pending.
12.DP: Propose new Checkpoint 1.5 for access to system messages
Status: Not done.
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.
Status: Pending.
14.GR: Write a technique on how to create accessible installation
Status: Pending. Refer to GR's email on installation.
15.MK: Find out techniques for sending text search requests to servers
of
streamed text.
Status: Not done.
16.MR: Review techniques for topic 3.1 (Multi-media)
Status: Not done.
17.MR: Review techniques for Guideline 4 (Multi-media)
Status: Not done.
18.MR: Run a multimedia player through the guidelines for January.
Status: Not done.
19.MQ: Ask Mark about meaning of comment raised in Issue #167
Status: Not done.
GR: MN not back from Japan yet.
20.WC: Take form submission to GL WG to discuss issues related to
inadvertent submission.
Status: Not done.
2) Announcements
1.Regular UA telecon scheduled 13 January 2000 at 2:00 pm to 3:30 pm
Eastern Standard Time, USA
http://www.w3.org/WAI/UA/2000/01/wai-ua-telecon-20000113.html
3) F2F Meeting to process Proposed Recommendation Issues
CMN: Based on ATAG, I think it would be worthwhile. I'd also
suggest allowing a long time. Book extra time (3-4 weeks)
Note: CMN will be in the UA in April.
GR: Other WAI meetings around CSUN.
JG: WCAG may not meet then due to unavailability of chairs.
Possibly 27 March.
JG: Who's willing to go to a meeting late March, early April:
KB, CMN, DB, DA, GR, IJ, HB, JG.
4) Candidate Recommendation Preparation
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0049.html
HB: Do we get an early read from developers?
IJ: I think coordination is the piece that's missing in our
preparation for CR.
KB: The plan is reasonable.
DB: I will coordinate with IE Team.
GR: JG should contact MH at ProdWorks.
GR: I can work with Dolphin.
GR: I can talk to Håkon (since I'm a beta tester). How would
we handle a review of a beta-version?
IJ: I will talk to Håkon.
CMN: I'll be talking to RealNetworks people in Seattle.
JG: Other Netscape contacts?
GR: Mozilla?
JR: We can talk to IBM contacts about Mozilla.
Schedule for CR:
IJ: Probably not ready for CR 14 January. Will try for following
week.
5) User Agent Responsibilities Document
http://www.w3.org/WAI/UA/2000/01/ua-resp-20000109
GR: I like the direction it's taking.
JG: Send comments to the list.
6) Issue LC#162: Raise priority of 8.9 (consistency in configs) to P2.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#162
KB: How will developers say that they meet this checkpoint?
JG: How much consistency is required?
IJ: Seems like usability, not accessibility to me.
GR: If the configuration changes significantly, it should be noted
in documentation and README.
IJ: Seems like definition of P3 applies.
DA: Can be a bigger problem for users with cognitive difficulties.
Rearranging controls makes it very difficult.
KB: Is documentation of changes more important?
IJ: Another factor - difficulty of establishing minimal
requirement.
JG: If the change makes using the tool easier, but there is
inconsistency, what do you do?
DA/GR: I think it's arguably a P2, but we do have a problem with
identifying how you meet it.
CMN: My gut feeling is P2, but not sure.
JA: Same here. It's hard to nail down which direction to go on this.
GR: We need to point developers to the other aspects of the
question, notably documentation of changes.
HB: I think P3 is ok.
DB: I think P3 is ok.
KB: This falls to me in the category of general UI design.
Proposed:
- Delete checkpoint 8.9. Move discussion to guideline
rationale
or principles of accessible design.
- Talk about documentation of changes in G11.
DA: We're trying to say: don't make arbitrary changes. Will that
being
in prose alone make it clear that this is an accessibility
issue?
GR: I'm ok with deleting the checkpoint as long as clearly
indicate that documentation important.
DA: I still think it's a significant issue, even if it's in the
documentation. It's a burden beyond the documentation.
KB: I agree that it's an important issue.
IJ: Proposed:
- Delete 8.9
- Add a checkpoint in documentation (P3)?
GR: Dolphin offers compatibility modes. This has boosted their
sales. Propose adding a technique to configuration checkpoint
about compatibility with previous UIs.
Resolved:
- In principles of design, add consistency to list of
good design ideas.
- Delete 8.9
- Add a P2 checkpoint in G11 about documenting changes
- Add a technique to config checkpoint about compatibility
modes.
Action IJ: Update document with these changes.
7) Issue LC#166: Review priority of 10.5 (default configs that interfere
with
OS conventions)
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#166
IJ: 10.5 in 20 Dec 1999 draft.
DA: If the OS intercepts keystrokes, the UA won't see those
inputs.
JG: But that's the same for everyone.
DA: But may be an accessibility if you can do it through mouse but
not keyboard.
KB: That's covered by 1.1
GR: Do we have "mobility access keyboard modifiers reserved for
the operating system" in the techniques document?
JB: I think in the appendix.
GR: Based on the second sentence it's a P1 item. (e.g., breaking
accessibility input methods).
Resolved:
- Change 10.5 to P1 "Avoid default input configurations that
interfere with operating system accessibility
conventions."
- Move first sentence of note afterwards to techniques for 5.6
Action IJ: Update document with these changes.
8) Issue LC#175: Proposed raise (to P1) of checkpoint 4.18
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#175
IJ: 4.15 in 20 Dec draft.
GR: In the absence of notification, serious accessibility problems.
People think that their history mechanism is broken. People
often work around by shutting down the browser window.
DB: I think it's inconvenient, but not impossible. P2.
GR: The key point is knowing; not the event itself.
Resolved:
- Leave P2
- Move "SMIL" example in Note to techniques. (Ian to simplify)
- Add cross-ref from 4.15 to 9.1
Action IJ: Update document with these changes
9) Issue LC#176: Proposed change in priority (P3 to P2) for checkpoint
8.7
(link information)
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#176
IJ: 8.3 in 20 December draft.
KB: If a UA implements CSS, do they meet this checkpoint?
IJ: If pseudo-elements supported.
DA: If you have a page with lots of links, if you don't have
a way to know which you've visited, you have to memorize that
and it's difficult to access the data.
GR: There are a lot of superfluous links on pages, notably portal
pages.
DA: I think it's a P2.
GR: I think P1, but can live with P2.
JA: I think it's a P2.
HB: I think it's a P2.
DB: I think it's a P2.
Proposed:
- Make 8.3 and 8.7 P2.
DB: I have a reservation about making 8.7 P2. I think developers
might not add features because of this.
DA: You can't find a way to present link information that is
accessible to everyone.
GR: Refer to section 3.3 of techniques document (link techniques)
KB: Do we have a checkpoint for link presentation?
IJ: Yes: 8.6
KB: If the UA supports CSS, does that suffice? Or does the UA
also have to provide a piece of UI for presenting information?
Or must the default style sheet display all information?
Consensus:
- The concept is P2.
- Problems with ambiguity of the checkpoint.
There may be some implementation problems.
- Configuration less important if UA makes right choice
about what information to present.
Action GR: Send screen shot of JFW link view.
Resolved:
- Add (back the old)
checkpoint for visited/unvisited links P2. If you don't have
access to that information is to follow a link and then return.
For complex pages, this becomes an unreasonable burden for
people with non-graphical browsers or cognitive disabilities.
- Leave 8.3 and 8.7 as is (removing visited).
Action IJ: Update document with these changes.
Received on Wednesday, 12 January 2000 13:40:00 UTC