What is the expected behavior for an accessible name with role=application

[jessegreenberg]

@zepumph and I discovered that role="application" will change the bahvior for how the accessible name is set. For instance, the following element has Accessible Name "Chemistry Book"

<div tabindex="0">Chemistry Book</div>

while this element has an empty accessible name

<div tabindex="0" role="application">Chemistry Book</div>

And so NVDA will not read "Chemistry Book" when focusing this element.

Even more strange is that when wrapping the element in another with role="application", the inner content becomes the accessible name in Chrome, but not in Firefox.

<div role="application">
  <div tabindex="0">Chemistry Book</div>
</div>

We verified this by looking at the accessibility tree inspection tools in Chrome and Firefox, and also discovered that NVDA will not read the accessible name when focusing these elements.

We did find that using aria-label will define the accessible name as expected so we are going to proceed with using that attribute on things with role="application" (particularly in the upcoming friction prototype).

@terracoda is the behavior you would expect for accessible name? Perhaps because "application" is considered a "landmark", that has something to do with the way it impacts the AccessibleName? We can also go into more detail in an upcoming a11y meeting.

[zepumph]

We think we should discuss this in next week's meeting (although I won't be here).

[terracoda]

@jessegreenberg, yes, I was assuming that inner content would always be accessible, but it seems the algorithm is different with role application. I am still trying to fully understand the checklist provided in Using ARIA section 2.12 Custom Control Accessible Development Checklist.

It seems an inner element with inner content is needed, not just inner content. In the case of Friction, I am not sure what element is best. aria-label on an inner div element will work. I'll have to investigate to see if a semantic element would provide a better experience. An inner div witharia-label should work for now.

[jessegreenberg]

Thanks @terracoda, sounds good. I will also be gone for next weeks meeting so it may be best to discuss this on 8/14/18.

[terracoda]

This issue is related to a question I asked in https://github.com/phetsims/friction/issues/92. In VoiceOver I don't hear the accessible name in some contexts.

[jessegreenberg]

@terracoda said on 9/4/18 meeting that if you use aria-label, it will override whatever else would create the accessible name.

For now, we can use aria-label with a dual label moving forward, and watch for duplication of the label in the output.

[jessegreenberg]

@terracoda said that it would be good to do an HTML validation first before closing.

[jessegreenberg]

I tested it at https://validator.w3.org/ and got

👍

[terracoda]

@jessegreenberg, @zepumph and @emily-phet, I am sorry I was not fully grasping this issue yesterday. I still think it is safe to move forward with the single div with an aria-label, but I would like to get some feedback from the wai-aria interest group.

My main concern/question is this paragraph: "Put it (i.e., role="application") 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."

Will we get better (more consistent behavior) with a parent div with role application or the role directly on the interactive widget, in this case the Chemistry book. Also wondering if it is feasible to have one containing div for both interactive widgets, Chemistry book and Zoomed-in Chemistry book, and how the labeling/naming would work in that case.

So, just re-opening to post a question to the wai-aria interest group list.

[terracoda]

I did get feedback from the wai-aria interest group, and the code I shared at the time was determined to be acceptable.

Code in email that we were using (i.e., without parent):

<div tabindex="0" id="283-347-553-367" 
aria-label="‪Chemistry‬ book" 
role="application" 
aria-roledescription="move in four directions">‪Chemistry‬ book</div>

Code sample in email without parent:

<div id="283-347-553-367" role="application">‪
    <div tabindex=“0" aria-roledescription="move in four directions">Chemistry‬ book</div>
</div>

Comment 1

My point of view and is coming from a non-technical side of things. If you have tested this with multiple screen readers and browsers, and find the solution works. Then you have answered your question. Don’t forget to test on mobile, windows, Mac and possibley even Linux (desktop os in that order). The key is the standards are a guide and testing is the proof of the pudding. (Seam Murphy, Sept. 7, 2018).

Comment 2

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, Sept. 7, 2018)

Based on the comments above, our approach was fine. The grab/drag interaction has evolved since this issue was opened. We now have a common accessible grab/drag interaction.

Closing this issue.