How to Test Typography for Low-Vision Users?

Your site passes Lighthouse with a perfect accessibility score. Then you sit next to a user with macular degeneration while she reads your product page using Windows Magnifier at 6×. She loses the navigation off the side of the screen, mistakes a light gray "Save" button for disabled, and can't find the price because it's set in a thin weight that turns to mush under magnification. Every one of those problems was invisible to the automated scan, which only checked that colors passed a ratio on a static page.

This article gives you a practical test plan for typography with low-vision users in mind. It covers the kinds of low vision you're designing for, the tools people actually use, how to simulate impairments in the browser, a repeatable manual test routine, automated checks you can put in CI, and how to run sessions with real participants.

What Low Vision Means for Typography

Low vision is a visual impairment that can't be fully corrected with glasses, contacts, or surgery and that affects daily tasks such as reading. The World Health Organization estimates that at least 2.2 billion people have some form of near or distance vision impairment, and a large share of them read the web.

Low vision isn't one condition. Different impairments create different typographic needs:

Condition type	Examples	Typography impact
Reduced acuity (blur)	Cataracts, uncorrected refractive error	Needs larger text and distinct letterforms
Reduced contrast sensitivity	Cataracts, glaucoma, aging eyes	Needs high contrast; thin weights disappear
Central field loss	Macular degeneration	Uses high magnification; sees only part of a line at once
Peripheral field loss	Glaucoma, retinitis pigmentosa	Narrow field of view; long lines and far-flung UI get missed
Light sensitivity	Albinism, some medications	Prefers dark mode or inverted colors; glare hurts
Color vision deficiency	Protanopia, deuteranopia	Can't rely on color alone for links or states

Your tests should cover each of these, because a design that works under blur can still fail under magnification or forced colors.

Know the Tools Low-Vision Users Rely On

Before testing, understand what your users actually do to read the screen:

• Browser zoom and default font size settings, covered in detail in how to support browser zoom and user font preferences.
• Screen magnifiers: Windows Magnifier, macOS Zoom, iOS and Android Zoom, and commercial tools like ZoomText and SuperNova. These enlarge a part of the screen, often 4× to 16×, so the user sees only a small window at a time.
• High contrast and forced colors: Windows contrast themes replace your colors with a limited system palette.
• Inverted colors and dark mode: macOS, iOS, and Android offer system-level inversion, and many users prefer dark themes.
• Larger system text: iOS Larger Text, Android Font size and Display size.
• Reader modes: Safari Reader, Firefox Reader View, and Edge Immersive Reader strip your styles and reflow content, which only works if your markup is clean.
• Browser extensions that change fonts, spacing, and contrast.

Each tool changes your typography differently, so each needs its own test.

Step 1: Run Automated Checks First

Automated tools catch the easy failures quickly, which frees your manual time for the harder ones. Run at least one of these on every template:

• Lighthouse in Chrome DevTools.
• axe DevTools browser extension.
• WAVE from WebAIM.

They reliably catch:

• Text contrast below 4.5:1 for normal text and 3:1 for large text (WCAG 1.4.3).
• Missing lang attribute.
• Viewport settings that disable zoom.
• Skipped or missing heading levels.

They don't reliably catch text over images or gradients, contrast in hover and focus states, readability of thin weights, layout breakage at zoom, or anything that depends on human judgment. Treat the automated pass as a filter, not a verdict. For the details of contrast rules, see WCAG contrast requirements for text.

Step 2: Simulate Vision Impairments in DevTools

Chrome and Edge DevTools can simulate several conditions. Open DevTools, press Ctrl+Shift+P (Cmd+Shift+P on macOS), type "Show Rendering," and find Emulate vision deficiencies. The options are:

• Blurred vision
• Reduced contrast
• Protanopia (no red cones)
• Deuteranopia (no green cones)
• Tritanopia (no blue cones)
• Achromatopsia (no color)

Work through each and ask:

