W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 2001

Raw minutes from 16 May 2001 UAWG teleconference

From: Ian Jacobs <ij@w3.org>
Date: Wed, 16 May 2001 16:10:47 -0400
Message-ID: <3B02DEC7.DF59E17F@w3.org>
To: w3c-wai-ua@w3.org
16 May 2001 UA Guidelines Teleconference

Agenda announcement:

Reference document 11 April 2001 Guidelines:

Minutes of previous meeting 10 May:

Next meetings:
 May 17, 18 (extra)

 Jon Gunderson (Chair), Ian Jacobs (scribe), David Poehlman,
 Denis Anson, Scott Totman, Jim Allan, Gregory Rosmaita, Tim Lacy

Absent: Mickey Quenzer, Rich Schwerdtfeger, Eric Hansen

Regrets: Harvey Bingham
 Also HB regrets for 23 May.


 - Please review teleconference schedule on WG home page.
   There is information about the teleconferences May 17, 18,
   23, 24, and 25.

 - Next draft of Techniques will have a "Who benefits" entry for
   every checkpoint. I will ask people to review those paragraphs

 - Check out Gregory's test pages:

/* We do introductions since this is ST's first UAWG
teleconference */


Issue #469: Write access to controls that can be changed through
            the user interface.

Proposal: For harmony with checkpoint 6.1 (DOM write access):

 a) Split 6.3 into read and write, with write access only for
    what can be done through the UI.
 b) Split 6.4 into read and write, with write access only for
    what can be done through the UI.

ST: That would satisfy me.

JG: Do we have examples of UI control values that the user would
not be able to change through the UI?

ST: We have a control that simulates HTML and is for display
only. The user should not be able to write to those values.

TL: That's pretty much what we do. We may have editable controls
that are not editable until they become visible. You might have
an editable property whose visibility property is hidden.

Resolved: Accept proposal.

Issue #470: Navigation to disabled active elements


 - Clarify definition of enabled/disabled/interactive elements.
   Refer to IJ's proposal:

 - State that the assumption of this document is that the content
 focus always designates zero or one enabled or disabled elements
 (but never non-interactive elements).

 - No change to checkpoint 9.6, but mention in techniques that a
 configuration option to include disabled elements (for reasons
 cited by Scott) is fine.

 - Revise definition of focus to set expectations for it. Also
 mention that a "caret", while it takes keyboard input and is
 stateful, is not generally used to activate enabled elements and
 so is not what we are talking about.

Resolved: Accept proposal.

Issue #471: Standard versus proprietary APIs for compatibility with 
assistive technology

See Rich's defense (supported by Tim):

JG: Why didn't MSAA suffice?

ST: Our client predates it. Most of the ATs we work with predate
it as well. MSAA is used strongly for Web activities, but for
good old Windows apps, not all ATs use them.

JG: Our main concern is to promote interoperability. A lot of AT
developers don't have resources to develop specialized APIs.
Therefore, I think UAAG should probably not promote proprietary
APIs as that may not stand the test of time. It sounds like you
are saying that MSAA could be used, but reimplementation would be

ST: I don't think we will rework MSAA into the Windows portion of
our application. I can see integrating it into our browser. I
don't think most ATs have integrated it into the Windows portion
of their software.

TL: I recognize what ST is saying. The initial implementations of
MSAA left a lot to be desired. I know of several AT vendors that
the IE Team works with to implement MSAA correctly and to get it
working to their satisfaction. What I am concerned with by
following the proprietary model is that AT vendors will have to
write "monstrous case statements" to select from available
APIs. I don't think that this direction benefits AT developers or

ST: I think that Jaws would fail this requirement because it
doesn't use std APIs for every feature.

IJ: Let's distinguish:
 a) Deployed software
 b) Inadequate API issue
 c) Will ATs actually use it?

GR: Should include rationale as well when an API doesn't 
meet needs.

IJ: That's a lower priority requirement, as long as the API has
been documented.

DP: AOL has to deal with browsers AND Windows applications. ST
said he could see implementing MSAA in the UA.

ST: This UA/non-UA line can be fuzzy in the AOL client.

DA: I think it would be frustrating for the end user to have only
part of an application that conforms.

ST: We use another internal markup language (FDO) for parts of
the application outside the browser.

ST: Would you consider an instant messaging system a user agent?

JG: We wouldn't exclude it, but we haven't considered issues
raised by such a technology. The farther you move away from the
model we've considered, the fewer checkpoints will apply.

ST: I think that the vendors we work with don't use MSAA.

TL (to ST): MSAA aside, does the viewer window implemented by the
AOL client have a published API?

ST: Yes, standard windows calls (e.g., get text). Our custom
controls now respond to calls used by assistive technologies.

TL: From an interoperability standpoint, the thing that concerns
me from a user's standpoint: if I want AOL, and I'm restricted to
one or a small subset of AT vendors to get it, that would bother
me. An unpublished API is problematic.

TL: Is it correct to say that I could use AOL with several

ST: Yes.

ST: For Jaws, we use Jaws scripts (they have a scripting
language). I write scripts for my client that Jaws
interprets. Is that a problem? Or would that be considered a
standard API?

