Raw minutes of 25 Jan 2001 UA teleconference from Ian Jacobs on 2001-01-25 (w3c-wai-ua@w3.org from January to March 2001) (original) (raw)

25 January 2001 UA Guidelines Teleconference

Agenda: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0114.html

Minutes of previous meeting 22 January:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0105.html

Next meeting: 1 February Possible regrets: Mickey Quenzer

Present: Jon Gunderson, Ian Jacobs (scribe), Harvey Bingham, David Poehlman, Al Gilman, Charles McCathieNevile, Eric Hansen, Tim Lacy, Greg Lowney, Rich Schwerdtfeger

Regrets: Kitch Barnicle, Denis Anson, Jim Allan, Gregory Rosmaita

Absent: Mickey Quenzer

Announcements

• Today is HB's birthday!
• Will be attending ftf (from this call): HB, JG, IJ, AG (part-time) Also: RS, KB(?), EH(?) No: JA, DP Don't know: DA

ISSUES

2.Issue 452: Checkpoint 2.2: Review minimal requirement (three options?) Source: http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#452

Resolved:

• Adopt Ian's proposal with clarifications that user input is "completed" when the user says so. http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0111.html

• Add techniques based on the WCAG comments. The UA may offer other techniques to double or triple time intervals, which may also be useful.

AG reading comments from Gregg Vanderheiden:
"you need to provide more options for companies: three option
approach").

IJ: We chose "infinite" as the minimal requirement to be
sure that the user has enough time. The other options may be
nice but exceed the minimal requirement.

AG: I think that GV is responding from the perspective of
preventing a denial of service attack. But that's not the
stateless HTTP case. So his considerations may not be
driven by the Web's architecture.

JG: Even with statelessness, your cookie could expire (e.g.,
due to security reasons).

IJ: We talk about client-controlled timing only.

AG: A likely case where you might have timeouts is the
case of voice browsing.

DP: All of my time-out experience has been server-side.

IJ: Should we try to address server-side control? We already
cover client-side control.

AG: That falls into server administration, and the proper solution
is probably to build in more time in the server. You can call this
a content problem (for WCAG) or an HTTP problem (for PF). The
protocol by which you ask for more time should be in HTTP or
CC/PP. You don't want this on a page-by-page basis. You want a 
generic macro.

AG: Another client-side control scenario is periodic refresh.

JG: So say to reviewer that some of his concerns about time
    extensions are server-side issues. 

For definition of "presentation": http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0119.html

Resolved from Ian's proposal.

• Delete the term "presentation" from the glossary
• Leave 3.2 as is, change content label to Image.
• Delete checkpoint 3.4 since we aren't aware of blinking images on the Web.

/* GL and TL join */

1.Issue 389: Conformance: Hard to test conformance in an objective fashion. Source: http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#389

Status: I wrote the reviewer with clarifications and asked for comment. No response yet. http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0038.html

Proposed resolution by IJ: We have reduced some of the conformance requirements as a result of the reviewer's comments. We have worked very hard on this conformance scheme and rejected a number of others. If the reviewer has specific suggestions, we will consider them.

GL: My concerns about conformance to the document:

• The checkpoint wording is so broad that it's very difficult to understand what it means unless you refer to notes, techniques.

• If the document had been less ambiguous, I would not have had as many questions.

• I don't believe it's possible to define something that's objectively measurable in terms of conformance without getting technology-specific. What you have is probably as good as you can get and still be platform-independent.

• You need techniques documents for specific technologies (e.g., HTML, or some other implementation strategy).

• That's how the Microsoft guidelines will evolve: general guidelines, accompanied by technology specific complementary documents.

• Having the UAAG 1.0 be the only thing you can conform to is problematic.

JG: Will people want to say they conform to UAAG 1.0?

GL: I don't see that at the current time it is interesting. I think the impetus to conformance could be applied by outside organizations. But I don't think the impetus is there today from vendors.

GL: I can imagine user organizations (e.g., NFB) as well lobbying a manufacturer for implementation of the Guidelines. Guidelines are effective for this. Clear conformance levels would allow manufacturers who do wish to try to conform to make appropriate decisions about how to do this.

GL: Vendors may have incentive to interpret checkpoints minimally. That would mean that vendors might not satisfy the spirit of the guidelines.

AG: Your prognosis is that the technology-independent statement of the checkpoints will make conformance difficult.

GL: I think that conformance needs to be measurable and thus you have to be very specific. Especially for an implementor who is not an expert in the field. I think you need technology-specific bindings to be more effective.

IJ: My prognostic is negative that we will have the time to do the technology-specific bindings at this point. The WCAG WG is working on this problem specifically.

GL: My comments are suggestions, and I realize that some of them may not be realistic. If your goal is measurable conformance, though, I don't think you can achieve it with a document that is technology independent. Maybe it suffices to warn the reader of the document of this.

JG: Note that we have used the document to try to determine conformance of some user agents. The most difficult requirements to verify are those related to communication with other software. Did you have this feeling as well?

GL: I think that you are the wrong people to test the document since you understand it. I compared the document's definition of keyboard access v. yours. It was hard for me to determine whether your definition said the same thing as mine. In some cases, it was not clear to me which checkpoints applied to some cases I had in my head.

GL: It would be nice to mention in checkpoints what you expect the checkpoints to cover.

GL: Certainly, the API requirements would require platform-specific testing tools. I don't think that your WG would be producing those tools. It's a problem we're struggling with as well. We are trying to develop more general testing tools. There's a technical problem in evaluating conformance to the API requirements. There's a definitional problem of how an uninformed person would evaluate the checkpoints.