1. Blurred vision: Can you still distinguish Il1, O0, and rn versus m? Can you tell headings from body text by size and weight, not just color?
2. Reduced contrast: Is body text still readable? Do light gray captions, placeholders, and borders vanish? Thin weights (300 and below) are usually the first to go.
3. Color deficiencies: Can you identify links without color? Are error messages distinguishable from normal text with something other than red?

Simulations are approximations, not lived experience. Use them to find obvious problems, not to sign off on a design.

Step 3: Test with Screen Magnification

Magnification is where typography that looks fine at normal size often breaks down. Turn on a magnifier and read a full page:

• Windows: press Windows key + plus to start Magnifier, then keep pressing plus to increase magnification.
• macOS: System Settings, Accessibility, Zoom, then enable keyboard shortcuts or scroll gesture with modifier keys.

At 4× and above, look for:

• Long line lengths. At high magnification, a 100-character line requires a lot of horizontal panning. Lines limited to about 65–75 characters are easier to follow. The post on ideal line length for web content covers how to measure them.
• Related information far apart. A price on the far right and a "Buy" button on the far left may never appear in the same magnified view. Keep related text and controls close together.
• Thin strokes and low-contrast text, which look even worse when enlarged.
• Text in images, which becomes pixelated under magnification. Real text stays sharp.
• Tooltips and hover text that appear outside the magnified area and go unnoticed.

Step 4: Test Zoom, Text Size, and Reflow

Run these tests in a desktop browser at 1280px wide:

1. Page zoom to 200%. All text should be larger, with no overlapping or clipping. This covers WCAG 1.4.4.
2. Page zoom to 400%. The page should reflow to a single column with no horizontal scrolling, except for tables, maps, and code. This covers WCAG 1.4.10.
3. Browser default font size to 24px or larger. All text should grow. Text that stays the same size is set in px.
4. Firefox text-only zoom to 200%. This exposes fixed-height containers that clip text.

Write down each failure with a screenshot, the template, the zoom level, and the element.

Step 5: Apply Text Spacing Overrides

WCAG 1.4.12 requires that content survives these user overrides:

• Line height of 1.5 times the font size
• Paragraph spacing of 2 times the font size
• Letter spacing of 0.12 times the font size
• Word spacing of 0.16 times the font size

Paste this into the DevTools console to apply them:

const s = document.createElement("style");
s.id = "wcag-text-spacing";
s.textContent = `
  * {
    line-height: 1.5 !important;
    letter-spacing: 0.12em !important;
    word-spacing: 0.16em !important;
  }
  p { margin-bottom: 2em !important; }
`;
document.head.appendChild(s);

Look for clipped button labels, overlapping card text, truncated navigation, and text spilling out of fixed-height containers. Remove it with document.getElementById("wcag-text-spacing").remove().

Step 6: Test Forced Colors and Inverted Colors

Forced colors mode replaces your palette with the user's system colors. In Chrome DevTools, open the Rendering panel and set Emulate CSS media feature forced-colors to active. On Windows, you can also turn on a contrast theme in Settings, Accessibility, Contrast themes.

Check:

• Text remains visible everywhere, including text on background images.
• Buttons and badges that relied on background color alone still have visible boundaries.
• Custom focus indicators remain visible.
• Icons that convey meaning are still visible.

Fix boundary issues with a transparent border, which becomes visible in forced colors:

.button {
  border: 2px solid transparent;
}

@media (forced-colors: active) {
  .badge {
    border: 1px solid CanvasText;
  }

  .icon {
    forced-color-adjust: auto;
  }
}

Next, test system color inversion (macOS: Accessibility, Display, Invert colors) and your own dark mode. Photos should look correct in smart invert, text should stay readable, and dark mode shouldn't use pure white on pure black for long text, which can cause halation for users with astigmatism.

Also set Emulate CSS media feature prefers-contrast to more and confirm any high-contrast adjustments you've built actually activate.

Step 7: Check Reader Mode and Unstyled Content

Many low-vision users switch to reader mode to get their own font, size, and colors. Open each article template in Safari Reader or Firefox Reader View. If the main content doesn't appear, appears without headings, or includes navigation and ads, your markup needs work. Use main, article, real heading elements, and real lists.

