W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 2002

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

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Mon, 23 Sep 2002 16:05:19 -0500
To: "Ian B. Jacobs" <ij@w3.org>
Cc: Philippe Le Hegaret <plh@w3.org>, Ray Whitmer <rayw@netscape.com>, w3c-wai-ua@w3.org, w3c-wai-ua-request@w3.org
Message-ID: <OF330C42CE.49556696-ON86256C3D.00725AD8@boulder.ibm.com>

>Could you start by proposing some text? We can discuss this
>at Thursday's call.

How did I know you were going to say that?

Do I limit the definition to form controls?


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

                      "Ian B. Jacobs"                                                                                                   
                      <ij@w3.org>              To:       Richard Schwerdtfeger/Austin/IBM@IBMUS                                         
                                               cc:       Philippe Le Hegaret <plh@w3.org>, Ray Whitmer <rayw@netscape.com>,             
                      09/23/2002 03:43          w3c-wai-ua@w3.org, w3c-wai-ua-request@w3.org                                            
                      PM                       Subject:  Re: Issue 545: In Guideline 6, clarify "content state" rather than "content"   

Richard Schwerdtfeger wrote:
> Ian,
> You need to write a definition of "content state." Here is why: state
> 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
> 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.

Ah, but the DOM WG considers this a change in state, not a change
in the DOM tree.

Our intent has been to provide access (read + write) to changes
in form controls (or analogous things that can be changed through
the UI). Whether we call that 'content' or 'state' doesn't really
matter as long as the capability is there. However, if we call
it 'content' (as we currently do in the last call draft), that's
inconsistent with the DOM model. Hence the proposal to shift
to 'state'.

 > State
> in the AT community is often associated with the state of buttons. ...
> 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.

Could you start by proposing some text? We can discuss this
at Thursday's call.

Thanks Rich!

  - Ian

P.S. I'm in another meeting until Thursday...

Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447
Received on Monday, 23 September 2002 17:05:34 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:32 UTC