WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Semi-inert modals

for

From: Kian Badie
Date: Mar 31, 2022 6:03PM

Very interesting and insightful. Thank you! If I may ask more, what is the
motivation for pushing a dialog to be a modal? While yes, I think there is
a substantial amount of content in this modal compared to a simple message
or notification, it does seem like making something modal only takes away
functionality for both sighted users and screenreader users. I can see a
notification or message being modal so that it can ensure that it is read
before closing. But in a situation where a modal is providing supplementary
content, why take away functionality like header access?

I hope this isn't coming off as disagreement, I am just genuinely curious.
In fact, as a developer I would just prefer to make it modal since it seems
more straightforward to implement. However, I would have to convince my
client before doing that.

Thank you,
Kian Badie

On Thu, Mar 31, 2022 at 4:03 PM Bryan Garaventa via WebAIM-Forum <
<EMAIL REMOVED> > wrote:

> "Do you have to make it known to screen readers that the focus order is
> changed because of the activated element? Or does the dialog role handle
> that already?"
>
> A dialog is simply a common widget type that non-sighted screen reader
> users are used to, so there is no need to notify users that the tab order
> has changed. When a dialog opens on the desktop and focus is set into it,
> it is expected that focus will remain in that dialog unless you activate a
> control or press Escape to close it. Any keyboard hints that are announced
> when the dialog opens are provided by the screen reader to assist
> navigation, but none of these should be hardcoded in the markup for the
> dialog, otherwise it will confuse users of differing device types such as
> mobile touch devices when they hear keyboard instructions that have no
> relevance in that environment. A datepicker is a complex widget type
> though, so it may be reasonable to provide some instruction when activating
> a help icon or some other mechanism. It just depends how complicated the
> controls are to operate it.
>
> If the dialog is large enough to cover the majority of the content, it
> probably would be a good idea to make this modal, especially if there is no
> specific reason for it not to be such as providing an outside toggle or
> related controls that a user would expect to retain access to while it is
> open.
>
> Whichever way you go, it is important to always ensure you can easily
> close the dialog from the keyboard or by activating a control for that
> purpose where a keyboard is not present. Many times I've encountered
> dialogs that assume keyboard access that could not actually be closed by
> touch on mobile devices because there was no mechanism provided for doing
> this when aria-modal was set to 'true' on a dialog role.
>
> Hopefully this helps a bit.
>
> All the best,
> Bryan
>
>
> Bryan Garaventa
> Principal Accessibility Architect
> Level Access, Inc.
> <EMAIL REMOVED>
> 415.624.2709 (o)
> www.LevelAccess.com
>
>