W3C

State Meta Information for XHTML Elements

W3C Working Draft 28 May 2004

This version:
1.0
Editor:
Richard Schwerdfeger <schwer@us.ibm.com>
Aaron Leventhal <aleventh@us.ibm.com>

Abstract

Dynamic web content, like graphical user interfaces is required to maintain state information. This is realized through the use of declarative state information implied in form elements such as focus, invalid, and enabled. This state information is limited to forms and in some cases anchors.  Traditional accessibility architecture includes state information capable of addressing the state of GUI elements found on a traditional desktop. Authors of dynamic web content are accustomed to creating widgets that appear like desktop components but are implemented using combinations: of HTML or XHTML flexible constructs such as DIVs, SPANs; style sheets; and JavaScript to generate user interface changes in response to user interaction. All accessibility frameworks today use state information to provide alternative access solutions, such as a screen reader, in much the same way we need the state information to render content with different style sheet properties. In order to provide true access, this information must be provided in a standard way to allow for for interoperability.

This working draft:

This specification is part of a set designed to create an accessible infrastructure for dynamic web applications as defined by the Dynamic Web Content Task  Force Roadmap.

Status of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.

This document is the first Working Draft of this specification. It should in no way be considered stable, and should not be normatively referenced for any purposes whatsoever. This version includes an early implementation of Meta State Information. This document is a deliverable in the Dynamic Web Content Task Force Roadmap for addressing web content accessibility. This document does not address state Change events which  need to be generated to maintain interoperability with the assistive technology. That issue will be worked independently of the evolution of this specification as will other elements of the roadmap. Those issues should, of course, be resolved as quickly as possible, and the resolution will be reflected in a future draft. Finally, the working group has started to resolve many of the issues that have been submitted by the public. If your particular issue has not yet been addressed, please be patient - there are many issues, and some are more complex than others.

The information provided by the declarative states in forms is incomplete in its ability to support accessibility. JavaScript is used on over 50% of all web sites today. JavaScript authors create content which consists largely of custom UI widgets constructed from existing HTML widgets. These widgets may appear as tree widgets, pop-up windows, or even more complex widgets such as a spreadsheet. In the case of a Tree widget there is no mechanism to convey state information as to whether an expandable list is collapsed or expanded. Figure 1.0 illustrates the need for state information as part of the total solution needed by adaptive technology.

It is essential that the author be allowed to provide semantic state meta data in these widgets to adaptive technology through the combination of author supplied state properties and declarative state attributes stored by the user agent.

In short, HTML needs a mechanism for dynamic web content to allow the author and user agent to provide state information encompassing the possible semantic state information provided by the accessibility API on each operating system platform.

This document has been produced by the W3C HTML Working Group (members only) as part of the W3C HTML Activity. The goals of the HTML Working Group are discussed in the HTML Working Group charter.

Public discussion of XHTML takes place on www-html@w3.org (archive). To subscribe send an email to www-html-request@w3.org with the word subscribe in the subject line.

Please report errors in this document to www-html-editor@w3.org (archive).

At the time of publication, the Working Group believed there were no patent disclosures relevant to this specification. A current list of patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page.

Table of Contents


1 Introduction

This section is informative.

1.1 What is state meta information?

State meta information is used by applications and assistive technologies to used to determine the state of UI widgets. In the case of a web page it may be declarative as a function of particular elements or it may be an attribute which is configurable by the page author. In the case of a tree widget, it is important to know whether a tree element is expanded or collapsed. This is important for the web application generating the widget and for an assistive technology, such as a screen reader, wishing to provide an alternative rendering. Figure 1.0 illustrates state information as part of the entire accessibility contract

Figure 1.0 Accessibility Interoperability at a DOM Node

Accessibility infomation mapped to an element in the DOM

Figure 1.0 illustrates a typical DOM node. On the DOM node, data which should include semantic meta data, is separated from presentation. Placed within the DOM node and the assistive technology is a box containing the contract provided by the user agent to the assistive technology. This data includes typical accessibility information found in the accessibility API for many of our accessible platforms for GUIs (role, state, caret, selection, event notification, parent/child information, relationship, and descriptions).

1.2 Support for HTML and XHTML

The state meta information should be applicable to HTML and XHTML through the definition of an alternative name space which would be incorporated into a web page.

1.3 Design Aims

