E-mail List Archives

You are here: Home > Community > E-mail List Archives > View Thread

Thread: Overlay search box and screen reader modes

Number of posts in this thread: 5 (In chronological order)

From: Joseph Sherman
Date: Tue, Sep 10 2019 10:43AM
Subject: Overlay search box and screen reader modes
No previous message | Next message →

Hi all. I have a search box overlay that is launched when the user clicks on a Search button. I believe it uses role="dialog".

The search box opens and the user is put in the search field text box. There are also a couple of links in the overlay, but no plain text. In Windows, JAWS and NVDA go into 'forms' mode and the user can Tab through all items with no problem, and focus is trapped in the overlay. However if a user manually turns off 'forms' mode and goes into browse mode using the virtual cursor, they can access the content behind the overlay using the arrow keys.

The Mozilla developer pages<https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/dialog_role> have a note that "While it is possible to prevent keyboard users from moving focus to elements outside of the dialog, screen reader users may still be able to navigate that content virtually to use their screen reader's virtual cursor. Because of this, dialogs are considered to be a special case of the application role: They are expected to be navigated by screen reader users in a non-virtual navigation mode."

My question is whether users know to stay in forms mode in the overlay, or is being able to access the content behind the overlay using browse mode a problem? If it is a problem, what is a good way to trap the virtual cursor?

Thanks.

Joseph

From: glen walker
Date: Tue, Sep 10 2019 10:57AM
Subject: Re: Overlay search box and screen reader modes
← Previous message | Next message →

No, a user shouldn't be forced to stay in forms mode in your overlay.
Yes, being able to access content behind the overlay is a problem.

Support for role="dialog" isn't that great yet. If you were starting from
scratch, the easiest way to trap the virtual cursor is to make your dialog
container a sibling of your main content and then set aria-hidden on your
main content. Something like this:

<body>
<div>

</div>
<div style="display:none">

</div>
</body>

The dialog is hidden initially. When it's displayed, it's unhidden and
aria-hidden is set on the main <div>.

To prevent keyboard focus from moving out of the dialog (which sounds like
you're already handling), you can put an overlay on top of the main <div>
(using z-index) so that the overlay gets all the events and drains them.

If this is an existing page, you might not be able to refactor your
existing code to do this, but it might lead to ideas on how to fix what you
have.

On Tue, Sep 10, 2019 at 10:43 AM Joseph Sherman < = EMAIL ADDRESS REMOVED = >
wrote:

> Hi all. I have a search box overlay that is launched when the user clicks
> on a Search button. I believe it uses role="dialog".
>
> The search box opens and the user is put in the search field text box.
> There are also a couple of links in the overlay, but no plain text. In
> Windows, JAWS and NVDA go into 'forms' mode and the user can Tab through
> all items with no problem, and focus is trapped in the overlay. However if
> a user manually turns off 'forms' mode and goes into browse mode using the
> virtual cursor, they can access the content behind the overlay using the
> arrow keys.
>
> The Mozilla developer pages<
> https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/dialog_role>
> have a note that "While it is possible to prevent keyboard users from
> moving focus to elements outside of the dialog, screen reader users may
> still be able to navigate that content virtually to use their screen
> reader's virtual cursor. Because of this, dialogs are considered to be a
> special case of the application role: They are expected to be navigated by
> screen reader users in a non-virtual navigation mode."
>
> My question is whether users know to stay in forms mode in the overlay, or
> is being able to access the content behind the overlay using browse mode a
> problem? If it is a problem, what is a good way to trap the virtual cursor?
>
> Thanks.
>
>
> Joseph
>
> > > > >

From: Patrick H. Lauke
Date: Tue, Sep 10 2019 12:02PM
Subject: Re: Overlay search box and screen reader modes
← Previous message | Next message →

On 10/09/2019 17:43, Joseph Sherman wrote:

> My question is whether users know to stay in forms mode in the overlay, or is being able to access the content behind the overlay using browse mode a problem? If it is a problem, what is a good way to trap the virtual cursor?

You'd want to make the underlying page inert. Trap keyboard focus as
usual, but also hide the underlying page using aria-hidden="true",
removing it effectively from the accessibility tree and making it
unreachable via virtual cursor as well. Note that for this to work, your
dialog has to live outside of the container you're hiding, as you can't
have a container aria-hidden="true" and then "unhide" a child element.
So, you'd want something like:

<body>
<div ... aria-hidden="true">

</div>
<div role="dialog" ...>

</div>
<body>

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Jonathan Avila
Date: Tue, Sep 10 2019 12:07PM
Subject: Re: Overlay search box and screen reader modes
← Previous message | Next message →

I've heard some consensus though is that if the dialog has a proper role and focus stays in the box it would not be a WCAG failure though to not use aria-hidden on the content outside of it. I guess that is the real question. It's not always so simple to move the content to its own sibling div of the body and assistive technology like screen readers are getting better about hiding content outside of dialogs when aria-modal is present. So it seems maybe better solved at the AT level.

Jonathan

From: Patrick H. Lauke
Date: Tue, Sep 10 2019 12:18PM
Subject: Re: Overlay search box and screen reader modes
← Previous message | No next message

On 10/09/2019 19:07, Jonathan Avila wrote:
> I've heard some consensus though is that if the dialog has a proper role and focus stays in the box it would not be a WCAG failure though to not use aria-hidden on the content outside of it.

Tough one. Could arguably say that it's a failure of 4.1.2 because the
state/property of the underlying page being inert/inactive/hidden isn't
conveyed.

> I guess that is the real question. It's not always so simple to move the content to its own sibling div of the body and assistive technology like screen readers are getting better about hiding content outside of dialogs when aria-modal is present. So it seems maybe better solved at the AT level.

Yes, complementing the role="dialog" with aria-modal="true" (where
supported) would also work (in modern browser/AT combos that support it).

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke