WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Semi-inert modals


From: Bryan Garaventa
Date: Mar 31, 2022 12:21PM

Actually there are use cases for non-modal dialogs. Here is one, a datepicker where it is still possible to interact with background content.

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.
415.624.2709 (o)

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Birkir R. Gunnarsson
Sent: Thursday, March 31, 2022 10:05 AM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Semi-inert modals

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

ARIA Authoring Practices is not prescriptive/normative, while it is a great guideline.
If we think about this from the user's perspective, which is the ultimate end goal, a user with a mouse is not able to interact with the main content of the page, so we must create the same affordance to someone using keyboard or a screen reader, or as close to that as possible.
This means
* Hiding the main content of the page from a screen reader (you can add aria-hidden="true" on the main content container, provided that the modal dialog element is not a child of the main content container).
Block keyboard navigation to the main content, by setting tab key JavaScript on the last focusable element in the header to either go to the footer or the semi-modal dialog, ditto shift-tab on the first focusable element in the footer.

Would it be possible to request a design change to make the dialog fully modal? Are there strong reasons why the user would want the dialog open while being able to navigate in the header/footer? What happens if the user activates a link in either the header or the footer, does the modal go away and a new page loads, or does the modal stay open obscuring the main content of the new page?
In either scenario I don't quite see why any user should have access to header or footer while the dialog is open.

On 3/31/22, Kian Badie < <EMAIL REMOVED> > wrote:
> I have a modal element that does not make all outside elements inert.
> The modal covers the content window, but does not cover the
> header/footer elements. Therefore, mouse users are able to have the
> modal open while accessing the nav menu, search, and other controls.
> The modal still makes the inner content window inert (inner content as
> in everything in between the header/footer). I figured I should still
> treat it as a modal (as described by
> https://www.w3.org/TR/wai-aria-practices-1.1/#dialog_modal), however
> the aria practices state:
> "So, mark a dialog modal only when both:
> - Application code prevents all users from interacting in any way with
> content outside of it.
> - Visual styling obscures the content outside of it."
> So treating my modal as an actual modal would break that rule. Since
> it only made the inner content window inert, I leaned towards marking
> it up as a modal. Mouse users would still have access to the
> header/footer components and keyboard users could still access
> header/footer stuff by exiting the modal. However, it doesn't sit
> completely well to go against what I quoted from the aria practices.
> The alternative seems to not mark it up as a modal and manage tab
> order to tab through the header, modal, and footer elements to ignore
> the content underneath the "modal". But how would that be communicated
> in the markup/to screen readers? That doesn't feel right either. If I
> had to pick between the two options, it seems that marking it up as a
> modal is the better option, but I wanted to see if I could get any second opinions.
> Thank you,
> Kian Badie
> > > archives at http://webaim.org/discussion/archives
> >

Work hard. Have fun. Make history.