In designing state meta information, a number of design aims were kept in mind to help direct the design. These included:
  • Define the appropriate browser implementation of state meta information management
  • Define what state meta information may be controlled by the author
  • Support standard accessibility API on major desktop platforms
  • Define the mappings to the accessible state information on each platform
  • Support internationalization
  • Support device independence: new devices coming on line, such as telephones, PDAs, tablets, televisions and so on mean that it is imperative to have a design that allows you to author once and render in different ways on different devices, rather than authoring new versions of the document for each type of device.
  • Improve the accessibility of dynamic content such as that generated by script.

2. Terms and Definitions

This section is informative.

While some terms are defined in place, the following definitions are used throughout this document. Familiarity with the W3C XML 1.0 Recommendation [XML] is highly recommended.

accessibility API
This is the accessibility API for a given platform. Examples of this are the Java Accessibility API (JAPI), Microsoft  Active Accessibility (MSAA), and the Gnome  Accessibility Toolkit (ATK).
managed state
managed states are state attributes managed by the user agent as a declared attribute of a specific element. Often these states have corresponding CSS pseudo classes  to reflect necessary style changes.
unmanaged state
these are states which are represented as document element attribute meta information which are set by page author.

3. State Meta Information

State meta information is divided into managed and unmanaged states. For some well-defined document elements, states are predefined and managed. This is found in HTML anchors, HTML form elements, and XForms elements. Custom widgets, such as those created by Java Script must use existing, flexible document elements for which state information must be supplied by the author.  Examples of this are DIV and SPAN.

The definition of state meta information is designed to map to the accessibility API on those platforms which support an accessibility API.

Each platform accessibility API has a set of accessible state attributes. In HTML some of those attributes will be set directly in the DOM as attributes which then would be mapped to the accessibility API to maintain interoperability with assistive technologies. Other attributes are managed by the user agent. Others, in the case of XForms, will be derived from XForms bindings to instance data.

In order to improve the performance of user agents,  the W3C is defining a Role specification for XHTML 2 which may be also applied to XHTML 1.1. The purpose of role is to introduce semantics to document elements by defining what a document element is for. When the author uses these predefined roles some state information will be managed by the user agent without the need for the author to generate those state attributes.

State information must be accompanied by corresponding role information. In HTML this will be in the form of  a role attribute as defined by Meta-Information Role to XHTML elements..

3.1 Unmanaged state attributes

The following table lists the new state attributes which may not be managed and require the author to have control over.

In HTML, XHTML 1.0, and XHTML 1.1 all of these state attributes  apply to elements within the body tag. Selfvoicing is limited to object, body, iframe, frame due to complexity imposed on assistive technologies.


Need to support Availability in Standard Markup today Applicability User Agent mapping
expanded

Definition: indicates if the children of the element are expanded such as in a tree widget.

values: true, false

HTML, XHTML 1.0-1.1

If set to false :

MSAA:STATE_SYSTEM_COLLAPSED
ATK: ATK_STATE_EXPANDABLE

If set to true:

MSAA:STATE_SYSTEM_EXPANDED
ATK:ATK_STATE_EXPANDED

*Should the user agent map this to true when it's children are not hidden and expandable=true?
disabled

Definition: When set a widget, this boolean attribute disables the widget for user input.

values: true

Limited to HTML form input tags
<input> disabled="true"

HTML, XHTML 1.0-1.1

MSAA:STATE_SYSTEM_UNAVAILABLE
ATK:ATK_STATE_DISABLED

Should also remove element from tab order, make it not focusable, change appearance (grayed out, etc.), and prevent it from being interacted with.

focusable


Definition: Capable of receiving user input focus.

values:  "traverse", "nontraverse"

traverse: Means navigable through the keyboard tabbing or navigation sequencing mechanism. The presence of TABINDEX on an element indicates that focusable="traverse"

nontraverse: Means not navigable. Should be accessible through some access key mechanism.


HTML, XHTML 1.0-1.1

MSAA:STATE_SYSTEM_FOCUSABLE
ATK:ATK_STATE_FOCUSABLE

For the actual state user agent must provide this information through the DOM or some specialized API.

hidden

Definition: The author has asked that this element and its children are hidden from view. The element is and its children are programmatically hidden. For example, menu items are programmatically hidden until a user activates the menu.

Value: true
Currently provided through a style sheet:

style="display:none"

Defined in XForms by a lack of binding.
HTML, XHTML 1.0-1.1

MSAA:
STATE_SYSTEM_INVISIBLE: true if hidden=true; Otherwise false

ATK:
ATK_STATE_VISIBLE : false if hidden=true.
Otherwise false

Elements with this state should not be made available to users.

invalid


