Responses to Tantek Çelik issues raised during third last call of UAAG 1.0


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:


Suggestions about usability:

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

  "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:
  Gregory Rosmaita:


2) Issues you raised and responses

Issue 474: Is configuration required when the user agent always/never
does something anyway?

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

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

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

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
    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?

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]:

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

We have included his example in the Techniques document.

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

Resolution: The UAWG agreed with the reviewer and generalized the
principle as follows in section 3.9 of the 22 June draft:

 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.

Issue 479: 4.10: For consistency, P1 for volume control of non-style 
content, P2 for rest

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.

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:

  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.

Issue 481: 9.2 and 9.6: Definition of "non-interactive element"

Resolved: The definitions of "interactive element" and
"non-interactive element" have been clarified as follows:

   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.

Issue 482: 9.5: Moving focus without triggering handlers may be wrong

  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:

Issue 483: 10.1: Clarify "purpose of a table"

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?

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?

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:

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

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

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)

Resolution: The checkpoint has been narrowed from "all changes
that affect accessibility" to "accessibility features, which is
defined as indicated by issue 486.

12.5 In each software release, document all changes that affect

<NEW 12.4>
Document changes from the previous version of the user agent to
accessibility features, including accessibility features of the user
</NEW 12.4>

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

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?

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:

 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

Issue 490: Minor clarifications

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:

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


  - 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

Issue summary: Is it a P1 requirement to allow configuration of very
small text sizes?


 - 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:

    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.

Ian Jacobs (
Cell:                    +1 917 450-8783

Received on Tuesday, 3 July 2001 23:43:29 UTC