W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 1999

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

From: Jon Gunderson <jongund@staff.uiuc.edu>
Date: Wed, 29 Sep 1999 16:33:35 -0700
Message-Id: <4.1.19990929162943.00b26a10@staff.uiuc.edu>
To: w3c-wai-ua@w3.org

Chair: Jon Gunderson

Scribe: Ian Jacobs

Rich Schwerdtfeger
Mark Novak
Kitch Barnicle
Gregory J. Rosmaita
David Poehlman 
Jim Thatcher
Denis Anson
Marja-Riitta Koivunen
Charles McCathieNevile

Jim Allan 
Markku Hakkinen

Action Items

Completed Action Items 

   1.JG: Contact DP about particpation 

   2.JG: Contact GG about particpation and review of conformance proposal 

   3.IJ: Find out about MS review of document before F2F and their
participation in the meeting. 

   4.IJ, MRK: Send reference on SMIL note to UA list

   5.IJ: Make these editorial changes about continuous equivs for audio
captioning and descriptions 

   6.IJ: Link to "altifier" from Techniques document. 
     Link to ER tools page from techniques. 

   7.Working Group: Review IJ proposal for changes in conformance for
discussion next week

Continued Action Items 

   1.JG: Run pwWebSpeak (with Mark H.) through the guidelines. 

   2.JG: Propose techniques for rendering of frames 

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

   4.GR: Write a proposal to address issues about spawned windows. 

   5.DP: Technique 3.6 - Propose techniques 

   6.DP: Run Jaws for Windows through the guidelines 

   7.MR: Working on SMIL techniques in addition to SMIL access note. 

   8.MR: Coordinate with Geoff Freed so that issue related to aalternatiove
content is sufficiently addressed in PF. 

New Action Items 

   1.IJ and JG: Send a proposal to the ua list for resolution of the
conformance issues related to assistive technology 


Agenda [1] 

[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0427.html 

1) Review of action items.

   1.JG: Run pwWebSpeak (with Mark H.) through the guidelines. 
     Status: Not done. 

   2.JG: Propose techniques for rendering of frames 
     Status: Pending. 

   3.JG: Contact DP about particpation 
     Status: Done. He'll try to join today. Will be at ftf. 

   4.JG: Contact GG about particpation and review of conformance proposal 
     Status: Done. No news back. 

   5.IJ: Find out about MS review of document before F2F and their
participation in the meeting. 
     Status: Pending. Waiting for MS to call back. Dick will participate in
part of the meeting. Someone else from MS will also participate. Both will
review next

   6.IJ, MRK: Send reference on SMIL note to UA list 
     Status: Done. 

   7.IJ: Make these editorial changes about continuous equivs for audio
captioning and descriptions 
     Status: Done. 

   8.IJ: Link to "altifier" from Techniques document. 
     Link to ER tools page from techniques. 
     Status: Done. 

   9.DP: Technique 3.6 - Propose techniques 
     Status: ? 

  10.DP: Run Jaws for Windows through the guidelines 
     Status: ? 

  11.GG: Review proposal for techniques for accessing content.
     Status: ? 

  12.GR: Write a proposal to address issues about spawned windows. 
     Status: Pending. 

  13.MR: Working on SMIL techniques in addition to SMIL access note. 
     Status: ? 

  14.MR: Coordinate with Geoff Freed so that issue related to aalternatiove
content is sufficiently addressed in PF. 
     Status: ? 

2) Announcements:

     a) Send agenda items to UA face-to-face. 
     b) WAI AU in last call until 4 October. 
     c) DOM 2 in last call until 8 October. GR: During yesterday ER call,
some topics related to UA dependencies. GR will send pointer to the list on
those notes.
     In a week or two, requirements will come from ER to UA. 

3) Conformance. 

Interoperable proposal: 

Ian's summary: 

Jon's proposed terminology: 

DA: I'd like to argue that all user agents should be interoperable even if
designed for a particular funcational need. Some users have several

RS: Developers want to support many groups. Don't have resources however,
and you shouldn't be penalized for getting products out to users. 

IJ: Types of interoperability 

     a) Use standard input/output APIs of the OS. 
     b) Should tools make their functionalities available through their own
     c) What API to exchange document data (e.g., DOM)? 

We agree less as we go down the list. 