Definition: An element is invalid with respect to these attribute values:

  • "invalid" with respect to data validity semantics defined by a different specification (e.g. [XFORMS10]). This includes conditions such as precision errors and type mismatches. An element which lacks data validity semantics is neither valid nor invalid. This is different from an element which otherwise has no constraints. Such an element would always be :valid.
  • "out-of-range" due to range limitations. An element is out-of-range when the value that the element is bound to is out of range of the elements constraints. An element that lacks data range limits or is not a form control is neither :in-range nor :out-of-range. E.g. a slider element with a value of 11 presented as a slider control that only represents the values from 1-10 is :out-of-range.
  • "required" and the corresponding data has not been provided.

An element which lacks data validity semantics is neither :valid nor :invalid.

 the bound instance data constraints. An element which lacks data validity semantics is neither :valid nor :invalid. This is different from an element which otherwise has no constraints. Such an element would always be valid.


Invalid  (same as out-of-range)
values: "invalid","out-of-range", "required"

Provided in XForms  today.
HTML, XHTML 1.0-1.1

ATK:ATK_STATE_INVALID
MSAA: no mapping

For the actual state user agent must provide this information through the DOM or some specialized API.
For user agents using XForms, this information must provided through the DOM or a specialized API.


*It would also be good to expose what the range and type actually is such as providing the minimum and maximum range where it cannot be determined from a corresponding schema and exposed data model.

Additionally, assistive technologies should extend their API to support the reasons why elements are invalid as is done by XForms.

moveable

Definition: Indicates that the element may be moved.

values: "true"


HTML, XHTML 1.0-1.1

XForms:  UI elements
MSAA:STATE_SYSTEM_MOVEABLE
Non-Windows systems: Should be made available through the DOM or a specialized API.

User agent should provide a mechanism for moving the item through the keyboard, mouse, or programmatically to address device independence.

multiple

Definition: This means that that a container element manages the selection of multiple descendants based on user input.

values: "true"
html: <select multiple="true">

XForms: <select>, <repeat>

HTML, XHTML 1.0-1.1

Multiselectable applies to container elements of selectable descendant elements. This could be done with scripting using the following:

MSAA:STATE_SYSTEM_EXTSELECTABLE
ATK:ATK_STATE_MULTISELECTABLE
optional

Definition: An element is optional if the value for it is not required and the data it manages is used to enter forms data. An element which is not used to enter data into a form is neither required or optional.

values: "true"
Provided in XForms  today. (based on data model) HTML, XHTML 1.0-1.1

Non-Form elements may be used to inject form data.

XForms: This attribute is not applicable to XForms. This is determined from the XForms model.

MSAA, ATK - There is no mapping.


User agent must make available through the DOM or a specialized API.

Note: While optional could be combined with required this is kept to be consistent with CSS3 pseudo classes and XForms.

readonly

Definition: If false, it specifies that the element may not be modified by the user. If false, this is a read-write element.  Elements without this attribute are considered readonly unless overriden by the user agent such as in the case of designmode.

values:"true", "false"
HTML: readonly="true" for form elements

Provided in XForms today.  (based on data model)
HTML, XHTML 1.0-1.1

Non-Form elements may be used to inject form data.

XForms: This attribute is not applicable to XForms. This is determined from the XForms model.

MSAA:STATE_SYSTEM_READONLY
ATK:ATK_STATE_READONLY=inverse of readonly

The user agent should not allow value to be changed in the case that this is set to true on an element.

required

Definition: An element is required if it the value for it is required and the data it manages is used to enter forms data. Otherwise it is not required. An element which is not used to enter data into a form is neither required or optional.

values: "true"
XForms  (based on data model)

HTML, XHTML 1.0-1.1

Non-Form elements may be used to inject form data.

XForms: This attribute is not applicable to XForms. This is determined from the XForms model.

MSAA,ATK - There is no mapping.


User agent must make available through the DOM or a specialized API.

Note: While optional could be combined with required this is kept to be consistent with CSS3 pseudo classes and XForms.

resizeable

Definition: Indicates that the element may be resized. This is important for alternative input solutons

values: "true"

HTML, XHTML 1.0-1.1

XForms:  UI elements
MSAA:STATE_SYSTEM_SIZEABLE
ATK:ATK_STATE_RESIZEABLE

User agent should provide a mechanism for resizing the item through the keyboard, mouse, or programmatically to address device independence.
secret

Definition: Indicates that the value should not be echoed as it is entered.

values: "true"
XForms: see <secret>
HTML, XHTML 1.0-1.1
MSAA:STATE_SYSTEM_PROTECTED
ATK:ATK_STATE_SECRET
selected

Definition: This means that this element is a descendant of a container element which manages its selection and it is selected by the user.

