Re: Issue 545: In Guideline 6, clarify "content state" rather than "content"

Ian,

You need to write a definition of "content state." Here is why: state could
mean the state of the entire document i.e. you could be falling down the
mutation event path which you don't want to do since we do not require the
DOM 2 or 3 event specification.

Also, the text in an input field is not always considered a change in
state. It is often considered a change in content by AT developers. State
in the AT community is often associated with the state of buttons. ... See
the AccessibleState definition in Java.

I'd recommend you limit things to the state of form elements and be
explicit. You can do this by writing a definition of what you mean by
content state in the guidelines.

I understand that we require access to all this stuff generically but since
we are round-a-bout referring to the HTML spec we should simply add a
definition of content state in our list of definitions.

Make sense?

Rich

Rich Schwerdtfeger
Senior Technical Staff Member
IBM Accessibility Center
Research Division
EMail/web: schwer@us.ibm.com

"Two roads diverged in a wood, and I -
I took the one less traveled by, and that has made all the difference.",
Frost



                                                                                                                                        
                      "Ian B. Jacobs"                                                                                                   
                      <ij@w3.org>              To:       w3c-wai-ua@w3.org, Ray Whitmer <rayw@netscape.com>                             
                      Sent by:                 cc:       Philippe Le Hegaret <plh@w3.org>                                               
                      w3c-wai-ua-reques        Subject:  Issue 545: In Guideline 6, clarify "content state" rather than "content"       
                      t@w3.org                                                                                                          
                                                                                                                                        
                                                                                                                                        
                      09/20/2002 04:23                                                                                                  
                      PM                                                                                                                
                                                                                                                                        
                                                                                                                                        




Ray, UAWG,

At yesterday's teleconference [1], we discussed the issue the DOM
WG raised (issue 545 [2]) about programmatic access to state
information. We resolved to:

   "Add a note to the Guidelines indicating that DOM 2 Core may not
   provide all information in an HTML Doc and that implementers
   should track the maturation of DOM 2 HTML Module which is
   expected to provide access to that information."

However, in light of further discussions with Jon Gunderson,
Philippe Le Hegaret, and Ray Whitmer, I wish to propose further
clarifications to checkpoints 6.1, 6.2, 6.3, and 6.6 that I think
address the issue more completely.

I believe that it has been the UAWG's intent to provide
information to this state information. Provision three of UAAG
1.0 [3] checkpoint 6.1 (Programmatic access to HTML/XML infoset)
reads:

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

Ray explained to me that, at least in the DOM WG's model, user
interactions (e.g., through form controls) do not modify the
content (i.e., the DOM tree). They change the "state" or "current
values" of the content. I believe (but am not absolutely certain)
that the XForms model is the same.

Therefore, I propose that we make two clarifications:

  a) When we talk about write access, we mean the ability
     to make the same state changes.
  b) We also require read access to state values, not just
     write access. I believe that such read access has been
     implied by the other "read" provisions in
     checkpoints 6.1 and 6.3.

<PROPOSAL>

  1) Modify checkpoint 6.1, provision 3 to read:

    <new>
    If the user can modify the state of HTML and XML content
    ("write access") through the user interface (e.g., through
    form controls), allow programmatic read access to
    current values, and allow for the same modifications
    programmatically.
    </new>

  2) Make the same kind of change to checkpoint 6.3 (for
     non-HTML/XML content), provision 1:

    <old>
     For content other than HTML and XML, provide structured
     programmatic read access to content, and write access to
     those parts of content that the user can modify through the
     user interface.
    </old>

    Split into two:

    <new provision 1>
     For content other than HTML and XML, provide structured
     programmatic read access to content.
    </new provision 1>

    <new provision 2>
    If the user can modify the state of content other than HTML
    and XML ("write access") through the user interface,
    allow programmatic read access to current values,
    and allow for the same modifications programmatically.
    </new provision 2>

  3) Add a Note to checkpoint 6.2 that reads:

    Note: "The DOM Level 2 Core Specification does not provide
    access to state (current values) required by checkpoint 6.1,
    provision 3. The DOM Level 2 HTML Module [DOM2HTML]
    is expected to provide access to this information.

  4) Clarify provision 1 of checkpoint 6.6:

    "Provide programmatic notification of changes to content,
    user agent user interface controls, selection, content
    focus, and user interface focus."

    to read:

    "Provide programmatic notification of changes to content and
    content state, user agent user interface controls, selection,
    content focus, and user interface focus."
</PROPOSAL>

I believe this proposal clarifies, but does not change
substantially, the intention of the document. I think it aligns
us more closely with the DOM WG's model.

Furthermore, this proposal satisfies part of the DOM WG's
suggestion:

   "These states might prove significant for an accessibility
   agent."

This proposal does not add a requirement to implement the DOM
HTML module because (1) DOM Level 1 HTML is broken, (2) DOM Level
2 HTML is not yet a W3C Recommendation, and (3) it is late in the
game for UAAG 1.0 to add such a requirement.

Finally, there is implementation experience for read/write access
to this state information, part of the DOM since "Level 0".

Please comment on this proposal. Thank you,

  _ Ian

[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2002JulSep/0141
[2] http://www.w3.org/WAI/UA/issues/issues-linear-lc4#545
[3] http://www.w3.org/TR/2002/WD-UAAG10-20020821/


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

Received on Monday, 23 September 2002 10:37:29 UTC