Dialog Example Page: Add aria-hidden note

[DavidMacDonald]

The dialogue example correctly traps the tab focus forward and backward but the user can move out of the box while it is still active, with the virtual focus of a screen reader by arrowing up.

To reproduce open the dialogue box with a screen reader. Move virtual cursor backwards to the top of the dialogue and into the background content.

(Up arrow in JAWS/NVDA or CTRL+OPTION+LEFT ARROW in Mac VoiceOver) The image below is a screen shot of the virtual cirsor for VoiceOver in the background of the dialogue while it is open.

I wish there was an easier fix, bit I think it will require, aria-hidden=true on the background content of the page, and also a tabindex=-1 on every interactive element on the background page.

http://davidmacd.com/test/aria-hidden-test2.html

I put up a little test. The question was this,

"Does aria-hidden also hide the focusability of interactive children?"

The answer is no. However, in thinking this through, I think we can be OK with aria-hidden just on the background without tabindex=-1 while the dialogue is open. Here is my reasoning:

• The tab focus is properly trapping tab inside the dialogue
• If aria-hidden is on the background, then the screen reader user cannot move the virtual focus out of the dialogue nor can they move the tab focus out because of the previous bullet, and therefore there is no need to put tabindex=-1 on the background.

So if you can toggle aria-hidden="true" on the background div while a dialogue is open the problem will be solved.

I wish that adding aria-modal="true" would solve this with AT.

[mcking65]

@DavidMacDonald commented:

I wish there was an easier fix, bit I think it will require,  aria-hidden=true  on the background content of the page

David, please see the note about aria-hidden in the design pattern.

This is not what the note says ... But personally, even without screen reader support for aria-modal, I would not recommend using aria-hidden unless you plan to test and over test ... aria-hidden is a very sharp knife and using it dynamically like that is capable of unexpectedly amputating screen reader users in a way that is almost impossible for them to overcome unless they are handy with developer tools. I believe aria-hidden is most safe to use on elements that must always and forever be hidden and will never under any circumstance change ... until the thing that uses it dies.

The purpose of the APG examples is to demonstrate use of ARIA as intended by the specification. So, this example uses aria-modal and not aria-hidden. In addition to showing web engineers how to use these ARIA attributes, screen reader developers can use this example to test their support for the dialog role and aria-modal.

Net: this issue is a screen reader issue, not a bug in the example.

Side note: screen reader developers are free to include features in their products that allow their users to explore content outside of a modal dialog if they believe it will help their users have access that is more like what sighted users have. That said, the intent of aria-modal is to strongly indicate that only the dialog content is active and what is outside is either grayed out or not visible at all. The dialog is a window role, meaning that screen readers should provide boundaries that feel like window boundaries not like structural boundaries, e.g., table, region, list, etc.

[DavidMacDonald]

@mcking65
Dynamically adding aria-hidden and removing it is fairly common isn't it? Although I agree that poor execution of aria in general is a big problem, and understand that aria-hidden is a sharp edge.

How can we say the dialogue is modal, if the user can move out of it to the background with their virtual cursor. When I'm evaluating web sites, should I ignore that the background is darkened but the screen reader virtual cursor goes into the background.

This is the wild west days of accessibility so I'm all ears.

I think if the example is to remain without aria-hidden on the background. Perhaps
some explanation should be made in the example text, something like.

Note: the example does not employ aria-hidden on the background because the aria-modal attribute on the modal container is intended to replace the need for adding that on the background. Screen reader users may experience varying degrees of support for the aria-modal attribute as it is implemented by assistive technology.

[mcking65]

@DavidMacDonald commented

Dynamically adding aria-hidden and removing it is fairly common isn't it?

I have no idea how commin it is. I have not encountered it a lot. Accessible dialogs are rare. Among the accessible dialogs I have encountered, I think I have only suspected aria-hidden was being used maybe once or twice.

How can we say the dialogue is modal, if the user can move out of it to the background with their virtual cursor.

It is one thing to have some perception of the background. It is another for that background to be fully operable. If sighted users cannot operate it with either a keyboard or mouse, screen reader users will not be able to operate it. So, technically, that is modal.

When I'm evaluating web sites, should I ignore that the background is darkened but the screen reader virtual cursor goes into the background.

Definitely do not ignore this problem if it gives the screne reader user the ability to operate the background while sighted users cannot operate it. But, pun intended, we get into grey area here if the screen reader user can read greyed out text that sighted users cannot read.

Technically, by providing the ARIA dialog role and moving focus inside the dialog, site authors have done all that should be needed to communicate to screen readers where to read. A dialog is a window, and the screen reader should respect the window boundaries when reading.

That said, screen readers also have functions that allow reading outside the current window. That function should still work unless the dialog is marked modal, in which case the background should be hidden ... by the screen reader.

BTW, it is inappropriate to use aria-modal="true" on an ARIA dialog if sighted users can still easily read or operate the background.

This is the wild west days of accessibility so I'm all ears.

Let's keep taming the west ... peacefully.

I think if the example is to remain without aria-hidden on the background. Perhaps some explanation should be made in the example text, something like.

Note: the example does not employ  aria-hidden  on the background because the  aria-modal  attribute on the modal container is intended to replace the
need for adding that on the background. Screen reader users may experience varying degrees of support for the  aria-modal  attribute as it is implemented
by assistive technology.

We have a note on the design pattern that is similar to that. I think you are right that this is one of those cases where duplicating the note on the example page may be valueable, especially since the note is directly related to how people will experience that particular example. I will transform this issue into that action.

[DavidMacDonald]

BTW, it is inappropriate to use aria-modal="true" on an ARIA dialog if sighted users can still easily read or operate the background.

usually the dialogue is an overlay which obscures the background. And if the user interacts with the background by clicking on something the dialogue closes. I would mark that as aria-modal="true"

[mcking65]

Closed with c99876a.