values: "true"
applies to HTML Form element <option>

XForms: N/A


HTML, XHTML 1.0-1.1

Non-Form elements may be used to inject form data.

XForms: This attribute is not applicable to XForms. 
MSAA:STATE_SYSTEM_SELECTED
ATK:ATK_STATE_SELECTED
selectable

Definition: This means that this element is a descendant of a container element which manages its selection and it is selectable by the user.

values: "true"
applies to HTML Form element <option>

XForms: see selectable
HTML, XHTML 1.0-1.1

Non-Form elements may be used to inject form data.
MSAA:STATE_SYSTEM_SELECTABLE
ATK:ATK_STATE_SELECTABLE
selfvoicing
Definition: Indicates the object tag represents a self-voicing application meaning that it will speak without an assistive technology.

values: true

HTML, XHTML 1.0-1.1
MSAA:STATE_SYSTEM_SELFVOICING
ATK: Recommend adding to ATK.
unknown

Definition: This is the indeterminate state of a tri-state widget. This is used for progress meters or checkboxes.

values:true

HTML, XHTML 1.0-1.1

Through value="unknown" for role="checkbox" or role="progressmeter"

ATK:indeterminate and MSAA:mixed
value

Definition: This is the data value for the element when used to store state information. Such as "unknown" for a checkbox implementation.

values: string
*We need to determine the XForms mapping as it relates to precision and type. XForms makes use of XML Schema whereby XHTML1.1 does not provide for this information. HTML, XHTML 1.0-1.1

Non-Form elements may be used to inject form data.

Changing the DOM value property should affect the attribute  and changing the value attribute  should affect the DOM value property.

When available must provide type and precision.

XForms: computed from the data model


MSAA: should return the value for getValue().
ATK: should return this as part of of the AccessibleValue structure.


3.2 States mapped for new roles

These are states mapped for new roles document.

Need to support HTML  today New role to map from User Agent mapping
checked

Definition: This is used for elements having  a check box representing  a checked state.

values: true
<input type="checkbox">
role= "checkbox|menuitem-checkbox|button-checkbox" For all non-HTML checkboxes, this state is determined from the value property. If the value is true for the designated roles the corresponding checked state must be set to true. Otherwise, the checked state is determined from the form input control.

MSAA: STATE_SYSTEM_CHECKED
ATK: ATK_STATE_CHECKED
default

Definition: This is the default submit button used to submit form data.

values: "true"
<input type="submit"> or
<button type="submit">
role="submit".
MSAA:STATE_SYSTEM_DEFAULT
This state is determined from the role for all other platforms.
iconified

Definition: This is the state when an object, application, document, is minimized and represented as an icon

values:"true"

role= "html:document", "html:application"
If the state is "expandable":

ATK:ATK_STATE_ICONIFIED

multiline

<textarea> role="textarea" ATK:ATK_STATE_MULTI_LINE
This state is determined from the role for all other platforms.

pressed

Definition: Same as checked.

values: "true"

role= "checkbox"|"menuitem-checkbox"|"button-checkbox" MSAA: STATE_SYSTEM_PRESSED is  true when checked.
ATK: ATK_STATE_PRESSED is true when checked
secret
<input type="password"> role="password" MSAA:STATE_SYSTEM_PROTECTED
ATK:ATK_STATE_SECRET
singleline
 <input type="text">

role="textfield"

ATK:ATK_STATE_SINGLE_LINE
This state is determined from the role for all other platforms.

3.3 States managed for existing elements

These are the states and how they should be applied to existing elements within the user agent.

3.3.1 HTML Forms and anchors


State
HTML  today User Agent Mapping
default
<input type="submit"> or <button type="submit">
MSAA:STATE_SYSTEM_DEFAULT

For all other platforms, the user agent must make available through the DOM or a specialized API.


multiline
<textarea>
ATK:ATK_STATE_MULTI_LINE
Other platforms: implied based on the textarea being representative of it role.
multiple
<select>
MSAA:STATE_SYSTEM_EXTSELECTABLE
ATK:ATK_STATE_MULTISELECTABLE
secret
<input type="password">

MSAA:STATE_SYSTEM_PROTECTED
ATK:ATK_STATE_SECRET

selectable
<option>
MSAA:STATE_SYSTEM_SELECTABLE
ATK:ATK_STATE_SELECTABLE
selected
<option>
MSAA:STATE_SYSTEM_SELECTED
ATK:ATK_STATE_SELECTED
singleline <input type="text"> ATK:ATK_STATE_SINGLE_LINE
Other platforms: implied based on the textarea being representative of its role.



