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

Hi Joseph,

> On 27/02/2016, at 4:11 AM, Joseph Scheuhammer <clown@alum.mit.edu> wrote:
> 
> 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?

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:…” 


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

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

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

Ok. That’s what I’ll do.

Jason

> 
>> 
>> Cheers,
>> 
>> Jason
>> 
>> 
>> 
>> Jason Kiss
>> jason@accessibleculture.org
>> 
>> 
> 
> Ciao,
> 
> -- 
> ;;;;joseph.
> 
> 'Die Wahrheit ist Irgendwo da Draußen. Wieder.'
>                 - C. Carter -

Received on Tuesday, 1 March 2016 21:23:57 UTC