- From: Ian Jacobs <ij@w3.org>
- Date: Thu, 24 Aug 2000 15:54:26 -0400
- To: w3c-wai-ua@w3.org
24 August 2000 UA Guidelines Teleconference
Present:
Jon Gunderson (Chair)
Ian Jacobs (Scribe)
Eric Hansen
Kitch Barnicle
Denis Anson
Gregory Rosmaita
David Poehlman
Tim Lacy
Dick Brown
Harvey Bingham
Rich Schwerdtfeger (for 2 minutes)
Regrets:
Mickey Quenzer
Jim Allan
Absent:
Charles McCathieNevile
Next meeting: 31 August
Minutes of previous meeting:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0256.html
Agenda:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0293.html
1.Issue 310: What level of WCAG compliance should checkpoint 11.1
require or should it be relative priority?
http://server.rehab.uiuc.edu/ua-issues/issues-linear.html#310
JG: One option is to include in your conformance claim what
at what level you conform to the documentation.
IJ: This requires a reviewer to go look at the claim in detail.
You don't know from "Level X" what the UA will have done for
checkpoint 11.1.
EH: Since P3 requirements "may help" accessibility, it seems like
requiring that for UA 1.0 is too stringent.
GR: Some WCAG 1.0 P3 requirements are very useful (e.g.,
acronyms). I think that it should be Level Triple-A in all cases.
DP: If you're developing a UA and your documentation is on the
Web, but your UA doesn't conform, that may be confusing. I agree
with GR.
IJ: The best documentation is no documentation...
IJ: I hear three proposals:
1) Level Double-A always
JG: This covers all things that would make access either
impossible or difficult. One reason in particular:
table formatting.
DA: Why does documentation have to rise to a higher level
than other checkpoints?
EH: Note that since we're allowing conformance by composite
UAs, the multiplicative effect is relevant.
2) Level Triple-A always
3) Relative priority
DB, TL: Intriguing (graceful), but may be complicated.
HB: Note that you could have bad, but accessible, documentation.
KB: As I look at the P3 checkpoints in WCAG 1.0, I'm not convinced
that all of them will make a difference. Some of them may, and
perhaps the WCAG WG should re-evaluate checkpoint priorities.
Level Double A minimal: KB, EH, DA, JG, IJ, DP, DB, TL
Level Triple A minimal: HB, GR
Resolved: Level Double minimal requirement for checkpoint 11.1.
Note: There was dissent on this resolution. WG
participants may request that their objections be
carried forth.
5.Issue 309: Applicability needs review: how to tell when
checkpoint MUST be followed.
http://server.rehab.uiuc.edu/ua-issues/issues-linear.html#309
Refer to analyses:
IJ: http://www.w3.org/WAI/UA/2000/08/uaag10-applic
EH:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0297.html
EH: I think it's ok to have applicability issues, but the tighter
our
focus is for this document (type of UA we're intending this
document for) the more the applicability issues disappear. For
instance, we're talking about UAs that implement text, graphics,
audio, and video. If you assume this in the target UA, you don't
need applicability clauses for these content types.
IJ: I agree with EH that the tighter the document, the fewer
applicability provisions are necessary. But I am not comfortable
with too much tightening (e.g., you have to implement audio in
order to conform).
EH: Note also that the less inapplicability, the greater the
likelihood that conformance will translate to accessibility.
IJ: EH has identified the "moving part" in the document: more
flexibility to conform means you either say nothing about
the moving part (let reasonable people interpret claims) or
you point to them in applicability clauses.
EH: I'm concerned about pursuing some of my proposals before
some distinctions are addressed in WCAG.
IJ: What about folding in the provision into the checkpoints?
(e.g., if you support X, allow control of X). But this can
get heavier as you have to combine provisions.
EH: I think we need to remove "graphical" from our description
of the target UA since graphics are not required by the document.
GR: I think that the applicability provisions should be folded
into the checkpoint somehow. Reduce work on the implementors.
EH: Applicability provisions are pretty intuitive: if you don't
support you don't have to do. If you explain this idea in one
place, you don't need to repeat in each checkpoint.
IJ: We didn't say for WCAG: "For any table that you use, use
table headers."
Resolved:
a) Incorporate proposal (only four provisions)
http://www.w3.org/WAI/UA/2000/08/uaag10-applic
b) Include informative list of checkpoints for the remaining
four. If the WG doesn't like this, get rid of.
JG: Ask developers at last call whether they want applicability
incorporated in the checkpoints.
Resolved: Change "graphical general purpose UAs" to
"general purpose UAs".
IJ: EH, have we missed other pieces besides "native", "recognize",
and "applicability" from your proposals?
EH: Possibly "primary/alternative".
IJ: We'll get to with issue 297, I think.
2.Issue 292: Review list of speech synthesizer characteristics
(checkpoint 4.11)
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#292
HB: Gender and pitch are very similar. You could get away with
gender alone. Some japanese users, for example, require more
information in inflection.
DA: Voice for a sighted person differ from requirements for a
blind person.
/* Reduce the list? */
HB: No, satisfied with current list.
/* Add to the list? */
GR's proposal:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0467.html
IJ: How do you tell your speech synthesizer what you want?
If you're implementing CSS2 aural style sheets, I know how
the mapping from content to rendering works. Otherwise?
DA: It seems like that the user should be able to configure
everything
that's configurable.
IJ Proposal:
a) Leave speech synthesizer checkpoints as they are.
b) Ensure that Voice Browser WG documents include accessibility
features. There is a WG dedicated to this topic.
GR: Need to ensure that UAs don't preclude users from configuring
their speech synthesizer software.
GR: Propose : speak-out, speak-punctuation, and number processing
(as described in CSS2 speak-numeral).
Resolved:
a) Add verbiage for configuration of spelling, punctuation,
and number processing offered by the speech engine.
b) Get Voice Browser WG review of these three checkpoints
in last call.
c) Ensure coordination with VBWG for future coordination.
Completed Action Items
1.IJ: Rewrite what "recognize" means based on user agent
programmed functionalities. Refer to 18 August draft
--
Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 831 457-2842
Cell: +1 917 450-8783
Received on Thursday, 24 August 2000 15:54:29 UTC