- From: Cynthia Shelly <cyns@microsoft.com>
- Date: Tue, 19 Jan 2016 18:46:47 +0000
- To: "public-aria@w3.org" <public-aria@w3.org>
- Message-ID: <SN1PR0301MB1535A553EA4350C620A5E062C6C10@SN1PR0301MB1535.namprd03.prod.outlook.>
I'm not officially a member yet, so can't edit the action directly. Here's a draft for Action 1585. Accessibility APIs allow developers to express the function of controls and text to assistive technologies. Typically, accessibility APIs include a tree of user interface elements (controls and text) and information about each control: * descriptive Properties (role, name, position, etc.) * transient States (pressed, focusable, etc.) * Events (text changed, button was clicked, checkbox was toggled), and * Actions the user might take (click, check/toggle, drag, etc.) * Relationships (parent/child in the tree, controls, flowsto, etc.) UI Automation also supports the concept of patterns. Patterns allow you to describe a kind of behavior, and group them together to express new controls. For example, Toggle and Invoke patterns can be combined to express a tri-state button. Each of these patterns includes the states, properties, methods and events that describe the behavior. UIA uses Control Type rather than role. Control Types are defined in terms of their required and optional patterns. So, a button must support Invoke, and can optionally support Toggle. ARIA 1.x does not directly support patterns, but many of the UIA mappings in the AAM documents combine patterns to express web interaction concepts that are not native Control Types in UIA.
Received on Tuesday, 19 January 2016 18:47:16 UTC