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

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
415.624.2709 (o)
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), 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