Auditing Data UIs with a Screen Magnifier

Screen magnifier users see a small part of the screen at a time, typically 2 to 16 times enlarged. Data UIs are hard for them in particular ways: a toast appears in the bottom right corner while they are working top left; a validation error shows at the top of a form while they edit a cell at the bottom; a wide table’s row identifier is three viewport widths away from the value they are reading; a tooltip opens off the edge of the magnified view. A magnifier audit finds these problems, which automated tools and screen reader tests miss.

This guide belongs to manual accessibility audits.

Spec reference

  • SC 1.4.4 Resize Text (AA) and 1.4.10 Reflow (AA) — related to browser zoom; magnifiers enlarge without reflow, so additional issues appear.
  • SC 3.3.1 Error Identification (A) — errors must be perceivable; near the field helps magnifier users.
  • SC 1.4.13 Content on Hover or Focus (AA) — hoverable, persistent tooltips matter at high magnification.
  • SC 2.4.7 (AA) — focus tracking depends on a visible, programmatically exposed focus.
What a magnifier user sees Layers: the full screen with a table, a toast in the corner and a filter panel; the magnified viewport covering about one sixteenth of the screen around focus; content outside the viewport, including the toast and row identifiers, is invisible until the user pans. What a magnifier user seesFull screentable, filter panel, toast cornerMagnified view at 4×~1/16 of the screen around focusOutside the viewtoasts, row IDs, headers, errorsUser actionpan or move focus to see more
Anything far from focus is effectively hidden.

When to use — and when not to

Run a magnifier audit on key data workflows during each major release, and include magnifier users in usability testing.

Do not substitute browser zoom for a magnifier; browser zoom reflows content, a magnifier does not. The misapplication: testing at 400% browser zoom and assuming magnifier users have the same experience.

Browser zoom versus screen magnifier Comparison: browser zoom reflows the layout and keeps everything on one screen width; a screen magnifier enlarges the unchanged layout, so users see a small window that follows focus. Browser zoom versus screen magnifier✗ Layout reflowsContent fits widthNo panning neededToast still visible✓ Layout unchangedContent off-screenPanning and focus trackingToast outside the view

Annotated code example

<!-- Errors next to the cell, not only in a top banner -->
<td>
  <input aria-label="Amount for INV-1042" aria-invalid="true" aria-describedby="e-1042">
  <span id="e-1042" class="cell-error">Enter an amount above 0</span>   <!-- near focus -->
</td>
/* Toasts near the triggering control when possible, or at a consistent, documented position */
.toast-anchor { position: absolute; inset-block-start: calc(100% + 8px); inset-inline-start: 0; }
/* Tooltips flip to stay inside the viewport */
.tooltip[data-flip="true"] { inset-inline-end: 0; inset-inline-start: auto; }

Keyboard & AT behaviour

Magnifier feature What to check
Focus tracking View follows keyboard focus in grids (roving tabindex and active descendant)
Caret tracking View follows text cursor in cell editors
Pointer tracking Tooltips appear near the pointer
Smoothing and colour filters Text and focus indicators remain readable
Speech (ZoomText) Reads focused content; overlaps with screen reader checks
Data UI elements and magnifier risk Matrix of elements — toasts, form errors, tooltips, wide tables, dashboard alerts, modals — against distance from focus, tracking support and recommended fix. Data UI elements and magnifier riskDistance from focusTrackedFixToastsFarNoNear control or logForm errorsVariesIf focusedInline near fieldTooltipsNear pointerPointer onlyFlip inside viewWide tablesHeaders farFocus onlySticky headers, row IDsDashboard alertsFarNoAlert near contentModalsCentredFocus movesFocus first field
Keep feedback near focus.

Step-by-step implementation

  1. Set up. Windows Magnifier (Win+Plus), macOS Zoom (Option+Command+8) or ZoomText; set 200% and 400%; turn on focus and caret tracking.
  2. Pick tasks. Filter a table, edit a cell, sort, run a bulk action, read a chart tooltip, respond to an error.
  3. Work through tasks. Use keyboard and mouse; note every time you must pan to find feedback.
  4. Check tracking. Confirm the view follows focus in custom grids; if not, the grid may not move real focus (active descendant without scrolling).
  5. Report. Include magnification level, screen region and what was missed.

Integration context

Zoom testing is covered in zoom and reflow testing at 400 percent. Toast placement follows notifications and toasts for data operations, and tooltips tooltips, popovers and overlays in data UIs. Keyboard audits pair well with this one: keyboard-only audit script for data grids. Bug reporting is in writing actionable accessibility bug reports.

Gotchas

aria-activedescendant and tracking. Magnifiers track the focused element; with active descendant, the DOM focus stays on the container, so the view may not follow. Scroll the active cell into view, and test.

Animations. Moving content at high magnification is disorienting; respect reduced motion.

Colour inversion. Many magnifier users invert colours; check charts and status colours under inversion.

Edge cases

  • Multi-monitor setups. Magnifier users sometimes use a second monitor for a full view; do not assume.
  • Small text in charts. Axis labels at 10 px become blurry when magnified; use larger minimums.
  • Hover-dependent UI. Hover reveals are hard to discover at high magnification; ensure focus reveals too.

Worked example

A magnifier audit of a claims processing grid at 400% found that validation errors appeared only in a banner at the top of the page, toasts appeared bottom right, and the grid used active descendant without scrolling the active cell, so ZoomText’s view stayed on the grid’s top-left corner. The team added inline errors, moved toasts near the triggering control, scrolled active cells into view and increased chart label sizes. A magnifier user completed the claim review task without panning to hunt for feedback.

Common mistakes

  • Treating browser zoom as magnifier testing.
  • Feedback far from focus.
  • Active descendant without scrolling.
  • Tiny chart labels.

Testing checklist

Testing it with a screen reader

ZoomText Fusion and similar products combine magnification and speech, so many magnifier users also hear content. During the audit, turn on the magnifier’s speech or run NVDA alongside Windows Magnifier and confirm that what is spoken matches what is visible in the magnified view. Mismatches — speech about a toast the user cannot see — point to feedback placement problems.

Recruiting magnifier users

Magnifier users are underrepresented in many usability panels, which are often recruited through screen reader communities. Reach out through low-vision organisations and include magnification software in the screening questions. Ask participants which product, magnification level and colour settings they use, and let them bring their own setup when possible. Observing a real user’s workflow at 8× magnification reveals problems no checklist predicts.

Charts under magnification

Charts reveal their own magnifier problems: thin lines that break up when enlarged, axis labels too small to read even at 4×, legends far from the series they describe and tooltips that open on the far side of the chart. During the audit, read a value from each chart type using only the magnified view, and note every time you had to pan to the legend. Direct labels and a data table close to the chart reduce panning.

Key points

  • Magnifiers enlarge without reflow; test with a real magnifier, not browser zoom.
  • Keep feedback — errors, confirmations, toasts — near the focused element.
  • Make sure custom grids move real focus or scroll the active cell so tracking works.
  • Report findings with magnification level and screen region.

Design system notes

Define placement rules for feedback (near the triggering control) in the design system, and test components with magnifiers as part of release checks.

FAQ

Which magnifier should I use?

Windows Magnifier and macOS Zoom are free; ZoomText is common in workplaces.

What magnification levels?

At least 200% and 400%; users go much higher.

Is browser zoom testing enough?

No; it tests reflow, not magnification.

How do I make toasts magnifier-friendly?

Place them near the triggering control or keep a persistent log.

Does colour inversion matter?

Yes, many magnifier users use it.

Should magnifier users be in usability tests?

Yes; they find issues others miss.

← Back to Manual Accessibility Audits