aria-role behavior support for limited input types

[GoogleCodeExporter]

I would like to add speech feedback/behavior support for a few ARIA input 
roles, which seem most likely to me to be used instead of the HTML counterparts.

aria-role="button"
This should be easy to implement. Basically the content of the tag will be read 
followed by the word "button" like it would if it were a <button>. Activating 
the pseudo-button would take the onclick behavior and might provide speech 
output if there was a data-ez-sayonaction or equivalent attribute. (I can see 
this being used on <div>s or <img>s that people want to turn into buttons.)

aria-role="checkbox"
This would act like a native HTML checkbox. Navigating to it would read: 
"[Content of tag], checkbox is [status]." Where the status would depend on the 
aria-checked attribute (if true, then status="checked"; if false, then 
status="unchecked"; note that ARIA also allows "mixed"). Using EZ ACTION on the 
pseudo-checkbox would take the onclick behavior and read: "[Content of tag] has 
been checked/unchecked," as appropriate.

aria-role="radio"
This would behave like a native HTML radio button. Note that it would be up to 
the designer to enforce the mutually exclusive behavior of the radio button 
set--that's not something EZ Access would do. Navigating to the pseudo-radio 
would read: "[Content of tag], radio button is [status]." Where the status 
would depend on the aria-checked attribute (if true, then status="checked"; if 
false, then status="unchecked"; note that ARIA also allows "mixed"). Using EZ 
ACTION on the pseudo-radio would take the onclick behavior and read: "[Content 
of tag] has been checked/unchecked," as appropriate.

At this point, I don't feel that other aria-roles are as likely to be used. The 
other types of input also have more complex speech output, which might be 
tricky to provide with pseudo-inputs.

Original issue reported on code.google.com by jbjor...@gmail.com on 7 May 2013 at 8:58

[GoogleCodeExporter]

In the code, the aria-role speech output code should be physically close to 
that associated with the native HTML elements (or be the same if possible), so 
it is easier to change them in parallel if needed.

Original comment by jbjor...@gmail.com on 7 May 2013 at 9:01

[GoogleCodeExporter]

Original comment by aeharding on 12 Jun 2013 at 7:36

• Changed state: Started

[GoogleCodeExporter]

This issue was closed by revision r174.

Original comment by aeharding on 12 Jun 2013 at 8:17

• Changed state: Fixed