- From: Ian Jacobs <ij@w3.org>
- Date: Wed, 08 Sep 1999 13:47:15 -0400
- To: w3c-wai-ua@w3.org
UAGL Teleconference
8 September 1999
Present:
Jon Gunderson
Ian Jacobs (scribe)
Kitch Barnicle
Mark Novak
Harvey Bingham
Rich Schwerdtfeger
Marja Koivunen
Charles McCathieNevile
Gregory Rosmaita
Jim Allan
David Poehlman
Next meeting: 15 September
Regrets RS, Cathy Laws should be there.
Agenda [1], [2]
[1]
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0345.html
[2]
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0351.html
Agenda 0) Review of action items:
1.IJ: Run NN (and Mozilla) through guidelines.
http://www.w3.org/WAI/UA/uagl-checklist-nn4.60
2.IJ: Create a list of metadata elements and techniques for HTML
Done. Refer to WCAG.
3.IJ: Send a detailed call for review to the IG.
Done.
4.IJ: In document, highlight existence of "native" and "applies
to".
For next draft.
5.HB, RS: Look at techniques document.
HB: Review of Techniques
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0353.html
RS: Will send in comments on Techniques.
6.HB: Run pwWebSpeak (with Mark H.) through the guidelines.
7.DP: Technique 3.6 - Propose techniques
No.
8.DP: Run Jaws for Windows through the guidelines.
No.
9.GG: Review proposal for techniques for accessing content.
No info.
10.CMN: Write a proposal for moving forward on conformance to the
list.
Not done.
11.CMN: Send proposal to the UA list about including an implementation
period as part of the recommendation process
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0326.html
12.CMN: Propose something about schemas
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0349.html
13.CMN: Talk to Dan Brickley about document structure and site
mapping.
Will send a list of tools that make use of meta information to the
list.
Done. Conclusion: Don't think we have a checkpoint-level
requirement at this stage.
14.JA: Compose list of metadata sources for CSS. (e.g., generated
text)
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0348.html
15.Marja: Compose list of metadata sources for SMIL.
Almost done.
16.JG: Include in RSVP a request for inidicating completion of action
items
Done.
Agenda 1) Review of AU last call.
http://lists.w3.org/Archives/Public/w3c-wai-au/1999JulSep/0207.html
HB: I sent comments about XML info.
http://lists.w3.org/Archives/Public/w3c-wai-au/1999JulSep/0212.html
IJ: I sent comments.
http://lists.w3.org/Archives/Public/w3c-wai-au/1999JulSep/0211.html
DP: Have the AUGL been evaluated with real authoring tools?
CMN: Yes. We have authoring tool developers in the WG. We've done
conformance tests thoroughly with a couple of tools. We would
like to see more testing. The conformance test with Amaya
is part of the Techniques document.
CMN: I'd like to exclude Gregory, Ian, Jim from review since they
are intimately involved with the process.
CMN: We want:
a) A statement that the AU satisfies all needs of the UA Guidelines.
b) Review from anyone.
Action Jim, Kitch: Send list of dependencies between AU and UA WGs to
the AU and UA lists.
Gregory also says he will review the guidelines.
Agenda 2) Face-to-face/Last call.
Reminder: Sign up for UAGL face to face, 11-12 October at Microsoft.
http://www.w3.org/WAI/1999/10/ua-agenda
IJ: WAI Team met yesterday. Consensus to wait until
after face-to-face.
Resolved: Go to last call after the face-to-face meeting.
Action Ian: Find out about MS review of document before ftf
and their participation in the meeting.
Action Ian: Find out from Judy about NN attendance.
Action Ian: Find out from Judy about Operasoft attendance.
IJ: Will talk to Håkon Lie.
HB: Softquad's HotMetal.
Action JG: Compose list of assistive technology developers
for invitation to ftf.
Agenda 3) Conformance.
JG: I think that we require a third category for
specialized tools. Not designed for general
use. But we should still have something for
them in the document. A category for them
would resemble the dependent UA category.
For both of these types, we need to address
the issue of device-independence. I looked
at charter, which discusses interoperability,
but not necessarily between dependent UAs.
RS: Would another group require a major rewrite of the
document?
IJ: No.
CMN: But requires lots of thought...
CMN: My problem with the whole concept is that
if I target a particular market, but provide
a customizable browser, I don't have to
worry about interoperability. This is a
description of Netscape Navigator (Mozilla).
Their targeted audience is people using
a desktop graphical browser.
RS: I mean targetted for a particular
disability.
CMN: You can build lists that allow you to
compose lists to let you target whatever.
IJ: What about just re-examining the device
independent checkpoint, for example?
Just say that if you support a particular
API, you must do it accessibly.
KB: So same set of checkpoints, just different
definition of "applies to"?
IJ: Yes.
MN: I agree with Charles. I'm concerned about how
people will twist around the document.
Can we be more specific in the Techniques?
IJ: I think the Techniques are too informative.
RS: One part bugs me: communication between
dependent user agents. Targetted user agents
(e.g,. multi-platform) that try to meet
accessibility guidelines don't have resources
for doing communication when this is not their
targetted audience.
CMN: I have a problem saying a targetted tool
is an accessible user agent. They are
useful, but don't belong in this document.
Or at least conformance doesn't apply.
GR: I don't think targetted information should
be included in a general document. (Said this
last week). Also, the impact matrix will
be useful for targetted UAs to find out what
applies to different groups. I don't think
another subclassing will help.
JG: What about tweaking other definitions?
GR: More reasonable approach. I'd have to review
a concrete proposal. E.g., in the case of HPR,
the graphical view is available to the user
(on demand).
IJ: Recall this from UAGL (about native support):
"A user agent supports a feature natively if it
does not require another piece of software (e.g.,
plug-in or external program) for support."
RS: With HPR, you have several options for having
Netscape render info. HPR could be considered a dependent
user agent, but it targets a particular audience.
MK: I was thinking about device-independence. If the
dependent UA gives an interface for the information
(e.g., speech) then you can use the guidelines.
E.g., are we requiring UAs to provide a keyboard API?
DP: Most dependent UAs I know of allow multiple device input.
PwWebSpeak has more standard components available than HPR.
So I see HPR more as a screen reader for Netscape.
CMN: We're talking about a conformance statement that will allow
HPR, PWWebSpeak, etc. can conform. I think this is a mistake.
RS: I think it's unreasonable to ask ATs to support all the
other AT requirements. Dependent UAs are an enhancement,
providing secondary access.
IJ: I think including in this document will promote interoperability
even if people don't have to satisfy all the checkpoints.
Just being there will benefit developers.
RS: I propose variable priorities. E.g., Priority 2 for dependent UAs.
IJ: Note danger of saying "Don't have to do this since we
don't have resources." Can use that argument for not providing
accessible documentation.
CMN: This WG is not chartered for creating legal requirements.
Broad guidelines fit too many people and doesn't fit anyone
in the end. I like the variable priority approach.
RS: I'd hate to not encourage people to develop assistive
technologies because the interoperability requirements
are too strong.
JG: Seems to be consensus not to have more than two categories.
JA: There's no definition of graphical desktop browser or
dependent UA.
Action Ian: Propose list of checkpoints that are "sensitive"
(affect targetted UAs) and propose variable priorities/rewording
for them. (Look at HPR's evaluation.)
Action Jim: Propose definitions to the list.
Agenda 4) Configuration checkpoints.
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0127.html
GR: Two checkpoints proposed (and list of techniques)
a) One for links: Allow user to configure what
information about links is presented. [P1]
(Would replace 9.5 and 9.6 in 27 Aug draft).
b) One for form controls: Allow the user to view a
list of FORM controls. [P1].
DP: I like merging a with 9.5 and 9.6.
IJ:
a) Rationale of 9.6 lost if merged with (a).
b) I don't think should be priority 1.
JA: Gregory has two checkpoints that he's rolled together
View, focus info available and configurability confusing.
GR: Then drop the second sentence from first proposed checkpoint.
About checkpoint 9.5:
GR: Make the dependency on micropayments more visible.
Action Ian: Make the dependency on micropayments more visible.
GR: I think that configurability is important, but also
need a maximum amount of information about links is important.
Propose 9.5 and 9.6 as P2.
Action Ian: Include GR's link checkpoint as P3 (configurability).
Change priority of 9.6 to P2.
Get techniques out of [1].
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0127.html
Discussion of proposed checkpoint for FORM controls list:
IJ: I don't think should be P1.
GR: Then P2. Tabbing can be disorienting if you don't know tab
order.
IJ: How does list of form controls help?
JA: Helps when form is designed poorly (e.g., submit button
is followed graphically by other important controls).
DP: Would a correctly coded form require this information?
IJ: Example of submit button after other controls can be valid HTML.
Unresolved.
Received on Wednesday, 8 September 1999 13:47:24 UTC