- From: Ian Jacobs <ij@w3.org>
- Date: Wed, 23 May 2001 16:20:11 -0400
- To: w3c-wai-ua@w3.org
23 May 2001 UA Guidelines Teleconference
Agenda announcement:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0186
Minutes of previous meeting 18 May:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0174
Next meetings: 24, 25, 30
Regrets for 24th: Denis
Present:
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:
http://www.w3.org/WAI/UA/WD-UAAG10-20010411/
----------
Announcements
----------
- IJ: Document in preparation.
- Len Kasday memorial service tomorrow, 24 May 2001
----------
Discussion
----------
#485: 10.2, 10.4, 10.7: "Provide a mechanism" what must be
done through the UI?
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#485
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
objects?
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.
Proposal:
- 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 */
Proposed:
- 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.
Resolved:
- 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
accessibility.
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#486
Resolved:
- 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)
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#487
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
usability"?
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 */
Proposed:
- 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
suddenly.
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.
Resolved:
- 12.5 Document changes to user agent functionality and user
interface that affect accessibility.
#488: Glossary: Is the glossary normative or informative?
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#488
GR: I am against splitting the glossary into normative/non-normative.
Resolved:
- 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?
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#489
Resolved:
- 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
problem.
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
protocol.
Resolved:
- 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
Source:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0174
10.DP and GR: Produce an example scenario to justify this checkpoint
9.5 and to satisfy Issue #482
Source:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0164
Done:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0204
11.DA: Write Loretta Reid for info about Adobe APIs used for
accessibility, including security features
Source:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0174
Done:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0173
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
document.
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.
Source:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0164
5.JG: Talk to AT developers about assistive technology about using
accessibility API
Source:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0161
7.RS: Send pointer to information about universal access gateway to the
WG.
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