Blogs

Modal accessibility

By Lauren Baroud posted 06-10-2021 14:27

  
Hello Community!

My question today is around accessibility for modals.

When a webpage loads, a screen reader will automatically start reading out everything on the page unless you begin to interact with the page. I was wondering if a modal should behave the same way when it's visibility is triggered by the user.

In the current case I am working with, once the modal is opened, the screen reader identifies to the user that the modal was opened and the focus state is on the modal's "close" button, but the content is not read automatically, only when you use a command. Is this enough to meet compliance?

Thanks,
Lauren
2 comments
68 views

Permalink

Comments

Talyah Aviran
02-23-2022 05:26

Hi Lauren,

Hope you received the information you were looking for but if not, here is my take on this.

A dialog has a role of a dialog. Each dialog has a heading at the top, usually h2 with a unique ID.

The dialog also has static content. Ensure the static content container has an ID as well.

Add aria-labelledby on the dialog container were the role dialog is defined, referencing the ID of the heading.

Add aria-describedby on the dialog, referencing the ID on the static content.

When the dialog invokes, send focus either to the close button or to the heading by defining it as an anchor: href="#" and tabindex="-1".

When the dialog is invoked, the screen reader will announce the heading of the dialog as its label and will also read the description/content of the dialog, depending on the verbosity level set on the screen reader by the user.

Hope this helps.

Supraja John
07-17-2021 18:09

Following this to see other perspectives.

On my end, I have seen this type of modals and recommend that close button content have visually hidden content that describes what the close button would be closing. A strong reason for such a descriptive content is that for screen reader users, this link would be contextually meaningful when links list is opened up containing many links on page.

For example: in an ecommerce shopping site, let's imagine a modal popups up with close button being the first element in it. It should have the following descriptive content: Close Coupon Offer Modal << the italicized content would be visually hidden but upon focus accessible to screen reader (in fact, if there are no qualms within the team, I would even suggest that the hidden content be visually seen upon focus, but this may not be the most desirable solution based on how the overall modal looks size-wise with this long copy wrapping around and pushing the length longer possibly.)

As for the content not being read automatically... since the focus would be on the close button upon modal opening, the screenreader reading the button copy seems like an expected behavior as I imagine the close button being on top of the modal. Then arrow keys or p keys in screenreader usage can be used to navigate through the rest of modal content under the close button. If the rest of the content is not being read despite trying to navigate via these common reading keys, then that seems an error.

WAI-ARIA has some notes on this that may be helpful as well:
https://www.w3.org/TR/wai-aria-practices-1.1/#h-note-7