Re: ACTION-1569: Create a section that describes AAPI differences

Joseph,

Thanks. Looks good to me, although I do have a few comments/proposed edits. 

1. The end of the 2nd paragraph in "1.1 Accessibility APIs” reads "Accessibility APIs include a tree of accessible objects (controls and text) and information about each accessible:”.  Can we change this to read “…about each accessible object:”, or possibly “about each of them:” to avoid the shorthand reference to accessible objects as “accessibles”?

2. In “1.1 Accessibility APIs” it says "In the case of static Web pages, the Document Object Model (DOM) is used to represent the structure and state of the elements in the document being rendered by a user agent.” This could be read as suggesting that the DOM does not represent the structure and state of elements in interactive web pages. Can we just drop the word “static”?

3. In “1.1 Accessibility APIs” it says "For traditional static Web pages, assistive technologies, such as screen readers, interact with user agents using the DOM. For UI elements that are known to be interactive, such as HTML form elements and desktop applications, assistive technologies may use platform accessibility APIs.” This could be read as suggesting that assistive technologies wouldn’t or don't use accessibility APIs for static web page content, and that accessibility APIs are really only for interactive UI elements. Possibly rewrite that whole paragraph, for example: 

"In the case of Web pages, the Document Object Model (DOM) is used to represent the structure and state of the elements in the document being rendered by a user agent. The elements of the document are organized into a hierarchy of nodes known as the DOM tree. To interact with static Web content, assistive technologies, such as screen readers, have tended to rely on the DOM provided by the user agent. However, platform accessibility APIs provide a quicker and more comprehensive way for assistive technologies to learn about and interact with Web page content. Especially with UI elements that are known to be interactive, such as HTML form elements and desktop applications, accessibility APIs allow the more complex roles, properties, states, and relationships of those elements to be communicated to assistive technology in a way that the DOM cannot provide on its own."

4. Recommend the following minor rewrite of “1.3.2 UIA”:

“Central to UI Automation is the concept of Control Patterns. Control Patterns allow the description of common kinds of UI element behavior. These behaviors can be grouped together to express new types of UI controls. For example, the Toggle and Invoke Control Patterns can be combined to express a tri-state button. Each Control Pattern includes the states, properties, methods and events that describe the behavior.

Where other accessibility APIs include a role property whose value defines the type of UI element or control, UIA has the Control Type property to describe what kind of control a UI element represents. Control Types are defined in terms of their required and optional Control Patterns. So, the Button Control Type should support the Invoke Control Pattern or the Toggle Control Pattern, but not both at the same time.

ARIA 1.x does not directly support Control Patterns, but many of the UIA mappings in the AAM documents combine Control Patterns to express web interaction concepts that are not native Control Types in UIA.”

5. I’m happy to create a new fork for these proposed efforts, if that’s preferred.

Cheers,

Jason



Jason Kiss
jason@accessibleculture.org





> On 20/02/2016, at 9:53 AM, Joseph Scheuhammer <clown@alum.mit.edu> wrote:
> 
> Jason, Cynthia,
> 
> I have combined and added your modifications to the core-aam regarding a section that describes the differences among AAPIs (issue-540/action-1569/action-1585).  Could you please review?
> 
> Cynthia, I put some of your changes in the section " 1.1 Accessibility APIs", specifically the second paragraph:
> http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#intro_aapi
> 
> The rest were put in the new section "1.3.2 UIA":
> http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#uia
> 
> Jason, your change is the new section "1.3 Comparing Accessibility APIs":
> http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#comparing-accessibility-apis
> 
> Let me know if you need any further fixes, thanks.
> 
> Urls to your original text is given below in the quoted message from Jason.
> 
> On 2016-02-02 5:00 PM, jason@accessibleculture.org wrote:
>> Hi,
>> 
>> Sorry for not responding earlier.
>> 
>>> On 26/01/2016, at 7:52 AM, Joseph Scheuhammer <clown@alum.mit.edu> wrote:
>>> 
>>> Jason,
>>> 
>>> We are about to pull in your suggested changes:
>>> http://rawgit.com/w3c/aria/issue-540/core-aam/core-aam.html#comparing-accessibility-apis
>>> 
>>> Cynthia (CC'ed) has proposed text for a section about UIA to be included.  Her suggested text is in this email:
>>> https://lists.w3.org/Archives/Public/public-aria/2016Jan/0069.html
>>> 
>>> Your text begins with section "1.3.1 ATK/AT-SPI".  We are going to follow that with section "1.3.2 UI Automation" using Cynthia's text.  Then your "1.3.2 Accessible Names and Descriptions" becomes "1.3.3 Accessible Names and Descriptions".  Any objections?
>> That reordering of the sections makes more sense, so no objections.
>> 
>> Regarding Cynthia’s proposed text about UIA, I wonder if the first paragraph and list in that text, which are about accessibility APIs generally, might be better added to section “1.1 Accessibility APIs”, possibly after the second paragraph there.
>> 
>> Then the remainder of Cynthia’s text specific to UIA could form the new section “1.3.2 UI Automation”, perhaps with a small tweak to what would then be the first paragraph of that new section, for example:
>> 
>> “In addition to the types of information typically provided by accessibility APIs (e.g. properties, states, events, actions, etc.), UI Automation also supports the concept of patterns…."
>> 
>> Does that make sense?
>> 
>>> You have question in that last section about UIA descriptions, " Automation elements in the UIA accessibility tree have a Name property. [what about description in UIA?].   I've created an action for Cynthia to provide an answer (ACTION-2008).  I would like to replace your question with a references to the ACTION.
>> Great.
>> 
>>> In terms of mechanics, is there a pull request for your changes?  Or shall I just merge them in?
>> Feel free to just merge them in, unless you would prefer a pull request (although there will likely be conflicts to resolve given that branch 1540 with my changes are a year old now).
>> 
>> Thanks,
>> 
>> Jason
>> 
>> 
>>> Thanks.
>>> 
>>> -- 
>>> ;;;;joseph.
>>> 
>>> 'Die Wahrheit ist Irgendwo da Draußen. Wieder.'
>>>                 - C. Carter -
>>> 
> 
> 
> -- 
> ;;;;joseph.
> 
> 'Die Wahrheit ist Irgendwo da Draußen. Wieder.'
>                 - C. Carter -
>

Received on Wednesday, 24 February 2016 01:39:29 UTC