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

As I worked on the text, I started having similar doubts.
But, this is all hypothetical until someone really works out the remaining 
details and then steps through the kind of scenarios you are raising.
We have the ontology divided between structures and widgets. The 
fundamental question is whether that division should be a fundamental, 
unchangeable aspect of the nature of each element in the ontology. 
Is the decision to have a property like aria-interactive only a tradeoff 
between more strongly typed roles and fewer more flexible roles? 
For those who have not yet seen it, the branch I made for action 1505 that 
resulted in the aria-interactive property is at:
http://rawgit.com/w3c/aria/matt-action1505/aria/aria.html#aria-interactive


Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement 
Phone: (503) 578-2329, Tie line: 731-7398
mattking@us.ibm.com



From:   "Gunderson, Jon R" <jongund@illinois.edu>
To:     PF <public-pfwg@w3.org>, 
Date:   05/14/2015 12:35 PM
Subject:        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