WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Semi-inert modals

for

From: Bryan Garaventa
Date: Apr 1, 2022 2:53PM

Hi,
Honestly it doesn't matter what the semantics are or what it looks like visually. Non-sighted screen reader users can only perceive what has focus or where focus is contained within. In this case, this should be a focusable control or element within the dialog container when it is rendered.

Here is a simple example of this concept.
https://whatsock.com/Templates/Dialogs/Internal%20-%20Alert%20(Session%20Timeout)/index.htm

It doesn't actually matter how simple or complex the content of the dialog is, the concept of a dialog is basically a dynamic region that is rendered over preexisting content that needs to be interacted with by users when it is rendered. This may be something simple like a session timeout dialog, or something complex like a wizzard with multiple steps that stores data as the user interacts with it. Both of these, along with all the variations that can be used to represent something like this, can be represented as a dialog for assistive technology users.

Boiling down these concepts, all you need to do is ensure that the container has the correct roles and supporting attributes, move focus into the dialog when it is rendered (preferably at the beginning if there is a lot of content within it), do the same if this is a wizzard that opens another dialog after this one is interacted with, then after the dialog is closed move focus back to the triggering element if one is present. In the case of a session timeout dialog, focus does not actually need to move back to a triggering element because typically there isn't one.

As long as you move focus into the dialog when it is rendered, you don't need to manage focus separately from the header or footer, which sounds like it would be confusing.

There is another concept worth mentioning that isn't well represented in common patterns, mainly because it's hard to define due to its variability.

At times, it is necessary to display an overlay that is not useful to represent as a self-contained dialog. This is useful when rendering something that is part of the current flow but should not prevent users from navigating outside of it. Unfortunately the dialog role is not a good match for this, and there are none that can provide a one-to-one comparison within the accessibility API for this purpose.

I often refer to these as popups, though they can also be called overlays, etc. Here is an example of this.
https://whatsock.com/Templates/Popups/Internal/index.htm

In your case though, it sounds very much like a self-contained dialog is likely the right choice.

All the best,
Bryan


Bryan Garaventa
Principal Accessibility Architect
Level Access, Inc.
<EMAIL REMOVED>
415.624.2709 (o)
www.LevelAccess.com