Website pop-up accessibility is a common digital accessibility issue that is vital to resolve in order for an inclusive web experience. Whether it's the infamous email sign-up form, a pop-up triggered by user action, an advertisement for an external website, or a prompt to agree to web cookies, pop-ups are unavoidable, online.
Though website pop-ups are notorious for having web accessibility flaws, they can be designed to limit associated shortcomings and directly support the pillars of digital accessibility. This post will discuss several critical accessibility-related factors when implementing web pop-ups. As always, I will speak from my perspective as a blind screen reader user.
Pop-ups contain hidden content until triggered. This reaction is triggered either by a specific user action taken, or by a preset behavior specified in the code—such as a pop-up automatically opening upon page launch.
One important thing to consider is that the user must always know that selecting a particular web element (button, link, tab) will launch a pop-up. Often when navigating a website, I find that activating a button with my screen reader takes me to a different and unfamiliar context.
This disorientation often results from activating a pop-up not properly notated in the webpage’s source code. As a screen reader user, I can't determine if clicking that button will launch the pop-up. When this continuously occurs on a site, it leads to a confusing and ineffective user experience.
Web pop-ups triggered by a specific user action need to be announced in advance. Any button, link or other interactive element that invokes a pop-up must communicate this behavior. For example, I recently visited a restaurant website. One of the buttons on the restaurant's reservation booking page is labeled: "Select number of guests, pop-up button." This label conveys to screen reader users that the item is a button that, when clicked, will launch a separate pop-up window.
Upon opening the window, the screen reader should clearly announce that the focus has shifted to a pop-up. The same approach should also be applied to the pop-ups that are not activated by user interactions. Suppose a pop-up launches automatically, such as with a time delay email list sign-up prompt. In that case, the screen reader must always announce that a pop-up has opened so I can contextually understand the content it contains.
One of the most frustrating parts about navigating pop-ups is the frequent challenge of trying to dismiss the window and continue with my initial task. For a screen reader user like me to dismiss the pop-up, there must be an easy-to-locate and clearly labeled button to close the window. I must find the button using manual tab-key navigation.
If I use my screen reader to filter and jump around by button only, the option to dismiss the window must also appear in the list. If you use a graphic to represent the dismiss pop-up button, ensure it is labeled in the code.
For example, many sites employ a small image of the letter X to signify the dismiss function. Suppose this button image doesn’t have any accessible name. In that case, my screen reader will announce vague, meaningless terms, such as “image" or “graphic.” A few common accessible names in this and other similar scenarios include:
As a good rule of thumb, all pop-ups on a site must comply with the same accessibility guidelines as the main page. As an example, all call-to-action buttons must have accurate and meaningful labels, and any external or internal links must be properly indicated. If the pop-up contains any images, appropriate alternative text descriptions must be in place.
Here’s an example that demonstrates a well-designed pop-up. For some background, I just placed my order on an e-commerce website. The site gave me two options: “Continue shopping” and “Provide feedback, pop-up button.” In this situation, I select the second button, which triggers a pop-up window.
The following dialogue represents each announcement from my screen reader as I navigate sequentially through the pop-up’s content:
This is a good example of an accessible screen reader pop-up experience. The button that invokes the pop-up indicates in its code that it will exhibit this behavior. All the content in the pop-up is screen reader detectable, including the two call-to-action buttons. Additionally, there is a straightforward way to dismiss the pop-up if I want to jump back to the main page quickly.
While they initially seem intimidating, pop-ups can be a meaningful part of any accessible website. If you design with best practices and people with disabilities in mind, pop-up accessibility can enhance your website's overall usability.
I hope this post provides some framework for site designers looking to create accessible pop-ups. I encourage you to leverage this knowledge when web accessibility testing to ensure your website is optimized for everyone visiting your site.
Pop-ups are just one of many elements on your website that require thoughtful design to meet accessibility standards. However, achieving an inclusive web experience involves addressing accessibility holistically—across your entire digital presence.
Suppose you're ready to take the next step in ensuring your website meets the latest global accessibility standards. In that case, we invite you to join our upcoming webinar, “5 To-Dos for Your 2025 Web Accessibility Program.”
This session will provide actionable insights to help your team build a comprehensive, effective accessibility program that benefits all users, including those with disabilities.
Sign up today to secure your spot!
Editor's Note: Our frequent contributor, Michael Taylor, wrote this post. This post reflects his opinions and experiences. Read more about Michael and some other posts on his experience online here.