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
>
> -----Original Message-----
> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
> Kian Badie
> Sent: Thursday, March 31, 2022 2:46 PM
> 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.
>
>
> 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
> > >
> > > -----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.
> > > > > > > > archives at
> > > http://webaim.org/discussion/archives
> > > > > > > > > > > > archives at http://webaim.org/discussion/archives
> > > > > >
> >
> >
> > --
> > Work hard. Have fun. Make history.
> > > > > > archives at http://webaim.org/discussion/archives
> > > >
> > > at http://webaim.org/discussion/archives
> > > > > >