ISSUE: ARIA 5/14 Draft, "Use a host language feature" meaning unclear.

ISSUE: ARIA 5/14 Draft, "Use a host language feature" meaning unclear.

In the last paragraph of Section 1, a sentence says, "Use a host  
language feature that is as similar as possible to the ARIA feature,  
then refine the meaning using ARIA."

I'm not sure what this would mean for host languages like HTML 5 that  
have partial implementations of overlapping semantics. With elements  
and roles, it makes sense. With states and properties implemented as  
attributes, it leaves some confusion.

To start with a simple example, let's discuss the 'aria-required'  
attribute, versus HTML 5's native 'required' attribute. They seem to  
be 100% analogous, so let's also assume that a user agent has been  
implemented to tell the assistive technology that HTML 5's 'required'  
attribute maps to the accessibility API's 'required' property in the  
same way that 'aria-required' does.

Let's also assume that a web developer has written an ARIA-aware  
JavaScript library that will be used on a variety of pages, some HTML  
5, some HTML 4, some XHTML 1, etc. Who's job is it to remap the ARIA  
data for all purposes? If the script library requests an 'aria- 
required' attribute value which doesn't exist, but the DOM only has a  
'required' attribute, what should be returned?

Assuming the UA knows about the mappings for both 'aria-required' and  
'required,' then if the script sets an 'aria-required' attribute, the  
UA should update that elements accessibility API property, which  
should then get back to the UA and update the host language's native  
attribute, 'required'. I assume this behavior is expected and correct.  
So far, so good. But if that's the case, then theoretically, if you  
updated the native HTML 5 'required' attribute, the event chain should  
also automatically update the 'aria-required' attribute, even though  
there is more precise, native attribute with the same meaning. So  
let's go back to my first question: If the script library requests an  
'aria-required' attribute value which doesn't exist, but the DOM has a  
'required' attribute, what should be returned? I think it should be  
the value of the 'required' attribute. Theoretically, this means a  
script library should be able to get and set any 'aria-*' attributes  
in any language, regardless if there is a 'host language feature' that  
has the same semantics of that 'aria-*' feature.

I'm sure DOM many purists would disagree with this approach, but  
otherwise, who would the onus be on to ensure semantics inserted one  
way would be readable by all three or four links in the chain, the AT,  
the API, the UA, and the author scripts. I assume the lowest common  
denominator in this chain is the user agent.

Clarifying wording might be something like, "User agents that  
implement aria-* attributes MUST associate those attributes to their  
analogous semantic counterpart in any other implemented host  
languages, and keep the value of the analogous attributes  
synchronized." That wording in not particularly clear, but for  
example, if a UA implements both ARIA and HTML 5, then the HTML that  
specified either @required or @aria-required would have both  
attributes available in the DOM, and a change to either one of those  
attributes would change both. Their values would remain synchronized  
for the life of that DOM. Related concept: Cocoa Bindings.

Received on Monday, 9 June 2008 02:41:11 UTC