DP: I think most AT vendors provide a similar mechanism for
better interaction. If only one or two vendors are capable of
providing an interface, is that because the other vendors don't
have a way of interacting?

GR: I think that the scripting files and set files are
intermediate steps, but not the standard API.

IJ: I don't think that Jaws scripts would be considered a
standard API; it's pretty proprietary. On the other hand, I would
consider MSAA the de facto standard on Windows. So we should
probably be more specific about what we are expecting.

/* TL drops off */

 a) Deployed software: I don't think this should cause
    us to change our document.
 b) Inadequate API issue: I think we can address this
 c) Will ATs actually use it?: I think we need more AT input.
    Action JG: Talk to AT vendors (e.g., on the list) 
    about use of standard APIs.

GR: AT developers I've talked to have said that if browsers used
standards they would code to it. I think UAAG 1.0 needs to take
the lead to promote standards.

JG: We need to stop the pattern of kludges to satisfy
accessibility requirements.


 a) Leave the primacy of standard APIs in the document.
    Do not allow conformance simply to "better APIs".

 b) For checkpoints 6.3-6.5 and 6.7, make the following consistent
 with 6.6: If std API not available or does not allow the UA to
 satisfy the requirements of the document, use a publicly
 documented API. 

/* ST leaves */

DP: I have some concerns about the second sentence. A few years
ago, a screen reader called ISIS cost more than the software it
ran on. In order to do anything useful, you had to have a second
screen reader. I don't want a market where a UA can conform but
not really interoperate, or where some AT vendors are put at a

IJ: I think that the situation would be the same anyway, but
we're just asking that the API be public. That seems to be an

JG: I don't know who will make the decision whether someone's
publicly documented API is really better than something like

IJ: We are distinguishing:
 - If the API is broken: allow people to conform and work around it.
 - If someone can do better, we don't allow conformance
   for better, but non-standard APIs.

 c) Include in well-formed claim a requirement which APIs
    are being used to satisfy Guideline 6 (since interoperability
    important). [Should include some rationale if non-standard
    API is used.]

 d) For checkpoints 6.3-6.8, change to "at least one standard


IJ: We still have the outstanding question of what we accept as a
standard API. Glossary states:

  "As part of encouraging interoperability, this document
  recommends using standard APIs where possible, although this
  document does not define in all cases how those APIs are
  standardized (i.e., whether they are defined by specifications
  such as W3C Recommendations, defined by an operating
  environment vendor, de facto standards, etc.)."

JG: Some characteristics:
 a) Publicly documented
 b) More than one AT be able to use it ("reusable by other

/* Denis leaves */

IJ: Cascade:
 a) Use standard API (where std means W3C Rec or public
    product of another stds organization).
 b) If no std API exists or is broken, use a public API
    that enables interoperability (i.e., not be limited
    to communication with only one specific assistive tech).

GR: WindowEyes and HAL offer MSSA-mode and non-MSAA mode.

JG: Jaws uses MSAA for some things and not others.

Action IJ: Write up a proposal for the cascade of APIs:
 - Standard first (more strictly defined)
 - Public reusable API next.
 - Requirement for at least one accessibility APIs covered by
   6.5. (see issue 472).

[6.7 is a special case since talks about OE specifically.]

Proposed language for 6.6:

6.6 Implement at least one (standard?) API (e.g., of the
operating environment) designed to benefit accessibility and
allow interoperability with assistive technologies.

Action IJ: Include this as part of previous action.

Issue #475: Checkpoint 2.9: Does this checkpoint mean auto rendering of
content in same viewport?

Resolved: State that to satisfy 2.9, the user agent must allow
configuration to render all conditional content automatically,
but that this may be done at different time in different
viewports. [Indeed, it is probably a big mistake to render
everything at once in the same viewport.]

Issue #478 4.9: Clarify that global volume control can 
cover content and UI controls


 - For 4.9: It's ok if the technique also allows control of UI
            control volume.

 - Add to the Conformance section something like:
      "For the purposes of conformance, for those requirements
       that are "Content only" but that also have manifestations
       in user agent features, a technique that satisfies both
       Content and user agent features will satisfy the checkpoint
       except where the checkpoint explicitly states the

   In short: Content only is a minimal requirement.

Completed Action Items

GR: Screen shot of Lynx for refresh, and redirect.

GR: Will send test pages to list
Source: http://www.w3.org/WAI/UA/2001/05/wai-ua-telecon-20010503

Open Action Items

IJ: Edit the text of checkpoints 2.1, 2.2, 8.1, and 8.2 so that UAs are
required to conform for all formats that are implemented.
Source: Minutes 19 April 2001 Teleconference

IJ: Make mention of animations, text streams, and refresh in the
Source: Minutes 19 April 2001 Teleconference

IJ: Coordinate usability testing of the guidelines (JRG volunteers to be 
one of the testers).
Source: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0137

RS: Send pointer to information about universal access gateway to the
Source: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0258

GR: Review event checkpoints for techniques

GR: write different markup (list of elements) that 2.9 applies to, for 

CMN: Find out from SYMM WG whether repositioning of objects will appear
the spec (or should be in UAAG).

MQ: Review speech checkpoint techniques document

Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 831 457-2842
Cell:                    +1 917 450-8783
Received on Wednesday, 16 May 2001 16:10:49 UTC

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