aria-interactive and the authoring/debug process problems

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.

I think role values should not be able to switch between interactive and non-interactive based on attribute values, that should be a fundamental part of a role.  ARIA is hard enough for developers to understand, making some roles change from interactive to non-interactive based on attribute values will add to the complexity of learning and using ARIA.

My two cents,
Jon

Received on Thursday, 14 May 2015 19:35:15 UTC