JG: I think we're having a problem of terminology. 

IJ: See the summary. I think the goals of the WG are contradictory and
leading to issues. 

JT: But Assistive Technology developers want to be able to claim conformance. 

RS: If your Desktop Graphical User Agents (DGUA) targets the general
public, they should be accessible to the general public. You want to say
this rather than
make targeted ATs comply. 

CMN: The difficulty is that you have to say when a UA targets the general
public or a particular user group. They could say that they're not meant
for the general
public. They're only meant for people who want a basic graphical interface
who rely on the mouse and who rely on the keyboard for some things. This
happens to
satisfy many needs of the deaf community. 

JR: I think MS would get shot down for this. Consumer pressure could force
conformance as a mainstream browser. 

RS: These companies are spending a lot to make their products accessible.
They wouldn't do what you're saying. 

DA: So when we split, we run into logical problems. That's because we're
trying to be general and specific at the same time. Would it be a problem
for specialty
browsers to not be 100% conformant? 

IJ: I.e., use the checklist for them. I don't think "80% conformant" makes

CMN: So combine the models: conformance means you do everything. Use the
impact matrix for specialized tools. 

JT: So you won't allow the AT developer to use the label in a practical

KB: If I'm a purchasing agent for the dept. of defense that says "HPR"
conforms and "IE" conformance, why would I choose one or the other? 

JG: Most AT costs money. Most desktop browsers are free. 

KB: Purchasers need more information than just conformance. How to tell
purchasers what/where more information is required? 

IJ: If you're only meeting 30-40% of the checkpoints, then the guidelines
really aren't applicable to your tool. 

CMN: HPR provides some basic graphical rendering (through NN). But we don't
want HPR to have to fix NN to conform to the Guidelines. Also, speech output
will be part of the OS in a few years. 

JT: We're marketing to people who want speech. There's only one area of
interoperability where I'm uncomfortable marking "N/A": providing access to
other AT.
Should be stronger still. 

CMN: I think there's very solid consensus that there's a class of tools
that needs to provide accessibility for everyone (either do it accessibly
natively or by providing
information to others). 

JG: I sent to the WAI CG a proposal about external bodies verifying

DA: In our particular need, the conformance label doesn't have a specific
meaning. If you're a non-visual browser only, conformance means one thing.
If you have no
mouse, you may conform somehow else and yet you use the same label "conforms". 

JT: AT people want to be able to identify important checkpoints for them. I
can say that I can conform already by checking of a certain number as "N/A". 

CMN: Part of the interoperable question is that if you remove it, you have
to specify carefully what you do. (Note: Tools need to handle tables
themselves.) The
EIAD browser (for people with some cognitive impairments) is highly
regarded (and expensive) and has a touch screen interface. People who have
brain injuries
often has mobility problems as well. Should EIAD provide an API for their
touch screen interface? EIAD doesn't support the keyboard API. Is it
necessary that they
support the keyboard API so that people can use it? 

JG: If they're not supporting the keyboard, then they shouldn't have to.
You say you support the touchscreen (and should do so accessibly). 

(Digression into discussion of the keyboard, checkpoint 2.1) 

(Back to conformance). 

IJ: Let's look at these two questions: 

     a) We want mainstream browsers to be able to claim conformance. 
     b) We want ATs to be able to claim conformance. 

KB: What does (b) mean? Few ATs will conform alone. 

DA: Most ATs add functionalities to mainstream browsers. 

DP: PWWebSpeak runs alone. 

JG: Don't know about Avanti. 

GR: I had proposed that we do away with subclasses and address "user agents". 

DP: This troubled me as well a while back. 

GR: I think mainstream browsers, more than HPR, would want the marketing
force. HPR already has the target audience on board already. 

JG: If something claims conformance, there will be base-level conformance. 

JT: There are a number of content guidelines that are implemented in ATs
only. Need support from ATs for these. 

GR: I think that's a self-fulfilling prophecy. 

JT: The only difficult line is on interoperability. 

DA: The basic guidelines are for base functionality. The mainstream
graphical browsers must provide a way to provide all of this access. When
we use something
like HPR, this is an add-on that is providing some of the non-native
functionality. We're treating the HPR erroneously as a mainstream browser
as soon as they do
graphical rendering. 

