WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Semi-inert modals

for

From: Birkir R. Gunnarsson
Date: Mar 31, 2022 11:04AM

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
> > > > >


--
Work hard. Have fun. Make history.