WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Semi-inert modals

for

From: Bryan Garaventa
Date: Apr 1, 2022 2:53PM

Hi,
Honestly it doesn't matter what the semantics are or what it looks like visually. Non-sighted screen reader users can only perceive what has focus or where focus is contained within. In this case, this should be a focusable control or element within the dialog container when it is rendered.

Here is a simple example of this concept.
https://whatsock.com/Templates/Dialogs/Internal%20-%20Alert%20(Session%20Timeout)/index.htm

It doesn't actually matter how simple or complex the content of the dialog is, the concept of a dialog is basically a dynamic region that is rendered over preexisting content that needs to be interacted with by users when it is rendered. This may be something simple like a session timeout dialog, or something complex like a wizzard with multiple steps that stores data as the user interacts with it. Both of these, along with all the variations that can be used to represent something like this, can be represented as a dialog for assistive technology users.

Boiling down these concepts, all you need to do is ensure that the container has the correct roles and supporting attributes, move focus into the dialog when it is rendered (preferably at the beginning if there is a lot of content within it), do the same if this is a wizzard that opens another dialog after this one is interacted with, then after the dialog is closed move focus back to the triggering element if one is present. In the case of a session timeout dialog, focus does not actually need to move back to a triggering element because typically there isn't one.

As long as you move focus into the dialog when it is rendered, you don't need to manage focus separately from the header or footer, which sounds like it would be confusing.

There is another concept worth mentioning that isn't well represented in common patterns, mainly because it's hard to define due to its variability.

At times, it is necessary to display an overlay that is not useful to represent as a self-contained dialog. This is useful when rendering something that is part of the current flow but should not prevent users from navigating outside of it. Unfortunately the dialog role is not a good match for this, and there are none that can provide a one-to-one comparison within the accessibility API for this purpose.

I often refer to these as popups, though they can also be called overlays, etc. Here is an example of this.
https://whatsock.com/Templates/Popups/Internal/index.htm

In your case though, it sounds very much like a self-contained dialog is likely the right choice.

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: Friday, April 1, 2022 10:23 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.


I see. In my reading up on the accessibility of modals, the use cases described focus on what you have defined with modals being important messages to interact with. It is interesting to see some examples online where modals are being used to store additional content. For example, clicking on a collection of images opens a gallery like image viewing modal. Or, like the site I'm working on, the modal contains additional information. I think that causes confusion for me because it makes me think that additional content in the modal should only cover the main content, not the whole page like a important message would.

So if I were to manage the focus between the header, the dialog, and the footer while the dialog is opened above the main content would the dialog still be considered a dialog? Or is it semantically something different now?

Thank you,
Kian Badie

On Thu, Mar 31, 2022 at 8:00 PM Bryan Garaventa via WebAIM-Forum < <EMAIL REMOVED> > wrote:

> No problem. 😊
>
> Modals are important when it is necessary for the user to interact
> with it before they are permitted to continue interacting with the page. E.G.
> Session timeout dialogs, login prompts, wizards, and many others.
>
> It is especially important to implement modals properly to ensure that
> the background content is hidden from screen reader users, otherwise
> it is possible for the user to accedentally get lost in the background
> content when navigating instead of interacting with the dialog as they
> are supposed to be doing. This is critical when dealing with license
> agreements and other prompts that must be acknowledged, or when
> navigating wizards that require a particular order to be followed when completing form data.
>
> The issue with exposing the header and footer is not really the
> problem, but rather, if the user is interacting with the header or
> footer content, they will also have access to the background main body
> content as well and will not be interacting with the dialog as
> expected, nor will they be able to reliably identify where it is
> located in the page. This is always an issue when using a screen
> reader such as JAWS or NVDA on Windows where the Virtual Cursor or
> Browse Navigation allows the user to move around within a virtual
> representation of the page content instead of what is on the top layer as occurs with VoiceOver on iOS (when touching and not swiping.).
>
>
>
>
> 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 5:03 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.
>
>
> 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
> > #c
> > lem) 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
> > > > > >
> > > > > > archives at http://webaim.org/discussion/archives
> > > > > > > > archives at http://webaim.org/discussion/archives
> > > >
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> >