Re: Role Application - is a parent containing element required?

Thanks Bryan,
Thanks for this recommendation about not combining two custom widgets under one parent application. I had not thought to do that until I read the Using ARIA guidance more carefully.

To clarify our approach we only use application role to create interactions that don’t map to native HTML or ARIA roles, and we implement these custom interactions with a non-semantic elements such as a div.

Regarding, “aria-activedescendant”, it is not relevant for the draggable "Chemistry book”, but it would be relevant to any combobox interaction we may create. You got me thinking there because we couldn’t make the combobox role to work, so we used a pop-up button and a listbox role.

Regardless, you think a single div without a parent is not a problem for focus, and our code does indeed work, though needs more vigorous testing.

Thanks folks,
Taliesin

~.~.~
Taliesin.Smith@colorado.edu
Inclusive Design Researcher
PhET Interactive Simulations
https://phet.colorado.edu/en/accessibility
Physics Department
University of Colorado, Boulder

> On Sep 7, 2018, at 4:29 PM, Bryan Garaventa <bryan.garaventa@levelaccess.com> wrote:
> 
> Hi,
> This particular markup should be fine, since the application role does support focusability in addition to aria-activedescendant to simulate internal focus when needed.
>  
> I don’t recommend combining multiple interactive widgets within each other however, because the more you complicate the user interactions the more likely it is that end users will not be able to correctly understand what is required to use them.
>  
> Going back to your general question about role=application on interactive widgets, this is only allowed when the focusable element does not have its own native role, such as on a div or span that has no native semantics.
>  
> If, however, role=application is applied to native interactive elements like buttons, links, and editable or selectable form fields, then this will cause critical accessibility issues and will likely break the widget for end users because the explicit role will destroy the native mapping for that control in the accessibility tree.
>  
>  
>  
> Bryan Garaventa
> Accessibility Fellow
> Level Access, Inc.
> Bryan.Garaventa@LevelAccess.com <mailto:Bryan.Garaventa@LevelAccess.com>
> 415.624.2709 (o)
> www.LevelAccess.com <http://www.levelaccess.com/>
>  
> From: Taliesin Smith <talilief@gmail.com> 
> Sent: Wednesday, September 05, 2018 8:52 AM
> To: w3c WAI List <w3c-wai-ig@w3.org>
> Subject: Role Application - is a parent containing element required?
>  
> Hi Folks,
> In the Using ARIA documentation (https://www.w3.org/TR/using-aria/#using-application <https://www.w3.org/TR/using-aria/#using-application>), it says that the role="application" should be placed on the "closest containing element" of your widget or widgets. 
>  
> I am specifically refering to the paragraph that says, 
> "Put it on the closest containing element of your widget, for example, the parent div of your element that is your outer most widget element. If that outer div wraps only widgets that need the application interaction model, this will make sure focus mode is switched off once the user tabs out of this widget."
>  
> My question is it ok to place it on the interactive element itself? Or will not having a parent div affect how screen reader software manages focus mode when the user tabs off of the widget?
>  
> Here’s a code snippet that is working nicely:
> <div tabindex="0" id="283-347-553-367" aria-label="‪Chemistry book" role="application" aria-roledescription="move in four directions">‪Chemistry book</div>
> <!-- On-demand help text -->
> <p description-283-347-553-367>Use arrow keys, or letter keys W, A, S, or D to move book or zoomed-in book up, left, down, or right.</p>
>  
> Note that we added an explicit aria-label to get all screen readers to read out the name of the widget.
>  
> Or is mark-up with an actual explicit application parent better? And  if so, how do we get an accessible name description read out. Would it be something like this:
>  
> <div id="283-347-553-367" role="application">‪
>                 <div tabindex=“0" aria-roledescription="move in four directions">Chemistry book</div>
> </div>
>  
> And I have a second question regarding multiple interactive widgets:
> We actually have two interactive elements, a Chemistry book and a Zoomed-in Chemistry book, perhaps it would be better to have both interactive elements within the same div that has the role="application"? Currently, we are implementing them seperately, each with their own application role?
>  
> We are role=“application” for these interactive items because they can be dragged in 4 directions, and no native HTML elements or ARIA roles do that.
>  
> Any thoughts are much appreciated.
> Taliesin Smith