Re: Deprecation of DOMAttrModified (Was: DOMActivate vs. Activation Behavior)

Correcting a few typos that made that para difficult to understand:

What we need (does not exist other than through the deprecated, DOMAttrModified):
If an assistive technology user wants to do something other than the default "activation behavior" (for example, sort a table by the current cell's column), they convey that to the assistive technology (in VoiceOver, they'd use VO+vertical bar), which could then convey that to the user agent through the accessibility API, and the user agent could set the DOM attribute 'aria-sort' to 'ascending' or 'descending'... This much could work today, except that a web application author has no notification alerting them that the table grid's sort order has changed, so the controller is unlikely to know that it needs to update to view to reflect the new sort order. 

On Feb 9, 2010, at 1:14 PM, James Craig wrote:

> You're misunderstanding the problem. The connection from the web application *to* the assistive technology already exists. It's the connection from the assistive technology *to* the web application that we need. In both cases, the user agent acts as the intermediary. Two-way connections between the user agent and AT also already exist. What we need is a two-way connection between the web application and the user agent.
> 
> Already exists:
> If a web application author changes an attribute in the DOM, the user agent detects that change and updates the accessibility API, and the assistive technology can detect that change through the internal events you mentioned below, and alert the user. The web application author's intent is conveyed to the user.
> 
> What we need (does not other than through the deprecated, DOMAttrModified):
> If an assistive technology user wants to do something other than the default "activation behavior" (for example, sort a table by the current cell's column), they convey that to the assistive technology (in VoiceOver, they'd use VO+vertical bar), which could then convey that to the user agent through the accessibility API, and the user agent could set the DOM attribute 'aria-sort' to 'ascending' or 'descending'... This much could work today, except that a web application author has no notification alerting them that the table grid's sort or has changed, so the controller is unlikely to know that it needs to update to view to reflect the new sort order. 
> 
> Hopefully that explains the issue better.
> James
> 
> 
> 
> On Feb 9, 2010, at 12:42 PM, Jonas Sicking wrote:
> 
>> Note that there is nothing stopping implementations from having
>> internal events similar to DOMAttrModified. There is no reason to
>> limit accessibility tools to only use the feature set exposed to web
>> pages. Browsers should feel free to expose any API internally towards
>> accessibility tools that help these tools work as well as possible. We
>> do this internally in firefox a lot.
>> 
>> / Jonas
>> 
>> On Tue, Feb 9, 2010 at 12:21 PM, James Craig <jcraig@apple.com> wrote:
>>> On Feb 8, 2010, at 1:20 AM, Doug Schepers wrote:
>>> 
>>> I had a nice chat with Gregory Rosmaita the other day, and he and I cleared
>>> up some possible disconnects on both our parts regarding the deprecation of
>>> 'DOMActivate'.  I incorporated the fruits of our discussion in the current
>>> editor's draft of the DOM3 Events spec [1], which I hope clarifies not only
>>> the details of activation behavior, but the intent and implications of
>>> deprecating 'DOMActivate'.
>>> 
>>> Here are a couple more important points that Gregory advised me to
>>> emphasize:
>>> 
>>> * 'DOMActivate' is not the same as "activation behavior".
>>> 
>>> Thanks for that explanation, Doug. There is another issue for ARIA 2.0 that
>>> I noted on the PFWG list, now sharing here.
>>> DOMAttrModified is deprecated, but as far as I can tell, there is no
>>> suitable replacement. We'll need this (or something equivalent) in order to
>>> allow platform-, modality-, and device-independant access on anything other
>>> than the default action, which could be determined via click or DOMActivate.
>>> For example, on a treeitem element DOMActivate could indicate the default
>>> action of selection, but without DOMAttributeModified, there is no way for
>>> the user's assistive technology to convey the intent of a non-default
>>> action, such as expanding or collapsing the tree node. This currently relies
>>> on the author to assign de facto standard key events such as the left and
>>> right arrow keys. The deprecation of DOMAttrModified blocks the ARIA 2.0
>>> issue of device-independence.
>>> From the spec:
>>> "Warning! the DOMAttrModified event type is defined in this specification
>>> for reference and completeness, but this specification deprecates the use of
>>> this event type."
>>> http://dev.w3.org//2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-DOMAttrModified
>>> For example, the iPhone screen reader interface is completely gestural,
>>> without a keyboard unless the user is editing a text field. Although there
>>> could be a gesture to let the user convey their intent ("expand this tree
>>> branch") to the screen reader and user agent, there is no way for the user
>>> agent to convey that intent to the web application. DOMAttrModified or an
>>> equivalent event allows the web application to be notified when the specific
>>> DOM change occurs (e.g. @aria-expanded changed from "false" to "true") so
>>> the web application can update any relevant view after the attribute value
>>> has changed.
>>> For what it's worth, I don't foresee much need for rest of the mutation
>>> events (I could live with their deprecation), but DOMAttrModified is very
>>> useful from an accessibility perspective.
>>> Cheers,
>>> James Craig
>>> 
>> 
> 
>

Received on Tuesday, 9 February 2010 21:19:48 UTC