WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Semi-inert modals

for

From: Birkir R. Gunnarsson
Date: Mar 31, 2022 1:04PM

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
>
> -----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.
> > > http://webaim.org/discussion/archives
> > > > > >


--
Work hard. Have fun. Make history.