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

From: "Ian B. Jacobs" <ij@w3.org>
Subject: Responses to Tantek Çelik issues raised during third  last call of
UAAG 1.0
Date: Tue, Jul 3, 2001, 8:40 PM

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

Thank you for informing me of the resolutions.  I have very few remaining
comments, which you should consider under the same context as my original
informal review comments.

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

Glad to hear it, and glad to have been of some assistance.

> Please indicate before 19 July whether you are satisfied with the
> UAWG's resolutions

I do not think it is my place to be satisfied or not with the UAWG's
resolutions.  My intent was only to provide feedback from one implementor's
perspective which the UAWG was free to treat however it saw fit.  Hopefully
my comments were helpful to the UAWG's efforts.

> whether you think there has been a
> misunderstanding, or whether you wish to register an objection.

I am not registering any objections.

> 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

I have snipped out the issues and responses for which I had no further
informal comments.

> -----------------------------------------------
> 2) Issues you raised and responses
> -----------------------------------------------

...

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

Through the parenthetical comment alone '(e.g., through the various "on"
attributes)', it is possible to interpret pretty much every element as an
interactive element, in that it is possible in popular user agents to
dynamically attach the various "on" attributes to pretty much every element.

Due to the strongly worded final sentence, specifically "non-interactive
elements never become enabled elements", and since it is nearly impossible
to satisfy the "never" condition of that sentence given the above described
dynamic attribute attachment ability, the term "non-interactive element" is
nearly meaningless with the current definition.

I do not have a better suggestion to offer.  I am only pointing out the
limitation (presumably unintended) of the current text in the hopes that a
better alternative can be provided.

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

I briefly looked at the sample cases, and noted that most of them involve
the spawning of new windows ('window.open'), for which there is already a
requirement to allow disabling, and therefore, the argument could be made
that those sample cases are already "handled".

However, I did note that there are sample cases which do not involve
window.open, and allow me to add this additional related sample case which I
have seen:

  Similar to case 4E as documented in the above message, there are SELECT
elements with ONCHANGE handlers which immediately navigate to a new page,
which can make it difficult to "arrow key through" the various OPTIONs after
having focussed a SELECT element (since after even "arrow keying down" one
OPTION, the ONCHANGE event may fire which may result in an immediate page
navigation).


> ------------------------------------------------------------------
> 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 configuration file formats defined by W3C standards (e.g. a user style
sheet), it should be sufficient for the documentation to refer to the
appropriate W3C standard (e.g. CSS1) rather than have to explain the entire
W3C standard (e.g. a CSS1 tutorial).

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

This is reasonable enough.  But, in this case, what about alternate (or
primary) style sheets which are specified through HTTP LINK headers?  The
above definition would seem to imply that they are not part of the "document
source".  This seems contrary to intent.

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

I would like to point out that the reason I raised this issue is that some
very small text sizes are illegible (e.g. anything less than 9px
unsmoothed), and therefore, it may be preferable for a UA to set a "lower
bound" for the purposes of avoiding "unusable" configurations.

Is it a P2 (or P3) requirement to permit users to configure the size of text
to such illegible sizes?

Thanks,

Tantek

Received on Monday, 9 July 2001 05:13:10 UTC