Blog · Practical Guides
Reading technical documentation with dyslexia
API references, framework guides, software manuals, and README files are some of the densest text on the internet. For readers without dyslexia, they are already a cognitive challenge. For dyslexic readers, the usual friction multiplies: walls of small monospaced text, dense paragraphs with no visual breathing room, tables packed with similar-looking parameter names, and navigation structures that assume you already half-know what you are looking for. This guide covers what actually helps.
Why technical docs are harder than ordinary prose
Most advice about dyslexia-friendly reading focuses on books, articles, and emails. Technical documentation has several features that make it a genuinely different problem.
Mixed type. Technical docs constantly switch between prose and code. A paragraph of explanation, then a code block, then an inline reference like response.status_code, then another paragraph. Each switch requires your visual system to recalibrate from proportional text to fixed-width monospace and back again. For readers who already expend extra effort decoding letterforms, this toggling adds a significant overhead.
High noun density. Technical text is full of proper nouns, acronyms, and compound identifiers. Names like AuthorizationHeaderMiddleware or GET /api/v2/users/{id}/permissions have no phonological handle - you cannot sound them out to recognise them. This puts extra pressure on visual word-recognition, which is exactly the area where many dyslexic readers face the most difficulty.
Non-linear structure. Documentation is designed to be navigated rather than read start-to-finish. That means frequent cross-references ("see the Configuration section"), versioned sidebars, collapsible subsections, and sidebar navigation that can be overwhelming at a glance. Keeping your place in a branching doc structure is hard when re-locating yourself on the page already takes effort. This connects directly to why dyslexic readers lose their place more easily than others.
Compressed writing style. Good technical writing omits connective tissue. "Returns a 404 if the resource is not found" has no leading clause, no transition, no signal that a new sentence has started. Short, abrupt sentences are generally good for clarity - but when one dense sentence follows another with no paragraph break, the lack of visual landmarks makes it harder to know where you are.
The font problem in technical docs
Most documentation sites use one of a handful of typefaces for body text - often a system UI font, a slightly condensed sans-serif, or a generic web font chosen more for brand consistency than readability. Many of these are fine for the average reader; few are optimised for dyslexic readers.
The research on font choice for dyslexia is consistent in one direction: fonts with high inter-letter spacing, clear letterform differentiation (especially for b/d/p/q), and a generous x-height all help. Fonts like OpenDyslexic, Lexend, and Atkinson Hyperlegible were designed with these principles in mind. None of them are used as defaults on major documentation sites.
The monospaced code blocks are a separate issue. The standard monospace fonts (Courier New, Consolas, SF Mono) are not dyslexia-optimised. Of the programming-oriented fonts, Fira Code and JetBrains Mono both have unusually high legibility in tests with general readers. OpenDyslexic Mono exists and some readers find it genuinely helpful - see our full review of OpenDyslexic Mono for the trade-offs. For the prose sections of technical docs, the same font rules apply as for any other website: override to something legible, size up, and increase line height.
Overriding fonts on documentation sites
The most direct intervention is to force a dyslexia-friendly font on any documentation site you visit. LexiFont is a Chrome extension that does exactly this: it applies your chosen font - OpenDyslexic, Lexend, or Atkinson Hyperlegible - across every element on the page, including the prose sections of documentation sites. Code blocks use their own font stack, which LexiFont preserves by default, so your code remains in a monospaced face while the surrounding explanation becomes easier to read.
Once you have a font override in place, the next most impactful change is font size and line height. Documentation sites routinely set body text at 14-15px, which is too small for comfortable extended reading. Chrome's built-in page zoom (Ctrl+Plus or Cmd+Plus) scales everything uniformly and is the fastest fix. If you want control over just the text size without zooming the whole layout, Chrome's text-only scaling in Accessibility settings is worth enabling.
Size: 18-20px for body text, or use browser zoom until comfortable
Line height: aim for 1.6-1.8 (most doc sites set it around 1.4)
Line length: if the site has a narrow content column, leave it - narrow columns help
Background: if the site uses pure white, a cream or pale-grey override reduces glare
Handling information density
Font changes help with decoding. The bigger challenge in technical docs is often the sheer volume of information arriving in parallel: the main content, the sidebar navigation, the parameter table, the version selector, the breadcrumb trail. Managing that density is a reading strategy problem as much as a typographic one.
Use reader mode aggressively. Chrome's built-in reader mode strips out sidebars, navigation, and ads and reformats the main content as clean, reflowable text. Most documentation sites are not flagged as "articles" in Chrome's parser, so reader mode may not offer itself automatically - but third-party extensions like Mercury Reader or Readability work reliably on many doc sites. The trade-off is losing the sidebar navigation, which is sometimes essential. Use reader mode for sections you plan to read through rather than scan. See our comparison of reader mode vs. reading extensions for the full breakdown.
Break the reading into smaller sessions. Technical documentation is rarely meant to be absorbed in one sitting. Reading 20 minutes of focused prose and then stepping away is a practical accommodation. Working memory constraints are real: once you have filled your buffer with parameter names and method signatures, adding more on top is counterproductive regardless of how good your font settings are.
Use the site's own search first. Instead of reading a section hoping to find what you need, type the specific term into the doc site's search bar. This narrows your reading target to a paragraph or two rather than a whole page. Then you can read just that fragment with focused attention. The reduction in scanning effort is significant for readers who find it hard to track a moving target across a busy page.
Parameter tables
Parameter tables are a particular pain point. A typical REST API reference table has five or six columns - name, type, required, default value, description - in a small font with narrow cell padding. The rows often look nearly identical at a glance, and it is easy to lose which row you are reading mid-scan.
A few practical workarounds: browser zoom helps here even if you are already using a font override, because zooming in on a dense table reduces the number of columns visible at once, which cuts the scanning demand. If the documentation site has a dark mode toggle, try it: the alternating row shading in many dark-mode tables provides better visual separation between rows than the light-mode version. Some browser extensions add row highlighting - hovering your cursor highlights the entire row, which eliminates the "which row am I on" problem entirely.
If a table is very dense and you need to refer back to it repeatedly, copying the relevant rows into a plain-text note in a larger font is a sensible external memory strategy, not a workaround to be embarrassed about.
Setting up a consistent reading profile
The most valuable thing you can do if you read technical documentation regularly is to create a consistent browser profile tuned to documentation reading, rather than re-adjusting settings per-site. A Chrome profile set up for reading keeps your font overrides, zoom level, and extension settings stable across every site, so you are not spending cognitive energy on setup every time you open a new doc page.
The rough spec for such a profile: LexiFont set to Atkinson Hyperlegible or Lexend, Chrome's minimum font size set to 16px in Settings, text scaling at 110-120%, and a low-contrast colour scheme if you find pure-white backgrounds tiring. Background colour choices for dyslexia - cream, pale blue, or light grey - are worth trying here; many dyslexic readers find documentation on a white background more tiring than the same text on a warm-toned background.
With LexiFont Pro, you can pin a font and size as your site-wide default so it applies automatically whenever Chrome opens a new page - no clicking needed each session. This is especially useful if you spend time across multiple documentation sites in a single day.
When the documentation is a PDF
Some technical references - hardware manuals, standards documents, older software guides - are published as PDFs rather than web pages. PDFs are more resistant to font overrides because the text is embedded as glyphs, not as HTML. The practical workaround is to use Chrome's PDF viewer with the built-in zoom, or to open the PDF in a dedicated reader that allows reflow (Adobe Acrobat has a "Reflow" view that breaks the fixed layout and renders the text as continuous prose). For a full workflow on this, see our guide to dyslexia-friendly PDF reading in Chrome.
Listening instead of reading
For documentation that does not require you to follow code examples step-by-step, text-to-speech is underused. Many dyslexic readers find they absorb prose faster through audio than through reading, especially when the content is conceptual: architecture explanations, design philosophy sections, "getting started" narratives. Chrome's built-in "Listen to this page" (right-click selected text) works on most documentation sites and pairs well with font overrides. You can listen to the prose explanation while keeping your eyes on the code block it describes.
This combination - audio for the prose, eyes on the code - is how many dyslexic developers report reading documentation most comfortably. The auditory channel handles the explanatory text; the visual channel focuses exclusively on the code being explained. The font override ensures that when you do need to read a sentence closely, the letterforms are already set to something your visual system finds easier.
Specific sites and their quirks
Not all documentation sites are equal in terms of accessibility. MDN Web Docs has a notably clean layout and responds well to font overrides. Read the Docs sites (used by many Python and JavaScript projects) have a sidebar that can be collapsed, leaving a much cleaner reading column. GitHub's markdown renderer adds generous line height automatically. Confluence and Notion, used for internal documentation at many companies, both support custom font settings at the workspace or page level. For reading Confluence specifically, see our guide to reading Jira and Confluence with dyslexia.
The sites that tend to resist accessibility improvements are those with heavy JavaScript rendering - docs built on Docusaurus, Vitepress, or custom doc-site frameworks that load content dynamically. LexiFont and most font-override extensions handle these correctly by re-applying the font after each page navigation, but if you encounter a site where the font override resets, this dynamic rendering is usually the cause.
A word on cognitive load
Reading technical documentation with dyslexia is harder not just at a decoding level but at a cognitive load level, because the decoding effort eats into the working memory you would otherwise spend on comprehension. Every calorie your brain spends recognising a letterform is a calorie not spent understanding what that parameter does. Font and spacing improvements are not cosmetic: they free up cognitive capacity for the thing that matters, which is understanding the content.
The research on line spacing and letter spacing bears this out. Readers who encounter the same words in a better-spaced layout do measurably better on comprehension tasks, not just reading speed. The goal of every setting in this guide is the same: reduce the portion of your attention that goes to "reading" so more of it can go to "understanding." Documentation is hard enough on its merits. The typography should not add to that difficulty.
The setup that works for most dyslexic readers of technical docs: LexiFont set to Atkinson Hyperlegible or Lexend, browser zoom at 115-125%, Chrome minimum font size at 16px, and reader mode for conceptual sections you plan to read through rather than scan. Five minutes of setup, far less friction on every documentation page you open after that.