3.3.2 XForms

XForms is designed based on a model view controller architecture. Data model and styling are separated from the actual form elements. This provides for a much more flexible forms model. The rendering is up to the user agent and styling. If the author knows the type of widget that will be generated they may simply add role information to the element or this information could be provided by the User Agent depending on the deployment. The appearance may be suggested as parameters to the form elements such as in the case of a select1 which may be used to represent a radio button. In these situations it is less important to know what the rendering of the element is as the tag defines the semantics.


State
XForms  today User Agent Mapping
disabled
<select1>, <item>, <textarea>, <secret>, <input> MSAA:STATE_SYSTEM_UNAVAILABLE
ATK:ATK_STATE_DISABLED

This is determined from relevant. If relevant is false this disabled shall be mapped
focusable
<select1>, <item>, <textarea>, <secret>, <input>, <choices>, <repeat>

MSAA:STATE_SYSTEM_FOCUSABLE
ATK:ATK_STATE_FOCUSABLE

The user agent must set this to true when relevance is computed as true in the data model.

invalid
<select1>, <item>, <textarea>, <secret>, <input>

ATK:ATK_STATE_INVALID
MSAA: no mapping

If the state is computed to be invalid, out-of-range, or required this value should be returned as true. In the case of MSAA the user agent should provide a specialized API to return its value. Alternatively, if the user agent provides a specialized API for XForms it may provide invalid(), outOfRange(),  or empty() (returns true when required but not available).  This information is computed from the instance data associated with the form element.

*It would also be good to expose what the range and type actually is such as providing the minimum and maximum range where it cannot be determined from a corresponding schema and exposed data model.
hidden
<select1>, <item>, <textarea>, <secret>, <input>, <choices>, <repeat>, <submit>, <trigger>
MSAA:
STATE_SYSTEM_INVISIBLE: true if hidden=true; Otherwise false

ATK:
ATK_STATE_VISIBLE : false if hidden=true.
Otherwise false

The user agent will need to set this to true when there is no binding to data in a form element.
Elements with this state should not be made available to users.
multiline
<textarea>
ATK:ATK_STATE_MULTI_LINE
Other platforms: implied based on the textarea being representative of it role.
multiple
<select>, <repeat>
MSAA:STATE_SYSTEM_EXTSELECTABLE
ATK:ATK_STATE_MULTISELECTABLE
This attribute is implied based on the element type in XForms. It is up to the User Agent to do the implied mapping to the appropriate state.
optional
<select1>, <item>, <textarea>, <secret>, <input>, <choices>
There is no mapping for  for this in MSAA or ATK

The XForms implementation should provide a method either in the DOM or a specialized API since this value should be calculated as optional may be set to true or be evaluated based on an XPath. For example, a method of isOptional() is suggested.
readonly
<select1>, <item>, <textarea>, <secret>, <input>, <choices>

MSAA:STATE_SYSTEM_READONLY
ATK:ATK_STATE_READONLY=inverse of readonly

The XForms implementation should provide a method either in the DOM or a
specialized API since this value should be calculated as required may be set to true or be evaluated based on
an XPath. In the case of Windows this would be computed and added to the MSAA accessible states. In ATK
this would be computed and added to the AccessibleStateSet. On other systems a method could be provided
such as isReadOnly().
required <select1>, <item>, <textarea>, <secret>, <input>, <choices> There is no mapping for  for this in MSAA or ATK

The XForms implementation should provide a method either in the DOM or a
specialized API since this value should be calculated as required may be set to true or be evaluated based on
an XPath. For example, a method of isRequired() is suggested.
secret
<secret>

MSAA:STATE_SYSTEM_PROTECTED
ATK:ATK_STATE_SECRET

This is state is managed by the user agent. Use of secret as a tag implies secret.

selectable
<item>
MSAA:STATE_SYSTEM_SELECTABLE
ATK:ATK_STATE_SELECTABLE

Note: <itemset> should be expanded by the user agent. An attribute of selectable should be automatically be set by the user agent as long as it is bound.
selected
N/A
<item> <itemset>
When <itemset> is used, its elements are expanded by the user agent  at runtime vs. <item> which is already expanded in the document model. XForms does not  provide state information directly. No child has the selected state until something is selected. What is selected, visibly,  is based on coss pseudo classes applied to a child element . The style sheet engine may be unreliable.  When one is selected, the selected child is copied into the model by the XForms processor. The selected child/children data is referenced in the model from the ref attribute on the select or select1 element. 

