Blog · How-to
Why dyslexia font tools don't work on every website — and what to do
You install a dyslexia font extension, switch on OpenDyslexic or Lexend, and it transforms Wikipedia, news articles, and most blog posts beautifully. Then you open your bank's online portal, fire up Figma, or visit a heavily branded corporate site — and the text looks exactly the same as before, as if the extension weren't running at all. This isn't a bug. It's the result of several different web technologies that, by design, sit outside the reach of any external CSS injection. Understanding why this happens is the first step to working around it.
How font override tools work
Browser extensions that change fonts — including LexiFont — work by injecting CSS into the page after it loads. A simple rule like * { font-family: OpenDyslexic, sans-serif !important; } rewrites the font declaration on every element the browser's layout engine processes. For most pages — articles, documentation, e-commerce, social media — this works immediately because those pages render text through ordinary HTML elements styled with CSS. The extension's rule sits at a high specificity level and wins.
But "ordinary HTML elements styled with CSS" is not the only way text can appear on a web page. Modern web applications use at least four other techniques, and each one is immune to CSS-level overrides for a different reason.
The four reasons a site can block font overrides
1. Canvas-rendered text
The HTML <canvas> element is a pixel-drawing surface. When an application draws text onto a canvas with JavaScript's ctx.fillText() API, that text is not text in any meaningful sense that the browser's CSS engine understands — it is a grid of pixels, the same as a photograph. CSS font-family declarations have no more effect on canvas text than they do on a JPEG.
This matters because several of the most widely used web tools render their primary content on canvas: Figma, Google Maps, many online spreadsheet editors when they draw cell content at scale, and parts of PDF.js-based viewers. If you use any of these for work, your font extension will reliably do nothing to the main editing area, because there is no HTML text node for it to style.
2. Cross-origin iframes
An <iframe> embeds one web page inside another. When the iframe comes from the same domain as the host page, extensions can generally reach inside it. But when the iframe is served from a different domain — a payment processor's card form, a YouTube video embed, a third-party support chat widget — the browser enforces strict cross-origin security boundaries. Extension content scripts are blocked from injecting CSS or JavaScript across that origin boundary, by design, to prevent one site from modifying or reading another site's content.
This is why your font extension might transform everything on an airline booking page except the final payment step: the card fields are often hosted by a payment processor (Stripe, Adyen, Braintree) on their own domain, loaded into an iframe. The extension sees the frame; it cannot reach into it.
3. Aggressive inline styles and CSS specificity wars
Even when text is regular HTML, some sites effectively block overrides by setting font styles with inline style attributes directly on elements in JavaScript, or by loading fonts via the Font Access API and locking them to specific elements. Inline styles in HTML have higher specificity than any stylesheet rule, including rules with !important — the only way to beat an inline !important style is with a user agent stylesheet or a browser setting, not a content-script CSS rule.
In practice this is less common than canvas and iframes, but some enterprise web applications — internal tools, HR portals, certain financial dashboards — use JavaScript frameworks that set styles inline on every render cycle, effectively resetting any CSS override the moment they repaint.
4. Chrome extension restrictions on special pages
Chrome itself limits where extensions can run. Content scripts do not execute on chrome:// pages (the settings, extensions manager, new-tab page in some configurations), on pages belonging to other extensions, on the Chrome Web Store, or on certain sandboxed contexts like PDF viewer pages before you interact with them. These restrictions exist for security reasons and cannot be overridden by the extension.
If you open the Chrome settings page and expect your font extension to apply Atkinson Hyperlegible to Chrome's own UI, it won't — and that is intentional behaviour, not a bug you can report.
Which sites are most commonly affected
| Site / tool | Why overrides often fail | Workaround |
|---|---|---|
| Figma | Design canvas is a WebGL/canvas surface | Change Figma's app font in its own settings (affects UI only) |
| Google Maps | Map labels drawn on canvas | No direct fix; increase system font scaling for UI chrome |
| Payment forms (Stripe, etc.) | Cross-origin iframe | Audio CAPTCHAs / autofill to reduce reading burden; browser zoom helps |
| Online PDFs | PDF rendered as canvas by the viewer | Download the PDF, open in a dedicated reader, or use PDF accessibility tools — see PDF guide |
| Google Sheets cell content | Grid cells partially canvas-drawn at scale | Reduce zoom level so Sheets switches to DOM rendering; or use the accessibility view |
| Chrome settings pages | chrome:// pages blocked by design | Use OS-level font scaling or high-DPI display settings |
What you can actually do
The workarounds fall into three tiers: things that fix the problem at the browser level, things that work around it for specific content, and things that reduce the reading burden without requiring font changes at all.
Browser Reader Mode
Chrome's built-in reader mode (enable it at chrome://flags/#enable-reader-mode) strips a page down to its text content, presents it in a clean single-column layout, and — critically — re-renders all text as genuine HTML elements, bypassing whatever the original site was doing with its CSS. Once an article is in reader mode, any font extension can change its typeface without restriction. The trade-off is that reader mode only works on article-style content; it won't help with interactive applications.
This is often the fastest fix for news sites, blog posts, or documentation pages that use aggressive CSS and refuse to yield to your extension. See our comparison of reader mode versus reading extensions for a fuller picture of when each approach works better.
LexiFont Pro's override mode
LexiFont Pro includes an aggressive override mode that pushes font rules at the highest specificity the browser permits from a content script — targeting shadow DOM roots and dynamically injected elements that the free tier's stylesheet approach may miss. This catches the "inline styles written by JavaScript frameworks" class of problem described above. It does not solve canvas text or cross-origin iframes, because no extension can solve those — they are browser-level boundaries, not CSS specificity issues.
If a site works in reader mode (its text is real HTML) but your font extension still fails to override the font, upgrading to LexiFont Pro is worth trying before giving up on a particular site.
Chrome's minimum font size
Chrome has a built-in minimum font size setting (Settings > Appearance > Customise fonts > Minimum font size). Setting this to 14 or 16px means Chrome will refuse to render text smaller than that threshold, even if a site's CSS asks for 10px or 11px. This is not a font-family override — it won't change the typeface — but it is enforced at the browser engine level and bypasses CSS entirely. For sites where the core problem is that text is too small to parse comfortably, this often helps more than a font change would. See our full guide on browser zoom and text scaling for dyslexia for the mechanics.
OS-level accessibility font scaling
Both macOS and Windows allow you to scale the system UI font independently of the screen resolution. On macOS, this appears under System Settings > Accessibility > Display > Larger Text. On Windows, it is Settings > Ease of Access > Display > Make text bigger. These settings affect native application text and, on some platforms, some browser UI chrome — but they generally do not affect web content. They are, however, useful for the chrome:// restriction class of problem, where the text you cannot change is the browser's own interface.
High-contrast and zoom for canvas content
For canvas-rendered text — the Figmas and Google Maps of the world — font changes are simply off the table. What you can do is reduce the cognitive load through other means: increase the overall browser zoom (Cmd/Ctrl + Plus), use Chrome's forced colours mode (Settings > Accessibility > High contrast) which some canvas applications partially respect, or look for accessibility settings within the application itself. Figma, for instance, has its own "reduce motion" setting and allows the UI font size to be changed independently of the canvas.
If the content you need is a long document that happens to be embedded in a canvas-based viewer, see whether the document can be downloaded and opened in a dedicated reader instead. Our guide on dyslexia-friendly PDF reading covers the best options for document-heavy workflows.
A practical decision tree
My font extension has no effect on a particular site. What do I try first?
1. Try browser Reader Mode. If it works and the font changes, the site was blocking with CSS — Reader Mode solved it.
2. If Reader Mode has no "reader view" option for that page, the page is probably an application, not an article. Try LexiFont Pro's aggressive override mode next.
3. If the text still won't change, inspect the page: right-click any text and choose Inspect. If the text is inside a <canvas> element or an <iframe src="https://otherdomain.com">, no CSS tool can help. Move to workarounds: zoom, high contrast, or use the application's own accessibility settings.
4. If the page is a chrome:// URL, this is a browser restriction. Use OS-level font scaling for the browser UI.
Why this matters for dyslexic readers specifically
Most guides to browser accessibility assume the reader just needs to be told about the tool and shown how to install it. The reality is that the sites where font overrides fail are often the sites that matter most: work applications, banking, healthcare portals, and HR systems. These are also the sites that tend to use the smallest fonts, the most compressed line heights, and the least reader-friendly typography — because they were built by engineers following internal design systems that prioritise brand consistency over legibility.
This is worth naming plainly: the hardest-to-read web content is disproportionately the content you have no choice but to read. A font extension that works on Wikipedia and fails on your company's payroll portal is still enormously useful — but it's worth going in with a realistic picture of where the limits are.
The good news is that the landscape is improving. Chrome's ARIA and accessibility APIs are expanding. Web applications are increasingly audited against WCAG 2.2, which encourages semantic HTML over canvas-drawn UI. And some of the most important platforms — Notion, Slack, Linear, Confluence — render text as ordinary HTML, which means tools like a font override extension work on them without any extra steps. For those, the gap between "what the site looks like" and "what you need it to look like" is fully bridgeable.
For developers reading code specifically — where the text is almost always HTML-rendered in browser-based tools like GitHub, GitLab, and VS Code for the Web — font overrides work reliably, and swapping in a dyslexia-friendly monospace font can make a meaningful difference to how long you can code before fatigue sets in.
The summary: font extensions are powerful, and the best dyslexia fonts genuinely help on the majority of the web. Canvas, cross-origin iframes, and Chrome's own pages are the hard limits — and they are limits for all font tools, not just any one extension.
Try LexiFont Pro — aggressive override mode, all dyslexia fonts, $14.99 one-time