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

The rewrite of the UIA text is fine, except that I'd like to use a different example than an button. I have an action for that, which would still stand if we accepted this change.

-----Original Message-----
From: Joseph Scheuhammer [mailto:clown@alum.mit.edu] 
Sent: Friday, February 26, 2016 7:11 AM
To: jason@accessibleculture.org
Cc: Accessible Rich Internet Applications Working Group <public-aria@w3.org>; wai-xtech@w3.org; Cynthia Shelly <cyns@microsoft.com>
Subject: Re: ACTION-1569: Create a section that describes AAPI differences

Hi Jason,

Thanks for the followup.  Some of your suggestions are editorial, and I have no problem with those.  Some of the others I would like to discuss with the AAPI task force.  More thoughts inline.


On 2016-02-23 8:38 PM, jason@accessibleculture.org wrote:
> 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”?

I'm fine with that since this section is relatively near the beginning of the document.  However, when discussing mapping issues, we've often used "accessible(s)" as shorthand for "accessible object(s)", and I believe this terminology is used elsewhere in the document. I think the shorthand is fairly common now, so I'm reluctant to change every instance of it.  Is it particularly egregious from a grammatical standpoint?

>
> 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."

I believe these sections were written circa 2008, during the switch from HTML, which was mostly document markup relying little on JavaScript, to DHTML, which was a mixture of static document + lots of dynamic interaction.  It should be updated.  These changes I want to pass by the other members of the task force.

>
> 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.”

Cynthia, do you have any comments on the above suggestion?

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

That's my preference, since I find pull requests a useful way to discuss the changes and making tweaks, etc. before pulling it in to master.

>
> Cheers,
>
> Jason
>
>
>
> Jason Kiss
> jason@accessibleculture.org
>
>

Ciao,

--
;;;;joseph.

'Die Wahrheit ist Irgendwo da Draußen. Wieder.'
                  - C. Carter -

Received on Saturday, 27 February 2016 01:41:25 UTC