The user agent should provide a method that returns a list of selected data to the assistive technology. If this is empty, nothing is selected. This is not normally how assistive technologies work although it is simpler to process. For example, the Select element may have a role of Calendar and each selected child may have a data type of date which would be easily processed and read as a calendar was being processed. This also simplifies multi-modal interfaces.

*Need to verify the following XForms interpretation from the group.
singleline <input> ATK:ATK_STATE_SINGLE_LINE
Other platform : implied by <input> being representative of its role.




3.4 States completely managed by the user agent

This section lists all states managed entirely by the user agent. The author is not allowed control over these states. These states shall be mapped to the accessibility API layer on the target operating system platform. These states must be managed by the user agent either because information is required outside the document or it is impossible for the page author to implement.

State
Reason for management by User Agent
User Agent Mapping

activewindow


Definition: This is a window or window simulation whose child has a child with the focused element.

Value: "true"

This must be supported automatically by the browser as the solution involves focus management in the user agent.
MSAA:activewindow
ATK:activewindow
This should be set to true when the Frame or element within a frame which has a role of "html:frame or html:dialog" or "html:messagebox" who has a child element with focus or an actual frame has focus. There can be only one active window. If an element has a role that is indicative of these roles it shall take precedence over the frame in which it is contained.
busy

Definition: Indicates that the element cannot receive input vs. not editable. This is set by the user agent such as when loading pages.

values: "true"
The author does not have control over this. This is a user agent function. MSAA:busy
ATK:busy

This is applied to the document to indicate that the page cannot receive user input such as when the page is loading.
focused

Definition: The element with input focus.

Values: "true"
Must ensure that only one element has focus at any given time. Note: the page author must be able to perform setFocus() on any page element which is active.
MSAA: STATE_SYSTEM_FOCUSED
ATK: focus
haspopup

Definition: Indicates that a pop-up menu can be launched from this element. This is a used by alternative input devices to indicate a pop-up menu can be activated.

values: "true"
This applies to all elements. Redundant information exists in the roles of the event handlers. This was created for MSAA as a shortcut to get semantic information about the default action. This is not required for ATK.

This state should be mapped to true on Windows systems when an event handler has a role of pop-up menu.

MSAA: haspopup

ATK: not necessary in ATK because it has multiple actions with descriptions.
linked

Definition: Indicates if the element contains a hypertext link to another URL.

Values: "true"
This information is declarative and should be managed by the user agent. HTML: <a href="url">
href="url" on any element in XHTML 2.0

MSAA:linked
ATK:This is implied by implementing AtkHyperlink

On all other platforms this information must be provided through the DOM or some other API mechanism

showing, offscreen


Definition: Indicates if the element is visible after clipping

Values="true", "false"

This must be managed by the user agent and not the author.
MSAA: offscreen
ATK: showing
Value  is true if fully or partially visible on screen after clipping.
visited

Definition: Indicates if the element contains a hypertext link to another URL which has already been visited.

Values:"true"
This information is declarative and should be managed by the user agent.
HTML: <a href="url">
href="url" on any element (XHTML 2.0)

MSAA:visited
On all other platforms this information must be provided through the DOM or some other API mechanism

3.5 Unsupported States defined in Accessibility APIs

State
Reason

active

Unnecessary. This can be determined if an event handler is present.

animated, marqueed

This should be done via a style sheet whereby the browser provides a method for getting this information from the final format of the style. This does not appear to be implemented in browsers.

managesdescendants

Unnecessary. This is handled by the event bubbling mechanism in the DOM, whereby they need only attach to the root node to listen for all events and their target. It is inefficient to attach event monitors on all DOM elements.
sensitive Unnecessary. This applies only to ATK and Sun indicates this may be duplication of effort.

unavailable

This is the same as disabled (not the same as busy).

4.0 Appendix

4.1 Merged state attributes supporting accessibility

The following table contains the proposed state attributes to generate accessible state information from scripting through DOM interaction. Those states preceded by an asterisk are already implied by existing form elements. As a result, CSS3 has created corresponding pseudo classes.

To generate the requirements a mapping was completed between between MSAA and GAP accessibility state information. All state information which should be generated by the user agent vs. the script, such as showing are omitted.

These requirements have been reviewed by Peter Korn and Bill Haneman at Sun and agreement was reached with the WAI PF working group.

Proposed State Attributes Definition Implied document states today MSAA, GAP,
Cocoa
Questions/comments
activewindow Indicates a window is currently the active window. N GAP
Cocoa
Sun is OK with this
animated The element's appearance changes rapidly or constantly. This state is used to indicate that the element's location is changing. N MSAA  
busy Indicates that the element cannot receive input vs. not editable. N MSAA,GAP
 
