MINUTES(edited): W3C WAI User Agent Telecon 1 September 1999

Attendance

Chair: Jon Gunderson

Scribe: Ian Jacobs

Present: 
Jim Thatcher
Kitch Barnicle
David Poehlman 
Gregory J. Rosmaita
Charles McCathieNevile 
Harvey Bingham
Mark Novak 
Judy Brewer
Marja Koivunen 
Jim Allen

Regrets:



Completed Action Items 

   1.JG: Draft outline for section 5.3.3 of techniques
document.http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0309.html 

   2.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. 

   3.IJ: done
     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. 

   4.IJ Send proposal to WCAG to propose different wording on the
requirement for text rendering by UAs. done 

   5.GR: Run Hal through the guidelines.
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0301.html 

   6.KB: Fill in the table for UAGL and coordinate with Wendy Chisholm of
Web Content
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0300.html 

   7.RS: Coordinate review of HomePage reader.
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0234.html 

   8.RS: Consider the "applicability clause" and propose rewording of the
conformance statement for checkpoints. 
     Status: Done in HPR review 

   9.RS: Post list of checkpoints at issue to the list related to review of
Home Page Reader.
     Status: Done in HPR review 

Continued Action Items 

   1.IJ: Run NN (and Mozilla) through guidelines. not done 

   2.IJ: Create a list of metadata elements and techniques for HTML 

   3.HB, RS: Look at techniques document. 

   4.HB: Run pwWebSpeak (with Mark H.) through the guidelines. 

   5.DP: Technique 3.6 - Propose techniques 

   6.DP: Run Jaws for Windows through the guidelines. 

   7.GG: Review proposal for techniques for accessing content. 

   8.CMN: Send proposal to the UA list about including an implementation
period as part of the recommendation process 

   9.CMN: Propose something about schemas 

  10.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. 

  11.JA: Compose list of metadata sources for CSS. (e.g., generated text) 

  12.Marja: Compose list of metadata sources for SMIL. 

New Action Items 

   1.JG: Include in RSVP a request for inidicating completion of action items 

   2.IJ: Send a detailed call for review to the IG. 

   3.IJ: In document, highlight existence of "native" and "applies to". 

   4.CMN: Write a proposal for moving forward on this issue to the list. 

Minutes

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. 

   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 
     Status: done 

  23.Reviewers: Should be as specific as possible about product versions,
os versions, etc. 
     Status: done 

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. 

RS: Braille devices are non-standard and HPR does not support them. We did
not intend that HPR be used with a Braille device.

CMN: Braille is a standard device with an API

JT: Braille has a standard API?

CMN: It is a standard AT

JT: Is an important issue, but I don't think it is addressable. Braille is
to nebulis. I don't think that trageted browsers should be required to
support technologies like
Braille.

JA: Joins 

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".



Copyright  ©  1999 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C
liability, trademark, document use and software licensing rules apply. Your
interactions with this site are in
accordance with our public and Member privacy statements.

Received on Thursday, 2 September 1999 09:27:20 UTC