Step 8: Automate Regression Checks

Once a template passes, protect it with automated tests. This Playwright test runs axe-core for contrast and structure, then checks that the page doesn't scroll horizontally at a 320px viewport, a proxy for 400% zoom:

import { test, expect } from "@playwright/test";
import AxeBuilder from "@axe-core/playwright";

test("article meets automated a11y checks", async ({ page }) => {
  await page.goto("/blog/sample-post");
  const results = await new AxeBuilder({ page })
    .withTags(["wcag2a", "wcag2aa", "wcag21aa", "wcag22aa"])
    .analyze();
  expect(results.violations).toEqual([]);
});

test("article reflows at 320px without horizontal scroll", async ({ page }) => {
  await page.setViewportSize({ width: 320, height: 640 });
  await page.goto("/blog/sample-post");
  const overflow = await page.evaluate(
    () => document.documentElement.scrollWidth > document.documentElement.clientWidth,
  );
  expect(overflow).toBe(false);
});

Install the dependencies with:

npm install -D @playwright/test @axe-core/playwright
npx playwright install chromium

You can extend this with visual snapshots of each template at 200% text size, using page.addStyleTag to set the root font size to 200%.

Step 9: Test with Real Low-Vision Users

Simulations and checklists don't replace people who use magnifiers, high contrast, and large text every day. Even three to five participants will reveal problems no tool finds.

Practical tips:

1. Recruit through organizations that serve blind and low-vision people, or through specialist recruitment panels. Pay participants fairly.
2. Let participants use their own setup, including their device, magnifier, contrast settings, and font size. Their configuration is the test.
3. Give realistic tasks, such as "Find the price of the annual plan" or "Read this article and tell me the main recommendation," rather than "What do you think of the font?"
4. Watch where they slow down, zoom in further, lean toward the screen, or switch modes. Those moments point to typography problems.
5. Ask afterward about fatigue, glare, and which parts were hardest to read.

Build a Repeatable Test Matrix

Turn the steps into a matrix that you run on each key template before release:

Test	Tool / setting	Pass criteria
Automated scan	axe, Lighthouse, WAVE	No contrast or structure violations
Blurred vision	DevTools vision emulation	Hierarchy and characters still distinguishable
Reduced contrast	DevTools vision emulation	Body text and controls still readable
Magnification 4×+	Windows Magnifier, macOS Zoom	Related content stays close, no text in images
Zoom 200%	Browser zoom	No clipping or overlap
Reflow 400%	Browser zoom at 1280px	Single column, no horizontal scroll
Large default font	Browser settings, 24px	All text grows
Text spacing	Console snippet or bookmarklet	No loss of content
Forced colors	DevTools or Windows contrast themes	Text, boundaries, and focus visible
Reader mode	Safari Reader, Firefox Reader View	Content and headings extracted correctly

Low-Vision Typography Testing FAQ

Conclusion

Testing typography for low-vision users means testing the way they actually read: magnified, zoomed, with larger default text, custom spacing, forced colors, inverted colors, and reader mode. Automated scans catch the contrast and structure basics, DevTools simulations surface obvious weaknesses, and a short manual routine at 200% and 400% zoom with spacing overrides finds most layout failures.

Put that routine into a test matrix, protect passing templates with Playwright and axe in CI, and schedule regular sessions with low-vision participants using their own setups. That combination finds the problems a perfect Lighthouse score hides and gives you evidence that your text works for the people who struggle with it most.

Here are some useful references for going deeper on testing typography for low-vision users:

1. W3C WAI: Accessibility Requirements for People with Low Vision — a detailed breakdown of low-vision user needs for text and layout.
2. Chrome for Developers: Emulate vision deficiencies — how to use the DevTools Rendering panel for simulations.
3. W3C WAI: Understanding Success Criterion 1.4.12: Text Spacing — the exact spacing values and testing guidance.
4. MDN Web Docs: forced-colors — how forced colors mode works and how to style for it.
5. Deque: axe-core Playwright integration — setup and API reference for automated accessibility tests.