- From: Ian Jacobs <ij@w3.org>
- Date: Wed, 01 Sep 1999 15:22:42 -0400
- To: w3c-wai-ua@w3.org
- CC: jbrewer@w3.org
User Agent Guidelines Teleconference
1 September 1999
Present:
Jon Gunderson (Chair)
Ian Jacobs (Scribe)
Gregory Rosmaita
Harvey Bingham
Jim Thatcher
Kitch Barnicle
Mark Novak
Judy Brewer
Marja Koivunen
David Poehlman
Rich Schwertdfeger
Charles McCathieNevile
Jim Allan
Agenda [1]:
1) Review of action items
2) Last call scheduling
3) Conformance
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0278.html
Agenda 1) Review of action items.
1.JG: Draft outline for section 5.3.3 of techniques document.
Status: Done. (URL?)
2.IJ: Run NN (and Mozilla) through guidelines.
Status: Not done.
3.IJ: Issue 56 resolution
a) Mention media objects as example in checkpoint 1.6.
b) List as example in checkpoint 9.6
c) Incorporate media objects into 10.5 and 10.6.
Status: Done in 27 August draft.
4.IJ:
a) Add links to WG page with disclaimer about volatility of Working
Drafts and products.
b) Proposed disclaimer to be inserted in evaluations.
Status: Done in 27 August draft.
5.IJ Send proposal to WCAG to propose different wording on the
requirement for text rendering by UAs.
Status: Done in 27 August draft.
6.IJ: Create a list of metadata elements and techniques for HTML
Status: Not done.
7.HB, RS: Look at techniques document.
Status: HB has four pages written, pending.
RS: Not done.
8.HB: Run pwWebSpeak (with Mark H.) through the guidelines.
Status: Installed, starting to review. Hope to do this week.
9.GR: Run Hal through the guidelines.
Status: Done
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0301.html
10.DP: Technique 3.6 - Propose techniques
Status: Not Done.
11.DP: Run Jaws for Windows through the guidelines.
Status: Not Done.
12.KB: Fill in the table for UAGL and coordinate with Wendy Chisholm
of
Web Content
Status: Done.
http://www.w3.org/WAI/UA/NOTE-UAGL-impact-matrix-19990901
13.GG: Review proposal for techniques for accessing content.
Status: No information.
14.RS: Coordinate review of HomePage reader.
Status: Done.
15.CMN: Send proposal to the UA list about including an implementation
period as part of the recommendation process
Status: Not done.
16.CMN: Propose something about schemas.
Status: One more week, otherwise will drop.
17.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.
Status: Pending.
18.JA: Compose list of metadata sources for CSS. (e.g., generated
text)
Status: No information.
19.Marja: Compose list of metadata sources for SMIL.
Status: Not done.
HB: Will this include SMIL "Boston" (the latest version of SMIL?).
JB: Would be difficult since only a WD.
MK: Ok for SMIL 1.0 only.
20.RS: Consider the "applicability clause" and propose rewording of
the
conformance statement for checkpoints.
Status: Done. (URL?)
21.RS: Post list of checkpoints at issue to the list related to review
of
Home Page Reader.
Status: Done. Included in the HPR evaluation.
22.Reviewers: Read conformance section of guidelines before testing
sub-grouping of checkpoints with current products
23.Reviewers: Should be as specific as possible about product
versions,
os versions, etc.
IJ: People should send status info to Jon when they reply to
invitation to meeting.
ACTION JG: Include this message in next call for participation.
Agenda 2) REMINDER: Register for October F2F Meeting
JG: Remember to ask for the W3C rate at the hotel.
The registration page is up and running.
Agenda 3) LAST CALL: Timing and document preparation
JG: We are nearing, but have not entered last call. The original
intent of the face-to-face was to address comments that
came in during last call. But given state of techniques
document and number of open issues, not ready to go to
last call yet. Therefore, I'd like to discuss the impact
on the face-to-face meeting.
DP: Have all the unfilled techniques been assigned?
IJ: No. We sent a call for attention to the UAGL list.
JB: Do you want to send to the IG?
Action IJ: Send a detailed call for review to the IG.
JG: What do people think about going to last call?
MN: I have mixed emotions. Recent issues raise some
concerns. Also question whether we should have a face-to-face.
JG: I feel strongly that we should go to last call shortly
after the face-to-face.
RS: I feel we need to resolve the conformance issue ("targeted agent")
before going to last call. Otherwise, I think the guidelines
are pretty good.
DP: I think we should tackle outstanding issues first. I'm not
certain we could be ready for last call by the end of next week.
GR: I agree. In my evaluation, I emphasized checkpoints that
might be better as techniques (e.g., following a link involves
a fee).
IJ: (Review of process)
JB:
a) The sooner you finish the document, the sooner developers will
use it.
b) If you wait, you are likely to have a better document. But
don't wait too long since document may become irrelevant.
My preference, all other things equal, is to go to last call
as soon as possible. But if you have open issues, don't go
to last call yet. Another consideration is staff resources.
AUGL and UAGL are running neck and neck. If they go to Recommendation
in parallel, will make it tough on W3C Team resources. We don't
know how the timing of this document is affecting developer
browser release cycles.
JB: One possibility is to go to last call in three weeks, then
have a 3-week last call. That may not be enough time to
compile comments in time for last call. Strategically,
you don't want to send doc out twice for last call. However,
you can take extra time before going to Proposed Recommendation.
HB: A number of the major browser/assistive tech groups have
had no input to this process.
CMN: In AUGL, we've had a similar experience. But we've approached
developers lately who've said "We haven't commented but
we're trying to implement them!"
JB: What's the strategic impact of waiting?
IJ: Let's get other developers on board during this interval
before the face-to-face.
GR: Use evaluations as feedback to developers.
JB: But, until you say to someone "Last chance for comments",
people may not react or be motivated.
GR: In some cases, we may still light a fire under developers.
JB: We tried this in AU, but had no impact. We tried last year
internally but was a returnless effort.
JG: I don't think we'll get developers to jump to attention until
we go to last call.
JG: I propose that we try to go to last call 16-17 October. We
will revisit the question at the next teleconference. Judy,
Jon, Ian will discuss resource issues offline.
JB: I've argued for moving to last call soon. If the WG
feels that's ill-advised, please disregard my comments
as needed.
Agenda 3) Issues #77 and #79: Conformance for some assistive techs.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#77
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#79
JG: RS has proposed a third conformance class.
JG: IBM HPR, Avanti, PWWebSpeak don't fit easily into
dependent UA group. I'd like the dependent UA class to
represent advanced features. We don't care whether these
features are implemented in a browser or assistive tech.
JG: Biggest concerns with dependent UAs relate to compatibility
guideline (6 in 27 Aug draft).
JT:
a) What was the intent of the dependent UA category?
Seems to be "everything but graphical desktop browser".
JB: What about text browsers?
IJ: You conform by meeting a set of checkpoints. That's all it
means.
JT: I don't want Productivity Works to spend time putting
MSAA into its specialized interface. We would have to
in order to conform as dependent UA. They shouldn't
have to based on their "targetedness".
JG: Checkpoint about communication between dependent UAs
to promote communication between them. If that's the
major issue, let's review it. Are there other checkpoints
that don't make sense?
JT: There are others - because HPR is targetted to people
who use speech and the keyboard, we shouldn't have to
comply with 1.1.
CMN: The problem with the targetted approach is that
users working together may have different functional
needs. Graphical desktop browser is a targetted UA.
IJ: Have you seen "applies to"?
JT: No. That helps, but look at "low vision" requirements.
We have to say "not applicable". Our graphical interface
is not relevant to the evaluation.
JG: Issue: Which output of the tool do you evaluate? Primary
or secondary?
JT: The visual user interface of HPR is irrelvant for the
discussion we're having.
RS: The only reason for the visual interface is to help
a sighted user work with someone who cannot see.
JT: Also for debugging.
DP: If a blind person is teaching a sighted person, the
sighted person would still need an interface.
JT: HPR can turn on synchronziation for this purpose: cause
Netscape to bring up the same page.
DP: My concern here: can I voice command input into HRP.
That's a legitimate concern.
JT: Yes, through the keyboard API. You can use voice
recognition, therefore, to activate keys.
KB: Will the font/color adjustments apply to Lynx?
DP: Lynx doesn't care about fonts. So no, doesn't apply.
JT: We have comparable
requirements for voice (e.g., changing voice
for links).
CMN: Lynx hands off issues of font size to the OS.
But I agree that you can't style or control the
presentation of a link w.r.t. an ordinary piece of
text.
JT: For Lynx, there are no fonts.
IJ: There are colors, though.
JG: I'd like to move back to the question of
PWWebSpeak and HPR in terms of conformance.
Need to evaluate definition of "applies to".
CMN: If you take a given UA, you can say "This
UA requires a minimal set of input/output." For HPR,
the minimal output set is speech. MInimal input set
is the keyboard. That is has added input/output
is not relevant for conformance.
DP: There are one or two UAs that are uncommon in their
special capabilities for specific audiences. I think
we need only expand the definition of "applies" to
be able to exclude device issues.
JT: I agree with this approach.
CMN: Do HPR need to apply to UAGL at all? Maybe they
don't since they are trying to meet specific needs.
We've been addressing "general accessibility" up to
now. A UA that didn't allow that therefore wouldn't
conform. I don't think this is a bad thing. In short,
specialized tools may not need to conform to the
same set of guidelines as a generalized tool.
JT: Then bite the bullet and state that.
CMN: One possible outcome would be to drop the dependent
user agent conformance clause. Dependent user agents
don't conform unless they attempt to function
more generally. I think, however, that it's still
critical to explain how assistive techs will work with
general tools that conform.
RS: And for dependent user agents, we would need guidelines
for features relevant to a particular disability. What
I have a problem with is "do so natively" definition.
Do we need to redefine this for targetted UAs?
CMN: I think we should specify what we expect dependent
user agents to do in order to interoperate with a
conforming UA. But we should drop other requirements
for targetted UAs.
IJ: We've had this discussion already at the beginning
of 1999. It proved too difficult to break out
the different functions, devices, content types
into different documents or guidelines. We decided
to keep it all in one document.
GR: I propose creating W3C Notes for particular slices.
I second CMN's motion to drop the subclassing.
JG: Recall that the split was made, in part to allow
consumers to ask intelligent questions about
assistive technologies. I gather from previous
discussions that assistive tech developers want
to be able to conform to the UAGL. So benefits to
consumers as well as assitive tech developers.
RS: The impact matrix is very helpful for figuring
out what's important for a targeted agent.
E.g., I'm building a speech output device on
multiple platforms. I would want this type of
of checklist. I would want to consider less
the particular platform. If, on the other
hand, I were building a speech synthesizer to
run in the background would do something else.
IJ: We've already had a proposal (in January)
to not have conformance at all, but just
suggest profiles and have developers
fill out the checklist.
DP: Screen readers are, can, and should be providing
access through interfaces. My expectations
are rising. I think there is a need for the
dependent UA checkpoints that are in there that
promote interoperability and cooperation.
KB: One fear about the impact matrix is that
singling out a particular population will cause
people to ignore important features for other users.
In many cases, benefits are for multiple groups,
even though there may be a particular population that
would benefit most. In many cases, all users, and
use at the same time by several people, needs to be considered.
MK: The matrix is kind of a "next phase" after conformance.
GR: I don't think that targetted information should be
included in a document that addresses generality.
CMN: The impact matrix (assuming it's correct), allows you
to say "I'm not interested in a universally accessible
product" and you can be relatively sure to satisfy
requirements. I don't think we should write a Note, however.
It's a byproduct of the group.
IJ: I think our charter says that we must consider targetted
user agents. Can't just dismiss them.
RS: My main issue is "applies to". Perhaps we need wording
that some functionalities are not fundamental to
accessibility, but are only meant for people "along for the
ride."
IJ: I have problems with "along for the ride". A lot of people
would say the same thing about documentation. But it's
certainly vital to using software for many.
RS: I don't want to do major surgery on the guidelines. The
area that needs focus is "native support." Don't change
the whole document.
HB: Would it be worth having another reply (other than
yes, no, not applicable) for checkpoints.
Action CMN: Write a proposal for moving forward on this issue to
the list.
Action IJ: In document, highlight existence of "native"
and "applies to".
Received on Wednesday, 1 September 1999 15:23:29 UTC