- From: Ian B. Jacobs <ij@w3.org>
- Date: Mon, 23 Sep 2002 13:43:39 -0700
- To: Richard Schwerdtfeger <schwer@us.ibm.com>
- CC: Philippe Le Hegaret <plh@w3.org>, Ray Whitmer <rayw@netscape.com>, w3c-wai-ua@w3.org, w3c-wai-ua-request@w3.org
Richard Schwerdtfeger wrote: > 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. 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. ... 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. 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 16:47:56 UTC