DP: The issues are so numerous and the applications are so broad. There is lots of discussion on the interest group list about how the document is not designed for those without technical expertise.

GL: I think that in the long term, the field needs to come up with tools that offload the verification tasks from the user, especially the non-expert user. Tools need to make accessible tools automatic, but we also need validation tools that don't require expertise in order to be useful. They need to allow a novice software tester to generate a list of issues that can be turned into action items.

/* Rich joins */

GL: It would be interesting to have three people evaluate a user agent (including one who is not in the WG) and see what they come up with.

Action GL: Ask someone from Microsoft whether they will evaluate the guidelines with a product. Deadline one week.

/* Another issue */

GL: I thought that forward navigation alone was insufficient for minimal navigation through active elements.

JG: We hope UAs will do more, but the minimum was forward sequential navigation.

IJ: We have two checkpoints: sequential navigation and structured navigation (which subsumes direct navigation). Our structured navigation relies to a large extent on the format.

GL: Because "important elements" is not defined, is it possible for a UA to claim conformance that doesn't meet the spirit of it?

IJ: What would you say if I asked you (GL) if you objected to moving forward with the current conformance stuff?

GL: I think that you should clarify that the document is subject to interpretation.

AG: I have the same feeling as GL: this document is worth publishing for guidelines. We will confuse people if we say "test to this docuement" instead of "design to this document"

GL: It would be good to have testing experience to see how to move forward with testability in future versions.

GL: My experience is having designed guidelines in the past and having designed standards in the past. When random companies try to conform to a published standard, they will ask for clarification over and over again. The only way to deal with that in practice is to be more and more specific in complementary materials (FAQs, etc.) and to make explicit points that were initially implicit.

JG: I think WAI EO will be crucial to this effort.

GL: I think that the techniques document will be most useful for developers trying to do work.

Resolved:

• We expect to test the usability of the document per this discussion.
• We may add some verbiage to the document about "design to" v. "test to", but that will depend on the results of our testing.

Action IJ: Coordinate usability testing of the guidelines.

/* TL leaves */

3.Issue 454: Checkpoints 3.6/3.7: Should these be Priority 1? Source: http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#454

Refer to proposal from JG: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0117.html

JG: I would be more comfortable raising refresh to P1 if we had implementation experience.

DP: Lynx lets you do manual refresh.

GL: Don't know whether IE allows user to stop auto-refresh.

DP: Yes you can lose data if the refresh rate is too short. I've had this experience where I've been reading along and a page was yanked out from under my feet. However, if you don't update the page, you lose data in-between when you start updating the page and when you actually do.

GL: Note that client-side redirect (3.6) often breaks the back functionality. If you are on page A and you go to page B which takes you to C, then going back to "B" may be fatal since you are taken to C immediately.

DP: You can use the history to go back to in this case.

IJ: This problem affects everyone, doesn't seem to be just about accessibility.

IJ: I think that redirect should be done on the server side. Therefore, 3.6 is something of a repair checkpoint.

Resolved:

• (3.6) Redirect is P2 (author didn't intend user to see this page)
• (3.7) Refresh is P1 (author meant user to have content).
• Clarify that 3.7 (like 3.6) is about client-side driven refreshes. Delete "author-specified" in 3.6/3.7 and highlight "recognize" instead.
• Clarify that 3.6 and 3.7 are about pull rather than push.
• Add to techniques to not break "back" when implementing client-side redirect.

4.Issue 455: Guideline 4: Change to "Ensure user control of presentation"? Source: http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#455

5.Issue 456: Editorial: Need to clarify in section 3.2 that we do not mean system APIs Source: http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#456

6.Issue 457: Checkpoint 5.4: Ambiguity about what exactly required: standard APIs only? Source: http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#457

7.Issue 458: Do link highlighting requirements apply to all zones of an image map? What is required granularity? Source: http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#458

8.Issue 443: Checkpoint 1.4: Device independent access to pointer (mouse) specific events. Source: http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#443

Status: The document currently requires emulation of mouse-specific controls by virtue of our requirement that the user must be able to do everything through the mouse.

Discussion:

a) Do we want to require the UA to repair device-specific bindings specified by the author?

b) Do we have evidence that the ability to simulate mouse events through the keyboard benefits the user?

Completed Actions

Resolved actions from Ian: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0120.html

15.DP: Send information on programmable objects based on security options in IE

Source: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0105.html

Done: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0134.html

14.AG: Consult Trace Institute and reply to UAWG about what the requirement should be for checkpoint 2.6. Source: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0105.html

Done: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0135.html

Open Actions

4.IJ, EH, AG: Propose new definitions forterms in question (equivalence, text element, etc.)

8.JG: Talk to Al Gilman at the next WAI CG meeting about a joint meeting with UA, PF, and Voice WG (or participants) to discuss accessibility issues. Source: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0083.html

9.JG: Send screen shots of directional techniqes Source: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0083.html

10.JG: Implementation information for guideline 2

11.JG: Propose text for the techniques document about synthesized speech implementation issues. Notably UA and AT wanting to use the same synthesizer engine.

12.JG: Create issue list for things that need to be addressed in the next version of the document

13.JG: Request input on the resolution of issue 454 Source: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0105.html

16.GR: Review checkpoints in Guideline 10 for implementation information

17.JA: Review checkpoints in Guideline 4 for implementation information

18.MQ: Send more details about control of speech parameters for the techniques document based on OpenBook. (deadline open)

19.KB: Submit technique on providing information on current item and number of items in search

-- Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs Tel: +1 831 457-2842 Cell: +1 917 450-8783

Received on Thursday, 25 January 2001 16:03:39 UTC