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