*checked Replaced by the value property.
Y MSAA,GAP
 When included with role, may be replaced by the value property. Which would be true in this case.
collapsed Children of this element are hidden. Allows for progressive disclosure of children. N All
GAP's name is “expandable”. The mapping is straight forward for GAP. The bridge mapping layer would simply translate the state information accordingly.
*default The default state applies to a UI element that is the default among a set of similar elements. Typically applies to context menu items and buttons. One example is the default submit button among a set of buttons. Y MSAA MSAA treats this as the default button with focus in a window. However, this should be expanded to meet a web page as the CSS working group has already defined.
*enabled, *disabled The purpose of the enabled state is to allow authors to customize the look of user interface elements which are enabled - which the user can select/activate in some fashion (e.g. clicking on a button with a mouse). There is a need for such a state because there is no way to programmatically specify the default appearance of say, an enabled input element without also specifying what it would look like when it was disabled.

Similar to enabled, disabled allows the author to specify precisely how a disabled or inactive user interface element should look.

It should be noted that most elements will be neither enabled nor disabled. An element is enabled if the user can either activate it or transfer the focus to it. An element is disabled if it could be enabled, but the user cannot presently activate it or transfer focus to it.

Y All
GAP supports disabled and sensitive. Bill Haneman believes there is redundancy with sensitive in GAP. Will use standard because already in place. GAP mapping can address inconsistencies.
expanded Children of this element are displayed. N All
 
*focus state applies while an element has the focus (accepts keyboard or mouse events, or other forms of input). Y All Note: Corresponds to focused in MSAA and GAP. This applies to other forms of input besides the keyboard. This is needed for device independence. Focus is used vs. focused as this is already in the CSS3 Basic UI module.

 

Bill: Distinction between keyboard focus and other kinds of focus is needed, if we overload this term, for on screen keyboard clients.

Rich to Working Group: This is a problem. on most systems this means keyboard and not mouse. We need to discuss.

focusable The element is in the active window and is capable of receiving focus. Receiving focus means it can respond to keyboard input when it has focus. N All
This has proven very useful, especially for text navigation and for onscreen keyboards. From a style sheet perspective, the page author may wish to indicate this.
haspopup Element displays a pop-up menu or window when invoked. N MSAA Note: In GAP we expose this information as a relationship between objects, with the POPUP_FOR relationship. Would be valuable to use this information to establish a GAP relationship.
horizontal Indicates the orientation of this element is horizontal. If JavaScript were used to render a horizontal/vertical scroll bars or progress bars this would be of value. N GAP,
Cocoa
Microsoft hard codes an object ID for this which limits the MSAA to a standard Windows scroll bar implementation. Use of state is a better implementation.
iconified Indicates this element is minimized and is represented only by an icon N GAP,
Cocoa
 
*indeterminate Indicates that the state of a three-state check box or tool bar button is not determined. The check box is neither checked nor unchecked and is therefore in the third or mixed state. N MSAA, GAP Replaces mixed for MSAA as is a close match to GAP and is already provided for in the CSS3 Basic UI specification.

This state could be used for more than a 3-state control (e.g. 4+ state).  It is the state that is indeterminant, though the data referred to may be mixed.

invisible, visible The element is programmatically hidden or made visible. For example, menu items are programmatically hidden until a user activates the menu. Because elements with this state are not available to users, client applications should not communicate information about the element to users. N MSAA,
GAP
There is either one or both on either platform.
*invalid; valid An element is :valid or :invalid when it is, respectively, valid or invalid with respect to the bound instance data constraints. An element which lacks data validity semantics is neither :valid nor :invalid. This is different from an element which otherwise has no constraints. Such an element would always be valid. Y GAP GAP provides an invalid state. There is nothing in MSAA.
linked; visited Indicates that the element is formatted as a hyper link. N MSAA  MSAA :linked, traversed – MSAA

This will be useful to map non-link elements that are simulated as links in JavaScript to GAP as well.

managesdescendents Indicates that "active-descendant-changed" event is sent when children become 'active' (i.e. are selected or navigated to onscreen). Used to prevent need to enumerate all children in very large containers, like tables. N GAP Questions: Can a "style" be applied here? Can someone give me a use case for this wrt. JavaScript generated content on a web page.

PETER:this is commonly associated with transient (an object with transient children often [should] manage its descendents).

BILL: Vital for spreadsheets and other objects with a large number of children. Very possibly needed for big JavaScript tables.