RS: I like the suggestion of breaking it up between AT and graphical
desktop. How about this: 

     a) Identify all interoperability checkpoints. 
     b) Priority 1 for mainstream 
     c) Other priorities for ATs. 

DA: Don't make a lower priority, but narrow it. If you're rendering
information provided by a mainstream browser, you need to communicate back
to the browser
what you did with it. The AT communicates back to the underlying UA what
has happened (e.g., linearizing graphically). You don't have to deal with
control since the underlying browser does that. 

GR: If you use JFW and modify the page, and the page gets modified, the
changes are lost. 

DA: When we talk about interoperability, we need to talk about it

CMN: An assistive technology does need to provide interoperability (e.g.,
by relying on interoperable interfaces provided by the browser). 

DA: In short: interoperable associatively for some functionalities. 

JT: I don't want priority differences, I want the guidelines to say that
these checkpoints are for mainstream UAs only. 

KB: I lean towards variable priorities. 

MN: I don't think we should have checkpoints and then say that they don't
apply. I'd be in favor of going back to define the base functionalities. We
need access to

KB: Struggling over the conformance issue is not as important as ensuring
functionalities are provided. Allow HPR to say how they work with
mainstream browsers. 

CMN: I believe (and I think consistenly) that the answers to Ian's two
questions are yes (clearly) and "this isn't a requirement, but if we can
write the document to
allow it, that's great." 

GR: Let's function on base functionality. I agree with Mark and Denis - I'd
rather do away with the split and define what it is that the UA must do to
be useful. 

DP: In general, I think it's more important to deal with the basic issue of
helping developers achieve accessibility. I don't think conformance by ATs
should be a

RS: I think it's import for ATs to be able to conform. It's also important
for ATs to have a reasonable bar to conform to. E.g., as a blind user, I
need a "where am I"
functionality. I think that this WG includes experts that identify user
needs. Having guidelines for an AT to follow is a good thing to have. We
should have an
interoperability guideline that's for mainstream only. 

JT: We need to encourage ATs to do more things. Some division is a good thing. 

DA: To conform, a UA should do all of the checkpoints. The checkpoints are
useful to ATs and ATs add functionality to the underlying browser. Unless
the UA is
claiming to provide universal access, the AT shouldn't try to conform. 

MK: I think browsers should conform. For ATs, there are a lot of points
that need clarification. That should be the next step for targeted user
groups. They should
take the guidelines and build specific guidelines from them. So no special
conformance for ATs. They should use the impact matrix. 

IJ: I think that conformance by ATs is less of a priority than other
issues. If that needs to be removed as an obstacle to advance, then let's
remove it. But I'm not
insensitive to the marketing requirements of AT developers nor to their
participation in the group. 

KB: I think we're moving closer (notably by removing distinctions for a
number of checkpoints). 

RS: Is there consensus that we have dependent and desktop UAs? 

CMN: There is a terminology issue, but the issue is deeper than a
terminology issue. 

IJ: The issue is "Who is conformance for besides graphical desktop browsers?" 

JG: Consensus today is that conformance is for mainstream. 

GR: For ATs, use the impact matrix plus some note on usability. 

GR: I think the terminology should be used cautiously since lynx or w3 may
not fall under the name. You might just say "User Agent Guidelines..." 

CMN: Allow a different institution (e.g., RNIB) to define their own
conformance statement, based on the UAGL impact matrix. 

IJ: Distributed conformance may confuse people. 

JT: I think that the impact matrix won't work for us to be able to claim
conformance. You can't say that the interoperability checkpoints don't
apply to some
disabilities. I'm willing to say that the guidelines apply to mainstream only. 

RS: I wouldn't mind having checkpoints, but maybe we don't have to conform. 

GR: I wouldn't support conformance based on the impact matrix alone. It
would be the basis of more formal statement built on top of it. 

Action Ian and JG: Write a proposal to the list. 

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. 

Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Chair, W3C WAI User Agent Working Group
Division of Rehabilitation - Education Services
University of Illinois at Urbana/Champaign
1207 S. Oak Street
Champaign, IL 61820

Voice: 217-244-5870
Fax: 217-333-0248
E-mail: jongund@uiuc.edu
WWW:	http://www.staff.uiuc.edu/~jongund
Received on Wednesday, 29 September 1999 17:29:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:23 UTC