Zoom Testing for Web Accessibility: A Quick Guide

Every developer and web designer should perform manual checks to ensure that content works for people with disabilities. After all, accessibility isn’t optional and if it isn’t part of your process, you’ll spend more time (and money) fixing issues.

One of the easiest ways to test content is to simply “zoom in.” Many people with vision disabilities don’t use screen readers (software that outputs text as audio or braille). They simply scale the size of the content using their web browser’s built-in tools — and you can do the same to find issues that might impact those users. 

Zoom testing helps you verify conformance (or non-conformance) with several requirements from the Web Content Accessibility Guidelines (WCAG), particularly WCAG 1.4.10, “Reflow.” That criterion requires that content reflows into a single column without loss of information or functionality, and without needing horizontal scrolling, when the page is zoomed up to 400%.

In this article, we’ll explain how to use zoom testing to improve digital compliance. We’ll also provide some tips for getting the most out of manual accessibility checks.

Before zoom testing, perform an automated accessibility test. 

While this isn’t strictly necessary, automated tests will help you identify and fix many issues that can be extremely frustrating for users with low vision (and frustrating for manual accessibility testers — that’s you). 

That includes things like missing form labels, missing alternative text (alt text), redundant hyperlinks, and poor color contrast. To perform an automated test:

1. Choose a tool. We're partial to AudioEye’s Website Accessibility Checker; AudioEye also has a list of other automated accessibility testing tools, some of which are more appropriate for certain workflows and development strategies.
2. Run the test. Many free tools can only test a single page; paid tools may be able to audit your entire website, which may be preferable depending on the scope of your project. 
3. Review the output. Remember, automated tools are prone to false positives (reporting problems that don’t exist) and false negatives (missing issues that require a fix). Don’t assume that your tool is perfect; review each issue and determine whether it actually impacts users with disabilities.

We recommend automated testing as a first step for several reasons. First, it’s easier than jumping in with a zoom test or screen reader test — particularly if you’re new to the best practices of web accessibility. Secondly, it can save time and make manual testing more productive. 

An accurate automated test can also help you structure your manual tests. When you know where your website is succeeding — and failing — it’s a lot easier to figure out a game plan. 

Related: What’s the Difference Between Manual and Automated Accessibility Testing?

Zoom your web page to 200% at first.

While 400% is the benchmark for WCAG’s “Reflow" requirement, going straight to 400% may be overwhelming. 200% is a practical starting point — generally, if things are going to break, they’ll start breaking around that threshold.

With that in mind, we’ll test using an incremental approach. Use your browser's built-in zoom function (typically Ctrl or Cmd and the '+' key) to increase the magnification level 200%, and then further towards 400%.

At each level, carefully examine the page layout and functionality. Look fo the following:

• Reflow: Does text wrap correctly within the viewport width, forming a single readable column? If zooming forces you to scroll horizontally to read lines of text, it’s a WCAG failure (and bad for users). 
• Overlapping Content: Do elements (text, images, buttons, containers) overlap each other, obscuring information or controls?
• Functionality: Are all interactive elements like menus, buttons, form fields, and controls still visible and fully usable? Can you complete essential tasks?
• Readability: Is text still clear and legible? Does any text become too small, too large, or distorted?
• Information Loss: Does any content disappear or become inaccessible when zoomed?

When you’re testing, test everything. Pay close attention to images, multimedia players, headers, footers, and interactive elements. Open up sidebar menus and fill out forms. Your audience will be using your entire website, so test every element! 

Perform zoom tests and screen reader tests — but don't do both at the same time.

Conduct zoom testing and screen reader testing as separate, focused sessions to ensure thoroughness and accuracy for each accessibility requirement.

Zoom testing and screen reader testing are essential manual checks, but they address the needs and expectations of different types of users. For that reason, we recommend performing one type of check at a time. 

Another important note: Screen reader testing works best when performed by accessibility experts who have significant experience with screen readers. While developers can (and should) try screen readers like JAWS and NVDA, remember that building proficiency with a screen reader takes time.

To learn more, read: 

• Should Web Developers Perform Screen Reader Testing?
• What Is the Best Browser for Testing Screen Reader Accessibility?
• JAWS Screen Reader: An Overview for Developers and Content Creators.
• NVDA Screen Reader: An Overview for Developers and Content Creators.

Document every issue you encounter when manually testing for accessibility issues.

Whether you’re working on your own or sending the results of your test to a development or design team, you need to write everything down. Logging issues serves a few crucial functions: It helps you keep track of what needs to be done, communicate the necessary changes to your team, and track your progress. That can be beneficial for demonstrating compliance with the Americans with Disabilities Act (ADA) and other laws.

You can document your testing however you’d like, but be consistent. We recommend keeping track of the following:

• A description of the issue, along with steps that can be taken to reproduce the issue. For example, you might write “Using Chrome, navigate to the page, zoom to 200%, and observe how the header obscures the content.”
• The location of the issue. This should include the URL and (potentially) the page or component that causes the issue.
• Relevant WCAG criteria. Adding info about conformance can help you show why an issue needs to be fixed, which can be helpful for prioritizing certain fixes over others.

You might also include screenshots or screen recordings if you’re sending the issue to another team. Make it easy to find the issue — that will make it much easier to fix.

Get support for web accessibility testing and remediation.

Web accessibility testing needs to be consistent, and building a self-sufficient strategy takes time. The Bureau of Internet Accessibility is here to help. Whether you’re creating an audit plan or building WCAG into your development cycle, we provide resources to help you learn (and use) the best practices of accessible design.

Send us a message to connect with an expert or get started with a free automated web accessibility scan from AudioEye.