- From: Ian B. Jacobs <ij@w3.org>
- Date: Tue, 03 Jul 2001 23:40:44 -0400
- To: tantek@cs.stanford.edu
- CC: w3c-wai-ua@w3.org
Tantek,
As you recall, you raised a number of issues about the 9 April 2001
last call draft of the UAAG 1.0 [1]. . At the time you made the
comments you said (to me) that you did not wish to make these formal
review comments (and that you trusted the UAWG to address them fully
<grin>). This formal response may not be strictly necessary, but I
would like to bring the resolutions to your attention, and invite your
comment. For the most part, the WG agreed with your suggestions and
incorporated them into the 22 June 2001 draft of the UAAG 1.0 [5]..
The UAWG has logged your issues in the Working Group's issues list [4].
Please indicate before 19 July whether you are satisfied with the
UAWG's resolutions, whether you think there has been a
misunderstanding, or whether you wish to register an objection. If
you do not think you can respond before 19 July, please let me know.
The Director will appreciate a response whether you agree with the
resolutions or not.
Below you will find:
1) More information follows about the process we are following.
2) A summary of the UAWG's responses to each of your issues.
Note: Where checkpoint numbers have changed, I indicate the mapping to
the 22 June 2001 draft.
Your issues were first logged in three separate emails:
Important issues:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0073
Clarifications:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0074
Suggestions about usability:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0075
The current response addresses both the important issues and the
clarifications (see issue 490). The suggestions of the third email
have also been adopted (with the exception of the style sheet for
black and white printing; we could use your help!). I encourage you to
take a look at the 22 June draft to see the results.
Thank you,
_ Ian
-----------------------------------------------
1) Process requirement to address last call issues
-----------------------------------------------
Per section 5.2.3 [2] of the 8 February 2001 Process Document, in
order for the UAAG 1.0 to advance to the next state (Candidate
Recommendation), the Working Group must "formally address all
issues raised during the Last Call review period (possibly
modifying the technical report)." Section 4.1.2 of the Process
Document [3] sets expectations about what constitutes a formal
response:
"In the context of this document, a Working Group has formally
addressed an issue when the Chair can show (archived) evidence
of having sent a response to the party who raised the
issue. This response should include the Working Group's
resolution and should ask the party who raised the issue to
reply with an indication of whether the resolution reverses the
initial objection."
If you feel that the response is based on a misunderstanding of
the original issue, you are encouraged to restate and clarify the
issue until there is agreement about the issue, so that the
Working Group may prepare its substantive response.
If the response shows understanding of the original issue but
does not satisfy the reviewer, you may register a formal
objection with the Working Group that will be carried forward
with the relevant deliverables. There are currently two
objections that the UAWG will carry forward with the document in
a request to advance to Candidate Recommendation. Each concerns
the priority of checkpoint 12.1, one that the priority should be
lowered, the other that the priority should be raised. There are
additional supporters of each position.
Phill Jenkins:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0528
Gregory Rosmaita:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0553
[1] http://www.w3.org/TR/2001/WD-UAAG10-20010409
[2] http://www.w3.org/Consortium/Process-20010208/tr.html#RecsCR
[3] http://www.w3.org/Consortium/Process-20010208/groups.html#WGVotes
[4] http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3
[5] http://www.w3.org/TR/2001/WD-UAAG10-20010622/
-----------------------------------------------
2) Issues you raised and responses
-----------------------------------------------
------------------------------------------------------------------
Issue 474: Is configuration required when the user agent always/never
does something anyway?
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#474
------------------------------------------------------------------
Resolution: For most of the checkpoints, the configuration option is
as important as the feature that's being configured. However, the WG
agreed after examining all of the checkpoints, that for five of them,
the configuration part of the requirement was not the same priority as
the feature being required. Therefore, the WG decided that it is
sufficient to satisfy checkpoints 3.3, 5.1, 5.3, 5.5, and 5.6 without
configuration as long as the user agent provides the accessibility
functionality.
------------------------------------------------------------------
Issue 475: Checkpoint 2.9: Does this checkpoint mean auto rendering
of all content in same viewport?
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#475
------------------------------------------------------------------
Response: No. The WG agrees with the reviewer and has revised the
checkpoint in the 22 June draft to read:
"Allow configuration to render all conditional content
automatically. The user agent is not required to render all
conditional content at the same time in a single viewport."
------------------------------------------------------------------
Issue 476: Definition: rendered content/viewport circular
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#476
------------------------------------------------------------------
Resolution: The definitions of rendered content and viewport have
been fixed and are no longer circular:
1) Rendered content is the part of content that the user agent makes
available to the user's senses of sight and hearing (and only those
senses for the purposes of this document). Any content that causes
an effect that may be perceived through these senses constitutes
rendered content. This includes text characters, images, style
sheets, scripts, and anything else in content that, once processed,
may be perceived through sight and hearing.
2) The user agent renders content through one or more
viewports. Viewports include windows, frames, pieces of paper,
loudspeakers, virtual magnifying glasses, etc. A viewport may
contain
another viewport (e.g., nested frames). User interface controls such
as prompts, menus, alerts, etc. are not viewports.
------------------------------------------------------------------
Issue 477: Checkpoint 2.10: Does this also include script (written
language), or just natural language?
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#477
------------------------------------------------------------------
Resolution: After consultation with the I18N Working Group, the UAWG
clarified that this checkpoint does indeed include written language as
well as natural language. Martin Duerst wrote [6]:
<BLOCKQUOTE>
My understanding is that a script is just a means of supporting
a language when using written rendering. If e.g. the Cyrillic
script is not supported, then this means that visual rendering
of Russian, Ukrainian,... is not supported.
So I think script is subsumed in the checkpoint as you have it
now. It may be the case that e.g. there is a text-to-speech
module for Russian. In that case, it would be inadequate to
say 'Russian is supported' or 'Russian is not supported';
one would have to say 'Russian visual rendering is not
supported, Russian audible rendering is supported'.
</BLOCKQUOTE>
[6] http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0158
We have included his example in the Techniques document.
------------------------------------------------------------------
Issue 478: 4.9: Clarify that global volume control can cover content
and UI controls
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#478
------------------------------------------------------------------
Resolution: The UAWG agreed with the reviewer and generalized the
principle as follows in section 3.9 of the 22 June draft:
<BLOCKQUOTE>
The user agent may satisfy a "content only" requirement with a
mechanism that also involves user agent features. For instance, to
satisfy checkpoint 4.9, the user agent may provide a single control
for all volume (including content and user interface
features). Similarly, to satisfy checkpoint 3.3, the user agent may
offer a single configuration that turns off blinking in both content
and the user interface.
</BLOCKQUOTE>
------------------------------------------------------------------
Issue 479: 4.10: For consistency, P1 for volume control of non-style
content, P2 for rest
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#479
------------------------------------------------------------------
Resolution: The UAWG agreed. The 22 June draft includes two
checkpoints (4.10 and 4.11) that reflect the P1/P2 split.
------------------------------------------------------------------
Issue 480: 6.4: Security concerns about write access to controls.
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#480
------------------------------------------------------------------
Issue summary: Checkpoint 6.4 requires universal write access, which
may cause security problems.
Resolution: The WG agreed, and limited write access to that which can
be done through the user interface. The revised checkpoint 6.4,
provision 2 includes the change:
<BLOCKQUOTE>
2.Provide programmatic write access for those controls that the
user can modify through the user interface. For security
reasons, user agents are not required to allow instructions in
content to modify user agent user interface controls.
</BLOCKQUOTE>
------------------------------------------------------------------
Issue 481: 9.2 and 9.6: Definition of "non-interactive element"
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#481
------------------------------------------------------------------
Resolved: The definitions of "interactive element" and
"non-interactive element" have been clarified as follows:
<BLOCKQUOTE>
An interactive element is piece of content that, by specification,
may have associated behaviors to be executed or carried out as a
result of user or programmatic interaction. For instance, the
interactive elements of HTML 4 [HTML4] include: links, image maps,
form elements, elements with a value for the "longdesc" attribute,
and elements with event handlers explicitly associated with them
(e.g., through the various "on" attributes). The role of an element
as an interactive element is subject to applicability. A
non-interactive element is an element that, by specification, does
not have associated behaviors. The expectation of this document is
that interactive elements become enabled elements in some sessions,
and non-interactive elements never become enabled elements.
</BLOCKQUOTE>
------------------------------------------------------------------
Issue 482: 9.5: Moving focus without triggering handlers may be wrong
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#482
------------------------------------------------------------------
Resolution:
a) Some functionalities required by UAAG 1.0 may not guarantee
access in all cases, and may even break content in some cases.
However, without them, access may be impossible, and with them,
access may be possible for more than rare content. The
configuration requirements mean that a user can turn off the
feature if it makes content more inaccessible.
b) The set of events this checkpoint refers to in HTML includes
onfocus, onblur, and onchange.
c) The UAWG has come up with some sample cases of destructive
event handlers:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0204
------------------------------------------------------------------
Issue 483: 10.1: Clarify "purpose of a table"
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#483
------------------------------------------------------------------
Resolution: The checkpoint has been clarified as follows:
"Make available to the user the purpose of each table (e.g., as
expressed in a summary or table caption) and the relationships among
the table cells and headers."
More examples are provided in the Techniques document.
------------------------------------------------------------------
Issue 484: Black, white, and color: does graying rely on color?
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#484
------------------------------------------------------------------
Resolution: Black, white, and greys are colors, and therefore are
subject to the color requirements of the document. Users may have
"contrast" disabilities and not be able to distinguish shades of grey.
Many colors map to the same shade of grey. A color-blind person may
have a different perception of some of these greys.
------------------------------------------------------------------
Issue 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
------------------------------------------------------------------
Resolution: The UAWG agrees that for some checkpoints, init and
configuration files may be used to satisfy the requirements.
In particular, checkpoints 10.2, 10.4, and 10.7.
However, the UAWG recommends that these features *also* be
configurable through the user interface.
If editable configuration files are used, the documentation should
explain the syntax etc. of the configuration files.
Section 3.9 now includes text about configuration requirements:
<BLOCKQUOTE>
The user agent may satisfy the configuration requirements of this
document through configuration files (e.g., profiles, initialization
files, themes, etc.). For instance, style sheets might be used as a
mechanism to satisfy the highlight and configuration requirements of
checkpoints 10.2 and 10.4. Any functionality that is configurable
through a configuration file should also be configurable through the
user agent user interface. Furthermore, if configuration files may
be edited by hand, the user agent documentation should explain the
configuration file format.
For some of the checkpoints in this document (checkpoint 3.3,
checkpoint 5.1, checkpoint 5.3, checkpoint 5.5, checkpoint 5.6),
configuration is preferred, but not required to satisfy the
checkpoint in some circumstances. For other checkpoints, the
configuration requirement is considered as important as the
functionality being configured.
Since this document allows conformance by multiple software
components (e.g., a browser, a media player, and several plug-ins),
there are likely to be times when, to satisfy the configuration
requirements of the document, each component has to provide for
configuration independently. To make configuration easier for the
user, components should share and inherit configurations (including
from the operating environment).
</BLOCKQUOTE>
------------------------------------------------------------------
Issue 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
------------------------------------------------------------------
Resolution: The definition has been clarified for checkpoints 8.1,
12.2, 12.4, and 12.5.
Checkpoint 8.1:
Implement the accessibility features of specifications (markup
languages, style sheet languages, metadata languages, graphics
formats, etc.). For the purposes of this checkpoint, an
accessibility feature is either one identified as such, or one
that allows the author to satisfy any requirement of the "Web
Content Accessibility Guidelines 1.0" [WCAG10].
Checkpoint 12.2 (and 12.4, 12.5):
For the purposes of this checkpoint, a user agent feature that
benefits accessibility is one implemented to satisfy the
requirements of this document (including the requirements of
checkpoints 8.1 and 7.3).
------------------------------------------------------------------
Issue 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
------------------------------------------------------------------
Resolution: The checkpoint has been narrowed from "all changes
that affect accessibility" to "accessibility features, which is
defined as indicated by issue 486.
<OLD>
12.5 In each software release, document all changes that affect
accessibility.
</OLD>
<NEW 12.4>
Document changes from the previous version of the user agent to
accessibility features, including accessibility features of the user
interface.
</NEW 12.4>
------------------------------------------------------------------
Issue 488: Glossary: Is the glossary normative or informative?
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#488
------------------------------------------------------------------
Resolution: The glossary does not make any additional requirements
than the checkpoints, except in that some of the terms are "leaves" of
the requirements. In this sense, these terms are normative, so we have
marked the entire glossary as normative (even though much of the
description has no bearing on conformance).
------------------------------------------------------------------
Issue 489: Does "document source" include HTTP headers?
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#489
------------------------------------------------------------------
Resolution: The UAWG defines the term "document source" to be the
payload of a request for a resource (and thus it excludes HTTP
headers, for example). However, document source is prior to
repair, as the definitions indicate:
<BLOCKQUOTE>
In this document, the term "document source" refers to the data that
the user agent receives as the direct result of a request for a Web
resource (e.g., as the result of an HTTP/1.1 [RFC2616] "GET", or as
the result of viewing a resource on the local file system). The
document source generally refers to the "payload" of the user agent's
request, and doesn't generally include information exchanged as part
of the transfer protocol. The document source is data that is prior
to any repair by the user agent (e.g., prior to repairing invalid
markup). "Text source" refers to document source that is composed of
text.
</BLOCKQUOTE>
------------------------------------------------------------------
Issue 490: Minor clarifications
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#490
------------------------------------------------------------------
Resolution: The WG accepted all of the proposed clarifications,
with some additional clarifications of its own. Please refer to the
minutes of the 24 May teleconference for details:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0211
------------------------------------------------------------------
Issue 491: Selection/Focus: Require focus for enabled elements
only. Don't require selection. Clarify that "user interface focus" is
not related to viewports (but instead to other controls of the user
interface).
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#491
------------------------------------------------------------------
Resolutions:
- UAAG 1.0 requires implementation of a content focus, but does
not require implementation of a selection mechanism. However,
if the UA does implement a selection mechanism, the selection
requirements must be satisified for conformance.
- There is no requirement to be able to move focus to a viewport
where there is no interactivity possible.
- The WG made other clarifications about selection and focus in
checkpoints 9.1, 9.2, 9.3, 9.4, 10.2, and the definitions
of selection and focus.
------------------------------------------------------------------
Issue 512: Checkpoint 4.1: Range of text sizes
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#512
------------------------------------------------------------------
Issue summary: Is it a P1 requirement to allow configuration of very
small text sizes?
Resolution:
- The UAWG agrees that the intent of this checkpoint is to allow the
user to choose large, not small, text sizes.
- However, after consultation with other Working Groups, the UAWG
concluded that, in light of internationalization issues (and others),
the WG could not come up with a lower bound on the requirement
with any confidence.
- Therefore, the WG resolved to leave the checkpoint as is with a
note in the Techniques document:
<BLOCKQUOTE>
The primary intention of this checkpoint is to allow users with
low vision to increase the size of text. Full configurability
includes the choice of (very) small text sizes that may be
available, though this is not considered by the User Agent
Accessibility Guidelines Working Group to be part of the priority
1 requirement. This checkpoint does not include a "lower bound"
(above which text sizes would be required) because of how users'
needs may vary across writing systems and hardware.
</BLOCKQUOTE>
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Cell: +1 917 450-8783
Received on Tuesday, 3 July 2001 23:43:29 UTC