WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Semi-inert modals

for

From: Kian Badie
Date: Mar 31, 2022 3:46PM

Thank you both for the input! First, here (
https://www.cellstructureatlas.org/1-10-putting-it-all-together.html#clem)
is an example of the exact thing I am working on with the modal already
opened if you are interested. Now that you bring up making the dialog fully
modal, I am realizing that the dialog appears fully modal on mobile since
there is less space. On desktop, if a user activates a link in the
header/footer the modal will not persist and it will navigate to the new
page. If another element is activated in the header (like search or opening
navigation menu) it will appear over that modal window. While I think this
makes sense at a glance, I would understand if this is bad accessibility
practice and I would want to see what I could change to make things better.
I suppose users don't need access to the header/footer while the modal is
open. However, it does feel a bit weird to have supplementary content take
up more space than the main content. I guess that is part of the reasoning
for the semi-modal dialog. But I am open to suggesting to my client to make
it fully modal on desktop too if that is the best practice to do.

The date picker example is interesting. It traps keyboard focus without
announcing anything. With both that and Birkir's suggestion of modifying
the tab order of the page, I do have a question. 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?

Thank you,
Kian Badie

On Thu, Mar 31, 2022 at 12:04 PM Birkir R. Gunnarsson <
<EMAIL REMOVED> > wrote:

> Oh, just to clarify, there are a lot of cases for non-modal dialogs as
> Bryan pointed out.
> I am confused by the need for a semi-modal dialog, a dialog that
> blocks interaction with the entire main content of the page while
> allowing interactions with the page header and footer.
>
>
> On 3/31/22, Bryan Garaventa via WebAIM-Forum
> < <EMAIL REMOVED> > wrote:
> > Hi,
> > Actually there are use cases for non-modal dialogs. Here is one, a
> > datepicker where it is still possible to interact with background
> content.
> > https://whatsock.com/Templates/Datepickers/Basic/index.htm
> >
> > From a keyboard perspective on Windows using a screen reader like JAWS or
> > NVDA, the dialog seems modal because the user perspective is confined
> within
> > the dialog content. However, this is not true for touch device users
> such as
> > those using VoiceOver on iOS for example. In this last case, it is
> possible
> > to interact with the background content, which is important because the
> > triggering element is actually a toggle that can be used to dismiss the
> > dialog by touch.
> >
> > There are times when it is important to implement a non-modal dialog,
> and in
> > this case, adding aria-modal="true" will actually impaire the
> accessibility
> > of the widget by hiding the background content from iOS touch device
> users
> > by making the background content inaccessible. This automatically occurs
> > without the use of aria-hidden within this environment.
> >
> >
> >
> > Bryan Garaventa
> > Principal Accessibility Architect
> > Level Access, Inc.
> > <EMAIL REMOVED>
> > 415.624.2709 (o)
> > www.LevelAccess.com
> >
> >