A screen magnifier is assistive technology (AT) software that magnifies (or scales up) the content on a screen, improving experiences for people with vision-related disabilities.
People with low vision may use dedicated screen magnifiers to access websites and mobile apps. They might also use their web browsers to zoom in on content — disabilities are a spectrum, and it’s important to create content that provides an equivalent experience to all users wherever possible.
The choices you make when creating your content could create barriers for people who magnify their screens. By following the Web Content Accessibility Guidelines (WCAG), you can avoid making mistakes.
Here’s a look at several common screen magnifier accessibility issues — and how fixing them provides a better experience for everyone.
1. The screen’s layout requires scrolling in two directions
Today, most businesses understand the importance of responsive design, a design approach that aims to fit the content to the user’s viewport. The viewport is the visible area of the web page.
Responsive content reflows — it responds to changes in the viewport, rather than serving a completely different version of the content depending on the user agent.
Screen magnifiers don’t necessarily depend on reflow, but many people with low vision scale their content using their web browsers. If content cannot reflow when magnified by 400%, the user may need to scroll horizontally and vertically to read all of the content. If you’ve ever visited a non-responsive website when using a mobile device, you’ve probably encountered this issue — it’s a frustrating experience for users.
Relevant WCAG Criterion: WCAG 2.1 Success Criterion (SC) 1.4.10, “Reflow"
This criterion requires that “content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:
- Vertical scrolling content at a width equivalent to 320 CSS pixels;
- Horizontal scrolling content at a height equivalent to 256 CSS pixels.
Essentially, “Reflow" requires responsive design. As your content is magnified, the user can view it in a single column, which provides a better reading experience.
This usually requires some work with CSS (Cascading Style Sheets), but it’s well worth the effort: Responsive websites are robust enough to adapt to different viewports (such as smaller mobile screens) and tend to reduce bounce rates while driving mobile traffic.
Related: Why Reflow Is Essential for Web Accessibility
2. Low-contrast text may be difficult to read, even when magnified
Color contrast is the difference in luminance (light) between your website’s font and its background. Low-contrast text may be difficult to read, even when magnified. This is especially true for people with color vision deficiency (CVD).
Many screen magnifiers have built-in tools for changing colors, but ideally, your website won’t force users to change their settings in order to read content.
Relevant WCAG Criterion: WCAG 2.1 Success Criterion (SC) 1.4.3, “Contrast (Minimum)”
WCAG requires the visual presentation of most text and images of text to maintain a contrast ratio of at least 4.5:1, with exceptions for logos and incidental text. Large-scale text (and images of text) must maintain a contrast ratio of at least 3:1.
Automated tools can test your content against WCAG’s contrast requirements. The Bureau of Internet Accessibility provides the a11y® Color Contrast Accessibility Validator, a free instant analysis utility.
Related: The Basics and Importance of Color Contrast for Web Accessibility
3. Missing focus indicators can make navigation difficult
Some screen magnifiers like Freedom Scientific’s ZoomText can change the size of the user’s mouse cursor, which can overcome some focus indicator issues — but again, you don’t want to force the user to change their settings to operate your website.
Additionally, many people with low vision use a keyboard alone (no mouse) to navigate the web. Keyboard users expect websites to have clear, visible focus indicators.
Relevant WCAG Criterion: WCAG 2.1 SC SC 2.4.7, “Focus Visible”
This criterion requires that “any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.”
To meet this requirement, avoid using CSS to override users' focus indicators and make sure you test your content for visual effects that could obscure the indicator.
Related: What You Need to Know About Visual Focus and Accessibility
4. Websites require specific pointer gestures that the user cannot perform.
When a portion of the screen is magnified, users may not be able to perform certain gestures. For example, if a website requires a user to drag an icon over to another icon, some people won’t be able to perform that action.
That doesn’t mean that you should remove pointer gesture functionality from your website — gesture controls can be great for accessibility. However, you should provide users with options.
Relevant WCAG Criterion: WCAG 2.1 SC 2.5.1, “Pointer Gestures"
Here’s the full text of this success criterion:
All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.
An example of an “essential gesture" is an online painting app. Removing the path-based gestures would defeat the purpose of the app.
Another applicable criterion is WCAG 2.1 SC 2.1.1, “Keyboard,” which requires that all functionality is fully operable with a keyboard alone.
Related: How "Drag-And-Drop" Movements Affect Web Accessibility
Remember, digital accessibility isn’t just for people with vision disabilities
To create truly accessible content, you’ll need to build a website that accommodates as many people as possible — including people who use screen magnifiers, screen readers, eye-tracking systems, and other technologies to browse the internet.
By following WCAG, you can avoid accessibility barriers and reach a wider audience. For guidance, send us a message to connect with an expert or download our free eBook: The Ultimate Guide to Web Accessibility.
