- From: Ian Jacobs <ij@w3.org>
- Date: Mon, 15 Jan 2001 17:39:29 -0500
- To: w3c-wai-ua@w3.org
Hello,
Having published the 13 January 2001 draft of
the UAAG 1.0 Guidelines [1] and Techniques, I thought
it might be helpful to summarize where I think we
are.
- Ian
[1] http://www.w3.org/WAI/UA/WD-UAAG10-20010113
1) There are 26 open issues. See my summary of them
below.
2) Once we have resolved the remaining issues, we
need to respond to each reviewer and explain our
resolutions. If we have not convinced
a reviewer to withdraw an objection, then we
present the objection to the Director in our
request to advance to the next stage of the process.
Suggested Action IJ: I will probably be the one to write
emails to all the reviewers explaining the WG's
resolutions.
3) We have to decide whether we wish to return to
Candidate Recommendation for implementation
experience, or request that the Director advance
the document directly to Proposed Recommendation.
I think that we will probably discuss that at
the face-to-face meeting based revisions
of the guidelines and the implementation report.
Where we have weak implementation experience, we
may decide to seek out implementations or to
delete some requirements.
Suggested Action IJ: Prepare a new implementation report
for the face-to-face meeting.
Suggested Action Working Group: Keep sending implementation
reports to the list!
4) Timeline. This is not an official timeline, just
a projection by me.
4.1) We complete our open issues over the next three
teleconferences: 18 Jan, 22 Jan (a Monday), and
25 Jan. In order to complete the open issues
rapidly:
a) You are strongly encouraged to attend the
teleconferences.
b) I include some rough proposals for some of
the issues below.
4.2) During the month of February:
a) Send responses to reviewers and document
any outstanding objections.
b) Prepare a new implementation report.
c) Create a stable version of the guidelines
for review by the Working Group before the
face to face meeting.
4.3) 1-2 March: Face-to-face meeting in Cambridge.
4.4) If we decide to request to advance directly
to Proposed Recommendation, then:
a) We need to ensure that we have implementation
experience for all of our requirements. In
some cases, I don't believe we need to show
implementation experience because other groups
are responsible for this (e.g., WCAG or DOM).
b) Suppose the Director sends the Proposed Rec
to the Advisory Committee on 21 March (which
gives us several weeks to deal with issues that
arise at the face-to-face meeting). That
means that PR ends 18 April, we allow 3 weeks
to address issues that were raised, one week to
prepare the document, and UAAG 1.0 becomes a
Recommendation around 15 May.
4.5) If we decide to spend some time in Candidate
Recommendation, add a couple of months to this
timeline.
----------------------------------------------
Status of remaining issues and some proposals
----------------------------------------------
321, 322, 358, 359:
These are all about definitions and editorial changes
(to checkpoint 2.3 and possibly a couple of others).
Status: Eric, Al, and Ian are still working on a proposal
to resolve these issues.
324: How do developers interpret the phrase
"appropriate for a task" in checkpoint 6.2
Status: Awaiting discussion of proposal from Ian:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0437.html
327: Add requirement for support of charset expected of each API?
Status: We resolved to add a requirement at 16 Nov
face-to-face. Awaiting discussion of proposal from Ian:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0088.html
373: Checkpoint 10.5: Propose raising to Priority 1
Proposed: The reviewer suggests raising the priority of the
checkpoint to document changes that affect accessibility from
P2 to P1.
Proposed by IJ: Don't raise this priority. It's already P1 to
document all features that benefit accessibility. Therefore,
while useful, lack of documentation of the changes specifically
would not make understanding the documentation impossible.
382: Checkpoint 3.2: Hard to do in many cases (e.g., when scripts
used).
Status: I wrote the reviewer asking for more details and have
not heard back yet except that the reviewer acknowledged
reception of my request.
Proposed by IJ: Since 3.2 is about animated images, not all
animated effects, scripting is not an issue. No change to the
document.
389: Conformance: Hard to test conformance in an objective
fashion.
Status: I wrote the reviewer with clarifications and asked for
comment. No response yet.
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0038.html
Proposed by IJ: We have reduced some of the conformance
requirements as a result of the reviewer's comments. We have
worked very hard on this conformance scheme and rejected a
number of others. If the reviewer has specific suggestions, we
will consider them.
394: Checkpoint 2.1: Vague about what cannot be provided through
a source view.
Status: Awaiting discussion of proposal from Ian:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0043.html
443: Checkpoint 1.4: Device indepdent access to pointer (mouse)
specific events.
Status: The document currently requires emulation of
mouse-specific controls by virtue of our requirement that the
user must be able to do everything through the mouse.
Discussion:
a) Do we want to require the UA to repair device-specific
bindings specified by the author?
b) Do we have evidence that the ability to simulate mouse
events through the keyboard benefits the user?
444: Guideline 1 rationale needs clarification.
Proposed: Guideline 1 rationale needs editing based on our
change to checkpoint 1.1 (and not requiring that the user
enable mouse-only operation of the user agent in order to
conform). I believe that this is editorial and that the WG
doesn't need to spend time on it.
445: Checkpoint 1.3: What about systems that do not use the
keyboard at all, but provide accessibility solutions?
Proposed by IJ: UAAG 1.0 is designed to promote accessibility
of the Web for users with many types of disabilities. Keyboard
access is considered fundamental for this. This document is not
designed to promote the accessibility of specialized user
agents. Therefore no change to our requirements.
446: Checkpoint 6.1: Consider making the checkpoint scalable
(variable priority linked to WCAG).
Proposed by reviewer: Make checkpoint 6.1 a relative priority
checkpoint with respect to WCAG 1.0.
Status: We have already discussed this (refer to issue 111 [2])
and resolved to leave this a priority one checkpoint. The
rationale has been that if user agents don't implement
features, authors will never be able to use them. Therefore,
UAAG 1.0 must "lead".
[2] http://server.rehab.uiuc.edu/ua-issues/issues-linear.html#111
447: Conformance by default w.r.t. configuration requirements
Status: The reviewer's comment was that the document said that
the user agent should work by default. But since the document
requires lots of configurability to meet the different needs
of users, for which users should the document work by
default? The problematic sentence in the last call draft was
"Note: User agent developers are strongly encouraged to
design software that conforms in the default configuration."
That statement has been removed from the 13 January 2001
draft because it doesn't make sense: You don't "conform"
in the default configuration. You simply conform or you don't.
Therefore, unless there are objections or other comments. I
would consider this issue resolved.
448: Checkpoint 5.7: Is CSS read-only or read/write?
[This is checkpoint 5.9 in the 13 January 2001 draft.]
The reviewer's comment was "Is this section referring to
viewing the page or editing the page? Why would a user need to
access the CSS when viewing a document?"
Proposed IJ: Make this requirement read-only access.
- We already require that a conforming user agent
allow the user to select and apply user style sheets
(checkpoint 4.15 in 13 Jan 2001 draft).
- We require that the user be able to operate the user
agent through keyboard alone.
- Therefore, the user should be able to apply user style
sheets through the conforming UA's user interface. ATs
do not need to write to user style sheets through
an API.
Can people suggest a scenario where the AT would need to
write to the conforming user agent's user style sheet
through an API?
449: Create an executive summary for UAAG 1.0
Proposed by IJ: I agree that a 2-page summary of the
UAAG 1.0 as an appendix would be a useful addition.
Suggested Action editors: Write an executive summary.
450: If UA is implemented in Java, what system conventions should
it follow?
The reviewer's comment: "Several checkpoints refer to using
operating system conventions. What about a user agent that is
written in Java? In that case it is up to the virtual machine
to use the system conventions. Checkpoints that this might
affect: 1.3, 5.8, 8.6, 9.2. Also, section 3.2."
Comments from Al Gilman on this topic [3]:
"I believe that the UAAG as is should win out on this point.
That is to say, I believe that the UAAG never says simply
'follow OS conventions.'"
Status: Several checkpoints in the 13 January 2001 draft refer
only to OS conventions: 5.10, 5.11, 5.12, and 5.13.
Discussion: Should "OS conventions" be "system conventions"
(where system may include a programming environment) for
some or all of these checkpoints?
[3]
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0370.html
451: Checkpoint 2.6: Generalize to decorative content, not just
null alt
(Checkpoint 2.7 in 13 January 2001 draft)
Proposed by IJ: This proposal came from the WCAG WG, which is
working on requirements in WCAG 2.0. For the moment UAAG 1.0 is
based on WCAG 1.0, and this is a repair checkpoint for when the
author has not met the WCAG 1.0 requirement of providing an
equivalent. I propose that we not increase the scope of the
checkpoint in this version of the document, and consider a
broader checkpoint in a later version of UAAG that would be
based on WCAG 2.0. We have edited 2.6 to make it more format
based.
452: Checkpoint 2.2: Review minimal requirement (three options?)
The reviewer writes: You need to provide more options to
companies to address different types of situations and uses for
timing. Suggest a 3 option approach 1 - user can turn off all
timing OR 2 - user can adjust the timing to 5 times (or 10
times) the default setting. OR 3 - user is offered more time
and has at least 10 seconds to respond to offer.
Proposed by IJ: We resolved that the minimal requirement was
to pause the presentation since we could not determine
with certainty that fixed time delays (or multiples as the
reviewer suggests) would be useful. This sounds like a useful
configuration option for the techniques document.
453: Checkpoint 3.5: Generalize to "programmatic objects"
Status: For issue 364 [4], we resolved to include plug-ins.
Refer to Ian's request to review this resolution [5] since
plug-ins are not author-supplied.
Proposed by IJ: I don't know what "programmatic objects"
includes besides scripts, applets, and plug-ins. Why
exclude more? There are no other checkpoints that would use
the term "programmatic objects", so I'd prefer to be explicit
rather than abstract here unless there are other programmatic
objects that aren't covered.
[4] http://www.w3.org/WAI/UA/2000/11/minutes-20001116#issue-364
[5]
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0025.html
454: Checkpoints 3.6/3.7: Should these be Priority 1?
(These are the redirect checkpoints, currently P2
requirements.)
Discussion: If the user can't control redirects and refresh,
will access to some content be impossible?
Comment by IJ: I can see the reviewer's point. However, I am
reticent to raise the priorities at this stage.
455: Guideline 4: Change to "Ensure user control of
presentation"?
Proposed by IJ (Editorial):
- Move checkpoints 4.15-4.19 to Guideline 8. These seem
to be more about viewport, focus, and other UI behavior,
rather than styles.
- Change Guideline 4 title to "Ensure user control of
rendering and styles". I prefer not using the term
"presentation" since we use that term in the context
of multimedia presentation.
456: Editorial: Need to clarify in section 3.2 that we do not
mean system APIs.
The reviewer's comment: "It was my understanding of this
section that if a standard accessibility API does not exist for
an operating system, that the developer must create and use
their own. This would cause an AT developer to learn a
different API for each browser on a platform that did not have
an accessibility API."
Comment by IJ: Section 3.2 of that draft was about using
OS features as part of conformance. I don't understand the
reviewer's comment w.r.t. that section. I would note that
our current checkpoint 5.6 states:
"5.6 Implement standard accessibility APIs (e.g., of the
operating system and supported programming languages)."
This doesn't mean that if one doesn't exist you have to
invent your own; it wouldn't be standard.
457: Checkpoint 5.4: Ambiguity about what exactly required:
standard APIs only?
Checkpoint 5.4 is about read/write access to UI controls
through standard APIs.
Discussion: From Wendy's comment and after discussion with
Charles, it seems that this checkpoint is not clear: is access
to UI controls required even when there is no std API for doing
so?
458: Do link highlighting requirements apply to all zones of an
image map? What is required granularity?
Proposed IJ:
- User must be able to activate all links.
- For image maps specifically, I would argue that the
image map as a whole needs to be highlighted, but not
individual links.
--
Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 831 457-2842
Cell: +1 917 450-8783
Received on Monday, 15 January 2001 17:39:33 UTC