- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Tue, 24 Sep 2002 15:34:16 -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
Ian, Regarding the proposed wording to address state information I believe it is important that we define the correct terminology as it crosssections accessibility infrastructure terminology. Note: we may want to extend content value to include text of a document element such as a text input field. I propose using the following definitions to the working group and then expanding on Ian's proposed changes to incorporate these definitions: Content state - Document content has a condition of being in a stage or form during its use known as its "state." The state of document content is ususally defined in discrete pre-defined values as should be known by assistive technologies designed to support the document. Examples of possible object states are: has focus, selected, visible, is selecteable, checked, focused, activated, pressed, expanded, collapsed, iconified, editable, multi-line, resizable, vertical, horizontal, collapsible, expandable, and enabled. Content selection - A collection of document content often selected by the user through some means. Content value - An amount assigned to document content. Some document may have an assigned value that may change during the course of its use. An example of a the use of content value is the currently value of an HTML selection object. 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: Richard Schwerdtfeger/Austin/IBM@IBMUS Sent by: cc: Philippe Le Hegaret <plh@w3.org>, Ray Whitmer w3c-wai-ua-reques <rayw@netscape.com>, w3c-wai-ua@w3.org, t@w3.org w3c-wai-ua-request@w3.org Subject: Re: Issue 545: In Guideline 6, clarify "content state" rather than "content" 09/23/2002 03:43 PM 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 Tuesday, 24 September 2002 16:38:00 UTC