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

Raw minutes from 23 May 2001 UAWG teleconference

From: Ian Jacobs <ij@w3.org>
Date: Wed, 23 May 2001 16:20:11 -0400
Message-ID: <3B0C1B7B.ABA4913@w3.org>
To: w3c-wai-ua@w3.org
23 May 2001 UA Guidelines Teleconference

Agenda announcement:

Minutes of previous meeting 18 May:

Next meetings: 24, 25, 30
 Regrets for 24th: Denis

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

Absent: Rich Schwerdtfeger
Regrets: Eric Hansen, Harvey Bingham

Reference document 11 April 2001 Guidelines:


 - IJ: Document in preparation.
 - Len Kasday memorial service tomorrow, 24 May 2001


#485: 10.2, 10.4, 10.7: "Provide a mechanism" what must be 
      done through the UI? 

Q: Is the API requirement for UI controls necessary, or is it just
necessary to provide access to UA functionalities? 

TL: IE lets you trigger some functionalities through an API that
doesn't involve UI controls. You can get and set different properties
of elements (mostly content), and then these elements are rendered
through the UI. Say the focus is on a button. An assistive technology
can query the DOM or MSAA trees for information about the button.

IJ: For example, can you print without manipulating UI control

TL: Yes.

DA: The reason for APIs is to have a standard method.

JG: I think we're missing a requirement that ATs be able to *activate*
UI controls of the conforming user agent.

IJ: I think writing to a control has that effect.

TL: Yes.


 - The requirement is that the user be able to operate the same
   functionalities that are available to the user through the
   user interface.
 - Write access to UI controls is preferred.
 - Read access is still required.

IJ: I could see the WG saying "The abstract requirement of
programmatic operation is fine, but the real world today 
means that the API needs to interact with the UI controls."

JG: We can talk about this at the teleconf with ATs.

TL: I don't have an example of an AT interacting with IE other than
through UI controls.

JG: AOL has a custom API for some reasons.

TL: But it is possible to write a browser where Trident handles the
content, but the container is written in such a way that you would
only be able to access the UI controls through a specialized UI.

IJ: Would it be desirable or permissable to have an API that allows
the AT to operate the user agent entirely without ever touching the 
native UI?

Resolved cascade for checkpoint 6.4:

 a) Requirement is for programmatic operation of what 
    can be done through the user agent user interface.
 b) If available and appropriate, use an API that allows 
    read/write access to UI controls.

Question: Are configuration files a sufficient "mechanism"
for 10.2, 10.4, and 10.7?

GR: In order for this to be of use, then the syntax needs to
be well-documented.

DA: Would it be considered acceptable to set the Windows features
through the registry only?

IJ: I would let the market decide here..

DA: One risk would be that the developers push accessibility
features into a text init file. 

TL: The UI for configuring the UA needs to be accessible, however you
do it. If everyone is relegated to a text file, then I think that the
requirement would be met.

/* TL leaves */

  - Configuration files would satisfy checkpoints 
    10.2, 10.4, and 10.7.
  - Include strong recommendation to provide access through
    the user interface as well.

DA: People who are not hackers, or who have a cognitive
disability cannot configure the UA through an init file.

IJ: Slight contradiction with style sheets, though. We have no
requirements about *how* you edit style sheets, only that they be
applicable and selectable. Tantek wants to implement the focus
highlight through style sheets. The user agent override the style
through user style sheets.

MQ: Editable text configuration files are useful.

DA proposal:

 - It is not acceptable to provide inaccessible user interface
   controls to meet the requirements of this document,
   and to compensate with configuration files. If a
   control is provided, it must be accessible (and it's fine to
   have an alternative configuration mechanism such as an
   editable configuration file).
 - If no user interface control at all (for anyone), then
   configuration file suffices.

JA: IE 5.5 (Windows and Mac) lets you create and apply user style
sheets. (under Tools/Internet Options/Accessibility/..).

GR: IE's style sheet support is truly minimal.


 - Say in techniques for 10.2, 10.4, 10.7 that configuration
   files are ok.
 - If editable configuration files are used, 
   document the syntax etc. of the configuration files.
 - Recommend that these features *also* be configurable
   through the user interface.
 - In techniques for 11.6, if profile is editable, document
   the syntax and semantics.
 - In techniques for 12.2, state that documentation of
   configuration files when used to satisfy other requirements.
   Give example of focus style through style sheets.

For the record:

 - Possible P2 requirement (in future document) that any
   configuration be possible through the UI.

#486: 12.2, 12.4, 12.5: Definition of features that benefit 

 - Accept Ian's proposed editorial changes to 8.1, 12.2, 12.4, 12.5
 - Move definition of "features that benefit accessibility" to
   checkpoint 12.2 (not in the Note).

#487: 12.5: "All changes" is too broad (for a number of reasons) 

GR: You don't have to document code changes. There is no low-level
code change requirement. 

MQ: Would it clarify things if you said "things that affect

JG: Is this just about the user interface?

GR: No, functionalities as well (e.g., support for "longdesc").

GR Proposal:

 - Document changes to user agent functionality and 
   user interface that affect accessibility.

DA: If the user has to do something different, tell them.

IJ: Should 12.5 be a P3?

GR: There's a problem of changes to the help system, which would not
let me read the rest of the documentation.

IJ: I disagree with this reasoning. I think that a new user is
in the same boat.

/* Ian drops request to lower 12.5 to P3 */


 - 12.5 Document changes to user agent functionality and user
 interface that affect accessibility.

DA: What about changes to APIs? You don't want products to break

JG: I don't think that Guideline 12 is really about documentation
for developers. Therefore, I don't think that changes to API
should be part of 12.5. We might talk about developer documentation
requirements in a future UAAG.


 - 12.5 Document changes to user agent functionality and user
 interface that affect accessibility.

#488: Glossary: Is the glossary normative or informative? 

GR: I am against splitting the glossary into normative/non-normative.


 - Add to glossary something like:

    "This is a normative glossary, although some of the terms (or
    parts of explanations of terms) do not affect conformance."

#489: Does "document source" include HTTP headers? 


 - Yes, HTTP headers are part of document source.
 - "Document source" isn't really used in our document. Document
   object is (and HTTP headers have already been taken into account).
 - No change to the document.

DP: But what is "text source" in 2.2?

IJ: Good question. We eliminated "document source" to avoid this

JG: I think it's the text bits that the user agent receives, and is
the basis on which the document object is constructed. Our assumption
is that it does not include meta information from the transport


 - In definition of document source, state that it is prior to repair.
 - In checkpoint 2.2, state that the text source is *prior* to
   repair. It's a text "resource manifestation" as used in [WEBCHAR].

Completed Action Items

6.JG: Schedule a telecon with AT developers on changes

10.DP and GR: Produce an example scenario to justify this checkpoint 
9.5 and to satisfy Issue #482

11.DA: Write Loretta Reid for info about Adobe APIs used for 
accessibility, including security features

The following will be done in the next draft:

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

Open Action Items

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

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

4.IJ: Revise proposal to address Issue #474.

5.JG: Talk to AT developers about assistive technology about using 
accessibility API

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

8.GR: Review event checkpoints for techniques

9.GR: Rewrite different markup (list of elements) that 2.9 applies to, 
for clarification.

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

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