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

Hi Jason,

On 2016-03-01 4:23 PM, jason@accessibleculture.org wrote:
> Hi Joseph,
>
>
>
> ...
>
>
> 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?
> The pedant in me thinks that “accessible” as a noun is a colloquial aberration and not appropriate for a formal technical standard. Then again, I also think that today’s common use of “begs the question” to mean “raises the question" is a problem, when that bird has already flown the coop. While “accessible” as a noun is a common shorthand “in the industry”, anyone who is not an implementer or native English speaker might, after reading about accessible names, accessible objects, things being accessible, etc., get a little confused to come up against something called an accessible as a thing in itself.
>
> That said, I’m not absolutely opposed, and would only suggest, if we are going to allow “accessible” to mean “accessible object”, that this be somehow clarified in any spec that uses it that way. Including it in the glossary might be an option, but then some instances of the word “accessible” would link to the glossary entry while others wouldn’t. Or maybe the usage could be indicated in the prose the first time it is used like that, e.g. “Accessibility APIs include a tree of accessible objects, often referred to as accessibles, and information about each one:…”

We discussed this at last week's AAPI meeting, and we are in agreement 
with the change to "accessible object(s)".  We have a request, though:  
could you make that editorial change as part of your pull request 
(https://github.com/w3c/aria/pull/279)?  That is, replace all 
occurrences of "accessible" with "accessible object". I'm not sure, but 
that should be straight forward.  If it isn't, and you'd rather I do it, 
let me know.

>
>
>>> 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.
> Good. It should definitely be reviewed.

Again, we are in agreement with these changes.

>
>>> 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?
> I note Cynthia’s responded that she’s happy with the text but wants to change the Control Type example from button to something else and will be actioning that.

She has since given me the text for the new example, and asked me to put 
it together with your changes.  I will check out your branch, add in her 
example, and then push it back to github, all in time for tomorrow's 
AAPI meeting.  So, you are forewarned. :-)

Thanks!

-- 
;;;;joseph.

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

Received on Monday, 7 March 2016 18:37:53 UTC