Accessibility and Zoom Check Guide
A reference for the DeskTest.net Accessibility and Zoom Check. Explains what the tool detects, how to read the verdict, and the exact setting to change for each active mode. Use it when a user says "the screen looks wrong" - huge text, white on white, missing colors, or no animations - and you need to know in one click whether it is a setting rather than a broken page.
Open the Accessibility and Zoom Check ->
What does this check detect?
Two read-only probes. Nothing is changed on your machine; the tool only reads what the browser already exposes.
- Accessibility, contrast, and motion settings. Uses
window.matchMediato read six CSS media features:forced-colors(Windows High Contrast),prefers-contrast,prefers-reduced-motion,prefers-color-scheme,prefers-reduced-transparency, andinverted-colors. Each is reported as off, active, or "not detectable in this browser" when the engine does not implement that query. - Zoom and display scaling. Estimates browser (Ctrl-plus/minus) zoom, reads the pinch-zoom layer from
window.visualViewport.scale, reportswindow.devicePixelRatio, and reads the computed root font size. It deliberately keeps browser zoom and OS display scaling separate, because they look identical to the user but are fixed in different places.
After the first run the tool keeps watching. Toggle a Windows or macOS accessibility setting, or press Ctrl++ / Ctrl+-, and the readout and verdict update live via media-query change events. Nothing leaves the browser.
When should I run this?
- "The website looks broken." White on white, missing backgrounds, invisible buttons. Nine times out of ten this is Windows High Contrast (forced colors) turned on by accident, often by the Left Alt+Left Shift+Print Screen shortcut. This check confirms it instantly.
- "Everything is huge / tiny." Tells you whether it is browser zoom (fix with one keystroke) or OS display scaling (fix in the OS), so you do not chase the wrong setting.
- "The animations stopped" or "dark mode turned on by itself." Confirms reduced-motion or color-scheme is set, and where to change it.
- Before filing a bug against a vendor app. Rule out an accessibility override first, so you are not reporting "the buttons are invisible" when High Contrast is doing it.
- Onboarding a new workstation. A quick confirmation that no accessibility mode was left on in the base image.
Reading the results
Each step gets a status badge: Pending, Running, Pass, or Active. "Active" is not a failure - it means a mode is switched on and reaching the page. Active rows expand to show what each mode does and, where relevant, a numbered fix list.
The verdict panel at the top gives a one-line answer, a likely cause, and a recommended next step. It is opinionated: if forced colors is on, it names that as the headline because it is the most common cause of "the colors look wrong". If nothing is overriding the page and zoom is about 100%, the verdict says the settings look normal and points you at OS display scaling as the remaining suspect.
Copy Diagnostic Report writes a plain-text summary to the clipboard: every setting with its current value and whether it is active, the zoom and scaling numbers, and an overall line. Paste it into a ticket. Send to your IT drops the same text into an email.
The accessibility settings, one by one
forced-colors: Windows High Contrast
When active, the operating system replaces the page's colors with a system high-contrast theme. Sites that were not built for it lose background fills, gradient buttons, and background images. This is by far the most common reason a page looks "white on white" or has invisible controls.
- Windows 11: Settings > Accessibility > Contrast themes. Set the theme to None and Apply.
- Windows 10: Settings > Ease of Access > High contrast, turn off Turn on high contrast.
- Either: the shortcut Left Alt+Left Shift+Print Screen toggles it, which is how it usually gets switched on by accident.
Firefox maps this to its own "Use system colors" / colors override, so a Firefox colors override can also trip it even without OS High Contrast. Chrome and Edge follow the OS theme.
prefers-contrast: more, less, or custom
Reports whether the user asked for higher or lower contrast. More comes from a Windows Contrast theme or macOS "Increase contrast". Custom usually means a Windows High Contrast theme is active, which also shows up under forced colors. This is a preference, not a fault - only change it if it was set by accident. Windows: Settings > Accessibility > Contrast themes. macOS: System Settings > Accessibility > Display > Increase contrast.
prefers-reduced-motion: reduce
When active, well-behaved sites drop or shorten animations and transitions. If a user reports "the fancy animation stopped" or a carousel no longer auto-advances, this is usually why. Windows: Settings > Accessibility > Visual effects > Animation effects. macOS: System Settings > Accessibility > Display > Reduce motion.
prefers-color-scheme: dark or light
Informational. Tells you whether the browser is asking sites for a dark or light theme. It is never flagged as a problem, but it explains "the site went dark on its own." Change it in the OS theme or, in some browsers, the browser appearance settings.
prefers-reduced-transparency: reduce
When active, sites that support it swap translucent, blurred panels for solid backgrounds. A Chromium-era feature; browsers that do not implement the query show "not detectable" rather than a fault. Windows: Settings > Accessibility > Visual effects > Transparency effects. macOS: System Settings > Accessibility > Display > Reduce transparency.
inverted-colors: inverted
A system-wide color invert (for example macOS Classic Invert) makes the whole display look like a photo negative. Where the browser reports it, this check flags it as a likely cause of "the page colors are wrong." macOS: System Settings > Accessibility > Display > Invert colors. Note that Windows implements invert as a Color filter, which is not reliably reported to the browser, so a Windows color filter may not appear here.
Zoom versus OS display scaling
Both make everything bigger, and users cannot tell them apart. They are fixed in different places, so naming the right one saves a support round-trip.
| Number | What it is | How to change it |
|---|---|---|
| Browser zoom (est.) | The Ctrl++ / Ctrl+- page zoom, estimated from the window-to-viewport ratio. Approximate: scrollbars, side panels, and docked DevTools skew it a few percent. | Press Ctrl+0 (Cmd+0 on Mac) to reset to 100%. |
| Pinch zoom | visualViewport.scale - the trackpad/touch pinch layer, separate from page zoom. Normally 100% on desktop. | Ctrl+0 / Cmd+0 resets it too. |
| Device pixel ratio | devicePixelRatio - physical pixels per CSS pixel. This is OS display scaling multiplied by browser zoom. 1.25, 1.5, and 2 are normal on high-DPI laptops and scaled displays. | Not a problem by itself. If it is high only because of OS scaling, change OS scaling, not the browser. |
| Root font size | The computed base font size. Default is 16px; a larger value points at a browser or OS minimum/large-font setting. | Browser Appearance / Fonts settings, or the OS text-size setting. |
Why the tool will not just print one "zoom %". A web page cannot read OS display scaling directly. The only signal is devicePixelRatio, which folds OS scaling and browser zoom together. A naive outerWidth/innerWidth or "DPR times 100" number would call a perfectly normal 150%-scaled laptop "150% zoom" and send you to press Ctrl+0 for nothing. So the tool reports the browser-zoom estimate and the device pixel ratio as separate, honestly labeled numbers, and only tells you to reset zoom when the browser-zoom estimate or pinch zoom is actually away from 100%.
Rule of thumb: if the page shrinks back to normal after Ctrl+0, it was browser zoom. If it stays large at 100% zoom, it is OS display scaling - Windows Settings > System > Display > Scale, or macOS System Settings > Displays > Resolution.
For IT admins
Accessibility overrides are the quiet cause of a surprising share of "the app is broken" tickets, because the user never knowingly turned anything on.
The accidental High Contrast toggle. Left Alt+Left Shift+Print Screen is enabled by default on Windows and is easy to hit by accident, especially on laptops where Print Screen shares a key. You can disable the hotkey per-user (Settings > Accessibility > Contrast themes > Keyboard shortcut) or via the Control Panel\Accessibility\HighContrast registry Flags value in your image. If a cluster of users report "white on white" after a keyboard swap, this is the first thing to check.
Forced colors and web apps. Modern Chromium and Firefox honor forced colors by design; a vendor app that becomes unusable under High Contrast has an accessibility bug worth reporting to the vendor, but the immediate fix for the user is to set the contrast theme to None. Do not assume the app is broken for everyone.
Display scaling on mixed-DPI fleets. Laptops ship at 125% or 150% scaling out of the box; docking to an external 1080p monitor at 100% then makes everything look tiny, and users reach for browser zoom to compensate, which then looks wrong back on the laptop panel. Standardize per-monitor scaling in your image and teach users that Ctrl+0 resets browser zoom without touching the OS.
Kiosk and digital-signage builds. If a signage browser is launched with a --force-dark-mode, --high-contrast, or a forced --force-device-scale-factor flag, this check surfaces the resulting media-query and DPR state so you can see what the launch flags actually did.
Behind the scenes
Step 1 builds one MediaQueryList per feature value with window.matchMedia. Support is detected by inspecting the parsed .media string: a feature the engine does not understand normalizes to not all, which the tool reports as "not detectable in this browser" rather than a fault. The live update attaches a change listener to every supported query (with the legacy addListener fallback for older Safari), so toggling a setting re-renders without a re-run. All listeners are removed on Reset, so nothing leaks.
Step 2 keeps three signals separate on purpose. visualViewport.scale is the pinch-zoom layer and is read directly. Browser zoom is estimated from outerWidth / innerWidth, which is in CSS pixels on both sides so OS scaling cancels - but window chrome and scrollbars add a few percent of noise, so the result is snapped to the nearest 5% and always labeled an estimate. devicePixelRatio is reported as-is and described honestly as OS scaling times browser zoom, and is never treated as a fault on its own, because 1.25/1.5/2 are normal values. Root font size comes from getComputedStyle(document.documentElement).fontSize.
Nothing leaves the browser. No permissions are requested, no camera or microphone, no network calls. The diagnostic report is plain text built in memory and copied with navigator.clipboard.writeText, with a hidden-textarea fallback for browsers that block clipboard writes. View source to verify.
Related
- Accessibility and Zoom Check - the diagnostic itself
- DeskTest.net accessibility statement - how the site itself is built for accessibility
- Display Test - dead pixels, resolution, and screen checks
- Browser Test Guide - browser version, security context, and API support
- About DeskTest.net
- Help: getting started
Elsewhere on the web:
- MDN: forced-colors media feature - the spec behind High Contrast detection.
- W3C WAI: contrast and color - why these accessibility modes exist.