The Australian Government coat of Arms

Communities of practice

Communities of practice

Modal alert

Might be somewhat controversial as modal’s in general usually don’t pair well with accessibility standards however, it might be worth discussing as a community that if somebody had to implement this component, let’s make it as good as possible.

1 Like

I’m in agreement with @adamzerella. While modals are not exactly great accessibility practice, I unfortunately I’ve been requested to implement one.

There are ARIA guidelines on best practices, so I think a dialog/modal component following them would be of benefit.


Considering that implementing a robust and tested modal component should take a considerable amount of time, I think our solution for now should be to specify some solid guidance on why modal dialogs should be avoided and why.

It should be on the table as a proper component later on but for now, we should just refer users to some rationale and guidance on this topic.

My colleague whipped up a (first visit only, dismiss-able) modal on our National Redress website:

The idea for it is to serve as a content warning on the potentially distressing nature of content on the website.

It’s probably not perfect when it comes to a11y. In the sense that focus can be tabbed right on though and onto the rest of the website content. But that may not even be a bad thing for screenreader users.

1 Like


It might not be that great with the a11y, as you said but it’s a start! We might pursue some screenreader testing with this kind of thing at a later time :slight_smile:

Probably not much chop for mobile/responsive either.

A handful of years ago I did use a chunk of jQuery that could get the target of an anchor tag (using ajax). And open it into a modal.
So a link with class=“modal” to a URL like /your-feedback-page#form could open just that #form into the modal.

At the time I remember putting in a bit of effort to get the a11y support down-pat. It had a bit of ARIA, and I tried to get the tabbing order working right.
But by today’s standards it was probably pretty sketchy.

A bonus was that it could be set to only open as a modal above the 720px breakpoint, for example. So for phone/tablet users (or if you open link in new window) the link would be just like any other regular link.

I’ve put the code into a gist if anyone is interested.

On we’re using tingle.js, a vanilla JS modal plugin.
There were efforts to make it more a11y friendly, might be worth a second bash as it’s quite a great little plugin.

The WAI ARIA authoring practices has a great example of what to be mindful of when making modals accessible

Adding role=dialog to the container helps assistive technology users understand the content is in a dialog but you also need to use good labelling of the dialog and manage the keyboard focus to remain solely inside the control with the tabindex attribute and move back to the original position when the dialog is closed.

I’m working on a project at the moment where tabbing past the last item within an open modal dialog gives focus to the browser chrome. And thus the broader operating system.
So user can tab through the modal > then up to the current document tab > then the address bar > then back into the document (on the first item within the still open modal).
Just like what would happen when tabbing past the last focusable item on any regular webpage.

What are your thoughts on this? I’m of mixed opinions.
I do remember reading in a few spots about how focus should loop around inside the active modal dialog. But on the other hand, I wouldn’t want to be creating a sort of semi keyboard trap, by prevent users access to their own web browser controls & operating system.

What if the modal is asking a question that they need to switch to a different tab to find the answer for?

I’d say that’s a pretty unique edge case and I don’t imagine there are many situations requiring a user to tab outside of a modal. So if a question is asked, make it easy for the user to answer the question. If they have to move to another tab there’s possibly a better way of doing that workflow.

If the tab is contained within a dialog, and the dialog can be dismissed by either clicking a button or the close icon on the top right that is better for accessibility. If a keyboard user jumps out of the dialog and begins tabbing to content beneath the modal (with the modal still visible) it begins to make things difficult for the user.

This post does a great job of discussing the technical detail

No disagreement about the definition of a modal dialog.

My point is, within our websites, we shouldn’t be preventing our user from being able to flip away from a window with an open dialog - if they wish to get back to it later.

I think this is where our thoughts differ, I don’t think that would pass an accessibility check if that’s the case.

Even with an open dialog, you can use keyboard shortcuts to change browser tab or window, so the user isn’t completely stuck when the dialog is open. They should also still be able to use keyboard shortcuts to access the browser’s or OS’s menus.

If they want to do something within the contents same tab they should have to close the dialog first. If they can press escape to close the tab without having to specifically focus a close button then that’s pretty quick and easy.

System generated dialogs (i.e., using the webAPIs allert() or prompt()) trap keyboard focus within them (i.e., do not allow focus out of the dialog) and this is how support is heading for the HTML element. A close cross might be unnecessary, but no such modal dialog (i.e., not a modeless window) should be implemented without listening for the ESC key. Many accessibility issues are the result of indifferent interaction design or giving over to second-rate tooling.

1 Like