E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 17 (In chronological order)

From: Kian Badie
Date: Thu, Mar 31 2022 10:07AM
Subject: Semi-inert modals
No previous message | Next message →

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

From: Birkir R. Gunnarsson
Date: Thu, Mar 31 2022 11:04AM
Subject: Re: Semi-inert modals
← Previous message | Next message →

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

From: Bryan Garaventa
Date: Thu, Mar 31 2022 12:21PM
Subject: Re: Semi-inert modals
← Previous message | Next message →

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 ADDRESS REMOVED =
415.624.2709 (o)
www.LevelAccess.com

From: Birkir R. Gunnarsson
Date: Thu, Mar 31 2022 1:04PM
Subject: Re: Semi-inert modals
← Previous message | Next message →

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 ADDRESS 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 ADDRESS REMOVED =
> 415.624.2709 (o)
> www.LevelAccess.com
>
>

From: Kian Badie
Date: Thu, Mar 31 2022 3:46PM
Subject: Re: Semi-inert modals
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
> > 415.624.2709 (o)
> > www.LevelAccess.com
> >
> >

From: Bryan Garaventa
Date: Thu, Mar 31 2022 5:02PM
Subject: Re: Semi-inert modals
← Previous message | Next message →

"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 ADDRESS REMOVED =
415.624.2709 (o)
www.LevelAccess.com

From: Kian Badie
Date: Thu, Mar 31 2022 6:03PM
Subject: Re: Semi-inert modals
← Previous message | Next message →

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 ADDRESS 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 ADDRESS REMOVED =
> 415.624.2709 (o)
> www.LevelAccess.com
>
>

From: Bryan Garaventa
Date: Thu, Mar 31 2022 9:00PM
Subject: Re: Semi-inert modals
← Previous message | Next message →

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 ADDRESS REMOVED =
415.624.2709 (o)
www.LevelAccess.com

From: Kian Badie
Date: Fri, Apr 01 2022 11:23AM
Subject: Re: Semi-inert modals
← Previous message | Next message →

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 ADDRESS 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 ADDRESS REMOVED =
> 415.624.2709 (o)
> www.LevelAccess.com
>
>

From: Bryan Garaventa
Date: Fri, Apr 01 2022 2:53PM
Subject: Re: Semi-inert modals
← Previous message | Next message →

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 ADDRESS REMOVED =
415.624.2709 (o)
www.LevelAccess.com

From: jeffgutsell
Date: Sat, Apr 02 2022 2:02PM
Subject: Re: Semi-inert modals
← Previous message | Next message →

If Firefox and Safari finally supported the dialog element, would this simplify authoring accessible modal dialogs? It seems to me that this would be so.

Jeff Gutsell

From: Bryan Garaventa
Date: Mon, Apr 04 2022 11:05AM
Subject: Re: Semi-inert modals
← Previous message | Next message →

Hi,
It depends on what you mean by support.

The accessibility API can map the dialog element to the dialog role, which will provide the same feedback if the dialog is properly labelled. This is how an H2 element has the same feedback as role="heading" + aria-level="2", and to screen reader users there is no difference.

However, for this to truly be accessible, a dialog has to manage focus appropriately, which means that scripting is needed to do so. For the browsers to do this automatically, they would have to guess at what is meant to receive focus within the dialog when it is rendered, which will likely conflict with actual focus handling that is built into the dialogs. It may be possible to override this to some extent, but doing so would likely be very buggy.

Bryan Garaventa
Principal Accessibility Architect
Level Access, Inc.
= EMAIL ADDRESS REMOVED =
415.624.2709 (o)
www.LevelAccess.com

From: Kian Badie
Date: Mon, Apr 04 2022 4:09PM
Subject: Re: Semi-inert modals
← Previous message | Next message →

Hello,

Thank you very much for the very detailed explanation and examples! They
help a lot. I think I also want to make this a self-contained dialog and
manage keyboard focus to be trapped in the modal while it is open.

If mouse users are able to interact with content outside the modal (like
the header and footer), would that be considered inaccessible since it is
not the same experience? A keyboard user would have to close the dialog
before having access to the header/footer since keyboard focus would be
trapped within the self-contained dialog. It is indeed a different
experience with an extra step of closing the dialog to get to the
header/footer, but it seems to me that both experiences are accessible even
though they are different.

Thank you,
Kian Badie

On Mon, Apr 4, 2022 at 10:05 AM Bryan Garaventa via WebAIM-Forum <
= EMAIL ADDRESS REMOVED = > wrote:

> Hi,
> It depends on what you mean by support.
>
> The accessibility API can map the dialog element to the dialog role, which
> will provide the same feedback if the dialog is properly labelled. This is
> how an H2 element has the same feedback as role="heading" + aria-level="2",
> and to screen reader users there is no difference.
>
> However, for this to truly be accessible, a dialog has to manage focus
> appropriately, which means that scripting is needed to do so. For the
> browsers to do this automatically, they would have to guess at what is
> meant to receive focus within the dialog when it is rendered, which will
> likely conflict with actual focus handling that is built into the dialogs.
> It may be possible to override this to some extent, but doing so would
> likely be very buggy.
>
> Bryan Garaventa
> Principal Accessibility Architect
> Level Access, Inc.
> = EMAIL ADDRESS REMOVED =
> 415.624.2709 (o)
> www.LevelAccess.com
>
>

