9504 SW 32nd St, Oklahoma City, OK

Accessible Dialogs

Helping Others Technically with their Daily Challenges

TFCU dialog for logging into application

Here a pop up, there a pop up, everywhere a pop up! Dialogs are one of the most over used components on the web. They have been around for nearly the entire time that we’ve had modern browsers. They have always been problematic for users with disabilities, and we’re going to discuss some easy guidelines to improve the user experience and support accessibilities when you are developing your website.

Quick Do’s and Don’ts

  • Do not launch a dialog without the user’s intention.
  • Do not use a timer to launch it.
  • Do not use a mouse tracer to launch when the mouse hovers over the top of the browser window. 
  • Do not allow users to navigate out of the dialog via keyboard. Yes, I said it, keyboard trap the user on the dialog. 

Point of Initiation

Usually this is a button or link with the role of button that must be activated to launch the dialog. This button should include in the accessible name a note that it will launch a dialog. This note can be screen reader only and not visible on the screen. 

Management of Focus

When the activation element is activated, focus should move from it to the first active element on the dialog. On the other hand, when the dialog is closed, the focus should be set back to the point of initiation. This allows non-sighted users to build a mental model of the screen and depend on what happens upon initiation and closure.

Once more, focus should be trapped on the dialog and the user should not be allowed to tab out of the dialog at any time. The user must be allowed to close the dialog with a button with the accessible name of “close” or “close dialog” and the best practice is to allow a user to activate the “esc” key as a secondary way to close the dialog. 

Most likely you will need javascript to support all of this, so look around on the web for solutions, but make sure the behaviors described here are present in your final product.

Dialog Labelling

Dialogs must also support the screen reader users with a unique name. Using aria attributes, a developer can easily set the name of the dialog in two ways, but one is the preferred method. The preferred method is to have a heading element with the unique name on the dialog to support sighted users, and sighted users with cognitive differences. Add a unique id attribute to this heading element. Then on the outer div that encapsulates the dialog code you will add an aria-labelledby attribute with the value of that heading id.

The Final Word

If you follow the guidance described here, you will mitigate most if not all of the issues you face in accessibility for the dialog. This guidance does not cover things like forms inside the dialog or the differences between dialogs and notifications – they are not the same. Reach out to the team if you have more information or you have a project we can help you with!