WAI UA Telecon for January 12th, 2000

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

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.