Re: aria-interactive and the authoring/debug process problems


> On May 14, 2015, at 15:33, Gunderson, Jon R <jongund@illinois.edu> wrote:
>
> I understand the desire to reduce the number of roles in ARIA, but I have concerns that using aria-interactive attribute to achieve this goal will probably be detrimental to learning, authoring and debugging.
>
> Think of people looking at a DOM inspector and it says role=”gridcell”, but the accessibility API represents it as role=”td”.
>
> What role does a validation or visualization tool report to the user (e.g. GRIDCELL or TD)?
> If it is TD then the developer will not find a role=”td” in their DOM inspector view
> If it is gridcell then the definition of gridcell has to be more complicated to discuss that it is sometimes interactive and sometimes static based on an ancestor role of aria-interactive.  It sounds simple, but I think this will cause a lot of authoring errors, debugging problems and messaging complexity.
How much worse is your second option above (the DOM inspector shows role=gridcell but the accessibility API reports a table cell role) than the behavior of the HTML INPUT element, where the accessibility API mapping depends on the value of the TYPE attribute? This isn’t the only example, of course.


________________________________

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.


Thank you for your compliance.

________________________________

Received on Thursday, 14 May 2015 21:14:39 UTC