Dialog modal popover

All right, let’s talk about dialog modals, sometimes called popovers, and what you actually need to know right now.

This information is adapted from atomica11y.com, atomica11y.com, and from thebookonaccessibility.com.

Now, you notice this lesson isn’t titled accessible Dialog Modals, because if you create a dialog modal that isn’t accessible, all you really did was create crappy decoration, and that’s not what we’re here to do today.

Now, we can’t possibly cover every and nuance about accessibility in this single lesson, but we can cover the practical basics about dialog modals so that after this, you’ll understand that there are requirements they have to meet, what those are, and you can come back and reference this information later. There are complete demos and examples on atomica11y.com for design, web, iOS, and Android, and complete acceptance criteria for every single one of those cases.

To be sure, we’re talking about the same thing. Most commonly, this involves a dialog a dialog modal that includes some information or action and the ability to close that modal, or an alert dialog that contains some action that is mandatory and is not dismissible until that action has been performed. There are variations of dialog modal, sometimes called a bottom sheet or a side sheet, that follow the same rules.

It’s important we understand the purpose of a dialog modal. Dialog is a conversation, and modal means separate mode. A dialog modal is an interruption to the flow the customer is currently engaged in so that we can have a related and focused conversation.

To make a dialog modal accessible, we have to accommodate the following disabilities. Beginning with low vision. We’re talking about people who may be adjusting the font size on their devices. They may be using a magnification app that zooms way, way in on their screen, or on a handheld device, they may be pinching and zooming in to see things in greater detail. Not everyone perceives color the same way. We generally call this color blindness. One in twelve men and one in 200 women are unable to perceive the differences between certain colors. So we can’t use color as the only way that we convey meaning. When we’re talking about motor disabilities, we’re talking about people who are unable to use a mouse or tap on their screen or are unable to do so with precision. They may be using their keyboard, a Switch device, which is something akin to a game controller, or a voice command to interact with their device. And when we’re talking about blindness, we’re generally talking about people who are using smartphones, they’re using laptops, but they’re unable to see the screen. They will be using an application called a screen reader in combination with their keyboard or swiping and tapping on their handheld device in a specific sequence in order to interact with their device.

Beginning with low vision, we want to accommodate people who adjust the default text size on their devices. Now, these are people who would say they don’t even have a disability. They’ve just bumped up the text size on their phone so so I can read the text more easily. Text must be able to resize up to 200% with no loss of information. This is different from hitting Command or Control plus on your browser and zooming in in that way. This is literally changing the size of the fonts by default.

We also must ensure that text has a minimum of 4.5 to 1 contrast against its surroundings. The close button must have a 3 to 1 minimum contrast ratio, and any backdrop behind the modal must make it clear that this is a modal and not a new page.

For people with low vision, it’s important that we don’t take over the entire screen with a modal. When a modal takes over the entire screen, it’s very easy for people to believe they have gone to a new page. Rather than close the modal, they may try to go back in their browser. And we don’t want to dissociate the close button from the dialog.

Full screen takeovers and modals that move the close button outside of the dialog are also difficult because if they’re using a magnification tool that allows them to zoom way, way in on their screen like this, it’s very difficult for them to understand they are in a modal and to how to close that modal.

We cannot use color as the only way we convey meaning. One in twelve men and one in 200 women perceive to be colored differently. For example, people with red-green color blindness won’t be able to tell the difference between those two buttons.

For people with motor disabilities that keep them from being able to click or tap with precision, we want to provide generous target areas for them to interact with our modal. The click or tap target area must be no smaller than 24 by 24 pixels. To meet AAA requirements, the click or tap target area must be no smaller than 44 by 44 pixels.

When we’re talking about people using assistive technology, there is a specific set of keyboard and screen reader actions that we must follow. For someone using their keyboard or a screen reader in combination with a keyboard, when they activate the launch button for the modal, they will see or hear that the dialog opens. Arrow keys browse content within the dialog. The The tab key moves focus visibly to interactive controls in the dialog, starting with the first control, typically to close button. The escape key must close the dialog and return focus to the button that launched it, unless it’s an alert dialog that requires completion of a task within the modal. The space bar activates any buttons, and the enter key activates any links or buttons that are in focus. For people using a handheld device, when they swipe, focus will move within the dialog, and when they double tap, this activates most elements within the dialog. For people using screen reader, they must be able to understand the name, role, and state of the modal. On launch, the dialog must describe its purpose or title. It should describe itself as a dialog. It should be clear that the user is in a dialog because content behind the dialog remains completely inert.

Here we see focus moving from the close button to the continue button and not leaving the dialog. But it is okay for focus to leave the window and enter the browser controls.

Content must always remain inert behind the dialog. The focus indication must be visible in some way to meet AA requirements or have a three to one minimum contrast ratio to meet AAA requirements.

Things you should know button. Now, let’s watch a screen reader demo. Close button. Things you should know. Web dialog. You heard the close button is in focus and the name and role of the dialog. Continue button. Close button. Continue button. Focus stays within the dialog and does not enter the background of the modal.

Every dialog needs a name. There are different ways to accomplish this. In this case, the a labelled-by attribute, points to the heading level 2 that names the dialog. The reason we don’t use a heading level 1 inside the dialog is we want to reserve that for the main title of the page. A heading level 2 is perfectly appropriate for a modal dialog.

Let’s be careful not to misuse dialogs. Don’t use modals just to save space. Just write fewer words and trust that people know how to scroll. Cramming content into modals just to get above the fold is not content strategy. Placing additional information about a form field or some feature of your website inside of a modal just interrupts people from the flow they were already on. Oftentimes, it’s better to simply place that information where people already are interacting with your application or website.

Please don’t inject modals that are not related to the current customer’s journey. How many times have you been interrupted from a purchase flow to take a survey about your experience on a website? This is disruptive for people without disabilities, and it’s very disruptive for people with disabilities. Interacting with the modal, understanding what it is, and closing it is a severe interruption, especially for people using a screen reader.

And don’t require decisions based on additional sources of information that aren’t included in the modal. I think we’ve all experienced something like this where we’re required to make a very important irrevocable decision that has huge consequences, but we aren’t able to go and reference the information about which we’re making the decision.

This is especially challenging for someone who has a memory disability or just someone who is taking medications right now that’s making them feel groggy.

First of all, if there is so much content that you’re putting in a modal that it must scroll, you should really just reconsider your design decisions. A modal may not be the best component for this, but if you are forced to make a scrollable modal, make the entire modal scrollable. Do not put a small scrollable inset inside of the modal.

Now, what are some reasons to break these accessibility rules? Are there times when it’s okay to deviate and go do something interesting or clever? Maybe you saw Apple or Google do this. Despite the fact that they’re big, successful companies, just because Apple or Google do something, doesn’t mean that they had people with disabilities in mind when they did it. Maybe your manager thinks that an inaccessible pattern just looks cooler. As a designer, as a developer, it’s your job to advocate for people who are using your products. Do the right thing. Maybe people are saying, But we’re on a tight deadline and we don’t have time for accessibility, but that’s absolute nonsense. It doesn’t take any longer to produce an accessible modal than it does an inaccessible one. Maybe your developers are telling you that it’s not possible to create an accessible modal, but I can assure you they are wrong. There are plenty of examples on atomica11y.com that include code they can use to create an accessible modal with very little effort.

And that’s the end. Go forth and come back when you need help. You can always find more information on atomica11y.com. And if you’re building an enterprise accessibility program, thebookonaccessibility.com is for you. Thank you.