From: Bryan Garaventa
Date: Mon, Apr 04 2022 4:25PM
Subject: Re: Semi-inert modals
← Previous message | Next message →

"If mouse users are able to interact with content outside the modal (like the header and footer), would that be considered inaccessible since it is not the same experience?"

It will always be impossible to ensure the exact same experience between sighted mouse users and non-sighted screen reader users, but this is accounted for by ensuring proper focus management and the ability to access the same information using an intuitive process.

In this case, the user will be aware that a dialog has opened and that focus is contained within it, and if they wish to leave the dialog they can press Escape or activate the equivalent button for closing or canceling or submitting the dialog to close it and return focus back into the primary page content. This ensures the same level of access to the header and footer content that sighted users would have access to by seeing where it is visually, even though it takes a couple more steps for non-sighted users to do the same. This process is a common one though for dialogs of all tipes across various platforms, so it would not be inaccessible to do this.

Hopefully that makes sense.

All the best,
Bryan



Bryan Garaventa
Principal Accessibility Architect
Level Access, Inc.
= EMAIL ADDRESS REMOVED =
415.624.2709 (o)
www.LevelAccess.com

From: Kian Badie
Date: Tue, Apr 05 2022 3:11PM
Subject: Re: Semi-inert modals
← Previous message | Next message →

Hello,

That makes complete sense. So if I am understanding you correctly, it is ok
to have a couple of extra steps of closing the dialog for non-sighted users
to access the header/footer because the process is intuitive. Is that
correct?

If that is correct, I think that answers all the questions I currently
have. Thank you very much for the very educational and insightful
conversation! It helped a lot.

Thank you,
Kian Badie

On Mon, Apr 4, 2022 at 3:25 PM Bryan Garaventa via WebAIM-Forum <
= EMAIL ADDRESS REMOVED = > wrote:

> "If mouse users are able to interact with content outside the modal (like
> the header and footer), would that be considered inaccessible since it is
> not the same experience?"
>
> It will always be impossible to ensure the exact same experience between
> sighted mouse users and non-sighted screen reader users, but this is
> accounted for by ensuring proper focus management and the ability to access
> the same information using an intuitive process.
>
> In this case, the user will be aware that a dialog has opened and that
> focus is contained within it, and if they wish to leave the dialog they can
> press Escape or activate the equivalent button for closing or canceling or
> submitting the dialog to close it and return focus back into the primary
> page content. This ensures the same level of access to the header and
> footer content that sighted users would have access to by seeing where it
> is visually, even though it takes a couple more steps for non-sighted users
> to do the same. This process is a common one though for dialogs of all
> tipes across various platforms, so it would not be inaccessible to do this.
>
> Hopefully that makes sense.
>
> All the best,
> Bryan
>
>
>
> Bryan Garaventa
> Principal Accessibility Architect
> Level Access, Inc.
> = EMAIL ADDRESS REMOVED =
> 415.624.2709 (o)
> www.LevelAccess.com
>
>

From: Bryan Garaventa
Date: Tue, Apr 05 2022 4:38PM
Subject: Re: Semi-inert modals
← Previous message | Next message →

No problem, that does sound correct to me.

As long as you use the correct role and supporting attributes for the dialog markup, move focus into the dialog when it's rendered, manage tabbing correctly while focus is within the dialog, provide an intuitive mechanism/active element for closing or submitting the dialog, then move focus back to the triggering element if applicable after the dialog is removed, you should then have an accessible dialog.

Of course, you still need to make sure that everything the dialog contains is accessible, so please don't forget that part.

All the best,
Bryan


Bryan Garaventa
Principal Accessibility Architect
Level Access, Inc.
= EMAIL ADDRESS REMOVED =
415.624.2709 (o)
www.LevelAccess.com

From: Kian Badie
Date: Wed, Apr 06 2022 11:25AM
Subject: Re: Semi-inert modals
← Previous message | No next message

Sounds good! I will try to keep all of those things in mind. Thank you very
much!

Thank you,
Kian Badie

On Tue, Apr 5, 2022 at 3:38 PM Bryan Garaventa via WebAIM-Forum <
= EMAIL ADDRESS REMOVED = > wrote:

> No problem, that does sound correct to me.
>
> As long as you use the correct role and supporting attributes for the
> dialog markup, move focus into the dialog when it's rendered, manage
> tabbing correctly while focus is within the dialog, provide an intuitive
> mechanism/active element for closing or submitting the dialog, then move
> focus back to the triggering element if applicable after the dialog is
> removed, you should then have an accessible dialog.
>
> Of course, you still need to make sure that everything the dialog contains
> is accessible, so please don't forget that part.
>
> All the best,
> Bryan
>
>
> Bryan Garaventa
> Principal Accessibility Architect
> Level Access, Inc.
> = EMAIL ADDRESS REMOVED =
> 415.624.2709 (o)
> www.LevelAccess.com
>
>