UAWG response to DOM WG review of UAAG 1.0

Ray,

On behalf of the UAWG, I would like to thank you for the DOM WG
review [1] of UAAG 1.0. Please review this email and let us know
whether you are satisfied with how the UAWG proposes to address
your issue. A response before 3 October would be appreciated; let
us know if you require extra time.

Thank you,

  - Ian

===============================

You wrote:

   We believe that 6.5 should require the HTML DOM in addition to
   requiring the core DOM.  The reason for this is that there are
   certain current values or states of forms that are not
   available through the core DOM, but only through the HTML DOM.
   This might be, for example, the value in a text field after the
   user has typed in it.  These states might prove significant for
   an accessibility agent.  The core DOM does not deal with the
   state of the presentation, but only the content that was
   actually in the info set of the document, and the DOM WG never
   continued work on the Views module to provide alternative ways
   to access this sort of information.

The UAWG considered this issue (#545 [2]) at two teleconferences
and agrees with the comment that the current values or states
must be available through an API. The following provision
of checkpoint 6.1 [3] is intended to cover this case:

    "If the user can modify HTML and XML content ("write access")
    through the user interface (e.g., through form controls),
    allow for the same modifications programmatically."

As written, the provision (incorrectly) assumed that changes
through the user interface would be stored in the DOM. The UAWG
proposes to modify the provision to state the requirement more
abstractly, rather than assume a particular implementation (that
the DOM is modified when the user changes these states).

In light of your comments, I wrote a proposal [4] to clarify that
the provision refers to state/current values. The UAWG accepted
this proposal with a few additions:

  a) The same reasoning applies to user interface controls --
     they have current states and values -- and therefore
     checkpoint 6.5 should be edited similarly.

  b) We will use the following terms:

        current content state, current content value.
        current control state, current control value.

  c) We will give some examples (e.g., "checked" is a content
     state, while a textarea element would have a current content
     value of some string).

I note that the proposal [4] also suggests that we add a note
that this information is available through the DOM HTML module,
even if we are not requiring it for conformance to UAAG 1.0.

This UAWG decision was made at the 26 Sep 2002 teleconf [5].

[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2002JulSep/0136
[2] http://www.w3.org/WAI/UA/issues/issues-linear-lc4.html#545
[3] 
http://www.w3.org/TR/2002/WD-UAAG10-20020821/guidelines#tech-infoset-access
[4] http://lists.w3.org/Archives/Public/w3c-wai-ua/2002JulSep/0143
[5] http://lists.w3.org/Archives/Public/w3c-wai-ua/2002JulSep/0173

-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447

Received on Friday, 27 September 2002 21:14:53 UTC