- From: Ian B. Jacobs <ij@w3.org>
- Date: Mon, 09 Jul 2001 08:25:53 -0400
- To: Tantek Celik <tantek@cs.stanford.edu>
- CC: w3c-wai-ua@w3.org
Hi Tantek,
My replies preceded by IJ:.
Tantek Celik wrote:
>
[snip]
> 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.
IJ: They have been very helpful.
> > whether you think there has been a
> > misunderstanding, or whether you wish to register an objection.
>
> I am not registering any objections.
IJ: Ok
[snip]
> > ------------------------------------------------------------------
> > 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.
IJ: What is "enabled" ultimately depends on the user agent. The user
agent
developer implements a specification, but may choose to do more or less
than the specification. In the case of HTML, the "on" attributes are not
defined for every element (far from it). However, user agents may allow
authors to specify these attributes for almost every element. In this
case,
the developer is not implementing the specification correctly (a
separate
issue), and in doing so is increasing the amount of interactivity the
author can specify. There is no reason users with disabilities should
not
have access to these enabled elements, even if they are not
"interactive"
because they are not defined by specification to be potentially
interactive.
Thus, we separate the definitions of "interactive" (by spec) and
enabled.
Our requirements refer only to enabled elements - those that are live
in a given session. Our *expectation* is described in the last sentence,
but if user agent developers turn non-interactive elements into
enabled elements in some sessions, our requirements are that the user
agent provide access to them.
> > ------------------------------------------------------------------
> > 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).
IJ: I would go further and say that the UA should either explain the
format or refer to some document that does (for any format).
> > ------------------------------------------------------------------
> > 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.
IJ: I agree, as we would like to have access to these alternate style
sheets and expect to for LINK elements. The "good news" (and I learned
this by surprise some time ago) is that the Link header field is not
part of HTTP/1.1. Refer to section 19.6.3 [1]:
"The Alternates, Content-Version, Derived-From, Link, URI, Public and
Content-Base header fields were defined in previous versions of
this specification, but not commonly implemented. See RFC 2068
[33]."
There's no link header in section 14 ("Header Field Definitions").
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.6.3
> > ------------------------------------------------------------------
> > 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?
IJ: It is still a P1 requirement if this illegible size is part of the
range of font sizes offered by the operating environment. We don't make
the small size requirement directly, only require access to the range
already
made available by the operating environment. As mentioned above, while
we
tried to find a lower bound because we agreed with your sentiment, we
could
not do so readily in an I18N context.
- Ian
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Cell: +1 917 450-8783
Received on Monday, 9 July 2001 08:29:04 UTC