marqueed Indicates scrolling or moving text or graphics. N MSAA  
moveable Indicates that the element and its children can be moved such as for dragging or dragging and dropping. N MSAA  
multiselectable Indicates this element allows more than one of its children to be selected at the same time. N MSAA,
GAP
Working group decided to use multiselectable. And remove :extselectable. (MSAA)
multiline, single line Indicates this (text) element can contain multiple lines of text. This should be limited to text fields and text areas but not general free-form text. N GAP This has been helpful for GAP.

Important when determining what keyboard navigation model to use, and in some other cases (for instance, TAB behaves differently in the two cases for most toolkits)

pressed Indicates the element is pressed. B10 N MSAA,
GAP
 
*read-only, *read-write Indicates the user can change the contents of this element or not. Y MSAA,
GAP
Replaces read-only in MSAA and editable from GAP.
resizeable Indicates the size of this element is not fixed and therefore may be resized. For example, a user could change the size of a window by clicking the border with a mouse and dragging the mouse. This would also apply to resizing a column in a spreadsheet. N MSAA, GAP MSAA calls it sizeable. This is different from the dictionary meaning.
secret Used to provide the user with the ability to supply information to the system in a manner that makes it difficult for someone, other than the user, who may be observing the process to discern the value that is being supplied. A common use is for password entry. N MSAA MSAA supports protected. GAP has a notion of a Secret Role that is used by Open Office. XForms makes use of a secret element and HTML 4.0 makes use of a password attribute. Comment: this would be valuable when processing a form if you were blind. If you tabbed to the field you could determine this information right away.

It might be useful to GAP later on for things like 'secret'

spread sheet cells too, though the semantics need to be clarified.

selectable Indicates this element accepts selection. N MSAA,GAP GAP is more explicit by referring to a child hierarchy. This is too restrictive. For example we may want to apply selected to a table cell row or column.

BILL: I think we need to keep this state on a per-object basis; if we need different semantics for rows/columns I would prefer a different (additional) state.

selected Indicates the element is selected. N MSAA, GAP GAP is more explicit by referring to a child hierarchy. This is too restrictive. For example we may want to apply selected to a table cell row or column.

BILL: I think we need to keep this state on a per-object basis; if we need different semantics for rows/columns I would prefer a different (additional) state.

selfvoicing

The element or child uses text-to-speech (TTS) technology for description purposes. A speech-based accessibility aid does not announce information when an element with this state has the focus because the element automatically announces information.

N MSAA This would be helpful in the case of an audio style sheet. It prevents an assistive technology from reading something that is already being spoken. Furthermore, if a self-voicing document element was present, such as a self voicing applet, this would be very helpful to coordinate speaking or not speaking of the applet.
vertical Indicates the orientation of this element is vertical. If JavaScript were used to render a horizontal/vertical scroll bars or progress bars this would be of value. N GAP,
Cocoa
Microsoft hard codes an object ID for this which limits the MSAA to a standard Windows scroll bar implementation. Use of state is a better implementation.
unavailable Indicates the element is unavailable. N MSAA Could be valuable on a page basis such as when the page is waiting on a web service to complete a form submittal. The rendering may be a please wait indicator or some color combination.
Additional state information corresponding to CSS3 Basic UI specification.        
*active Applies while an element is being activated by the user. For example, between the times the user presses the mouse button and releases it. Y None These are not in MSAA or GAP. This is the GAP state ARMED. GAP will need to MAP this to ARMED.
*hover Applies while the user designates an element (with some pointing device), but does not activate it. For example, a visual user agent could apply this state when the cursor (mouse pointer) hovers over a box generated by the element. User agents not supporting interactive media do not have to support this pseudo-class. Some conforming user agents supporting interactive media may not be able to support this pseudo-class (e.g., a pen device). Author should also implement active at the same time. Y None Rich: Hover simply means to apply a style when the mouse is over the object. You would probably require the developer to indicate active at the same time.  This would be mapped to hottracked in MSAA. Page author should also implement “active” when this is turned on.
*in-range, *out-of-range Apply only to elements that have range limitations. An element is :in-range or :out-of-range when the value that the element is bound to is in range or out of range of the visual representation of the element respectively. E.g. a slider element with a value of 11 on a slider that only represents the values from 1-10 is :out-of-range. In summary: an element is :out-of-range when it does not accurately reflect the state of the model. Y None  
*optional, required If a value for each is, respectively, required or optional before the form it belongs to is submitted. Elements that are not form elements are neither required nor optional. This spec does not defined what is a form element. Y None Recommend this be added to GAP or MSAA derivative.