Designing for people with reading disabilities - TetraLogical  🔗 **Source:** [Designing for people with reading disabilities - TetraLogical](https://tetralogical.com/blog/2026/06/25/designing-for-reading-disabilities/) > [!note]+ Document Notes > tags: [reading-disabilities, dyslexia, plain-language, accessible-typography, inclusive-design, digital-literacy] > author: Grace Snow > source: TetraLogical > reference: https://tetralogical.com/blog/2026/06/25/designing-for-reading-disabilities/ > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > > # 🏷️ Title: Designing for people with reading disabilities > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ## 📝 Summary - TetraLogical's "Designing for disabilities" series adds a post on reading disabilities — dyslexia, hyperlexia, alexia — framing reading as a spectrum of decoding effort rather than a binary skill. - It matters because reading fatigue quietly taxes attention and decision-making long before someone consciously notices a barrier; fixes here are largely free (word choice, layout, heading structure) and don't require a redesign. - Stakeholders: content editors and copywriters (plain language), UX/UI designers (layout, typography), accessibility specialists (WCAG mapping), and end users with dyslexia, hyperlexia, alexia, low digital literacy, or who are reading in a second language. - Tradeoff: specialist fields (medicine, law) can't always drop technical terms — the piece proposes glossaries and first-use expansion rather than pure simplification, and it explicitly rejects "one accessible font" as a silver bullet in favor of letter-feature criteria. - Bottom line: treat reading disability accommodation as shared editorial + design responsibility that sits alongside, not inside, WCAG checkbox compliance. ## 📖 Main Content - **Reading is a spectrum, not pass/fail.** Decoding — turning symbols into meaning — costs real cognitive effort for many people. The article names three specific conditions: dyslexia (trouble mapping letter shapes to sounds), hyperlexia (strong decoding without matching comprehension), and alexia (an acquired reading loss, often stroke- or injury-related). - **Root cause framing matters.** The piece is explicit that these are processing differences, not intelligence deficits — a distinction that shapes tone for anyone writing UX copy or error messages aimed at these users. - **Plain language is positioned as inclusion, not simplification-as-condescension**, quoting Sarah Winters (Content Design London) directly on this point. - **Layout guidance is concrete and testable**: left-align (never justify), 70–80 characters per line, sentence-case headings, and heading size that visually signals document hierarchy. - **Typography guidance reframes "accessible fonts."** Rather than naming a specific typeface, it gives letter-feature criteria: distinct glyph shapes (l/1, O/0), taller x-height, open counters (gaps inside letters like e/p), restrained bold/italic/all-caps use, and a "squint test" for spacing. - **Reading-age target**: ~9–11 years old for general adult content, cross-referenced to TetraLogical's own anxiety-design post — this is asserted rather than freshly sourced here, which is worth flagging (see Logical Validity). - **Acronym handling** follows a standard expand-on-first-use pattern, with the added nuance of avoiding acronym-dense paragraphs even when each acronym is individually expanded. - **Multimodal alternatives** (diagrams, video, audio) are framed as sometimes strictly better than text for a given concept (evaporation-as-diagram example), not just a fallback — with a caveat that alt text quality is itself an accessibility variable, not a solved problem once present. - **Low digital literacy** gets folded into the same piece: icon pairing, consistent nav placement, and banning "click here" / "read more" link text. ## 🗒️ Notes - Three named conditions, three different failure modes: dyslexia = encoding mismatch, hyperlexia = decoding/comprehension mismatch (the inverse problem — good decoding, weak meaning-making), alexia = acquired/regressive, so design needs to hold for people whose reading ability changes over time, not just people who've always read this way. - The plain-language argument is really an access-expansion argument, not a dumbing-down argument — worth keeping as the go-to reframe when someone on a team pushes back on cutting jargon. - Formatting rules given are all falsifiable/checkable: line length in characters, heading case, heading size hierarchy. That's unusually testable for a design blog post — could go straight into a lint rule or design-review checklist. - Font guidance deliberately avoids naming winners (no "use Atkinson Hyperlegible" style prescription) — it gives you criteria to evaluate *any* typeface, including ones a brand system has already committed to. That's a more durable recommendation than a font pick. - The video/audio-alternative point implicitly acknowledges alt-text and captioning aren't a free accessibility win by default — quality of the *description*, not just its presence, is called out as the actual accessibility lever. - Link text guidance ("download the 2024 report" vs. "click here") doubles as an SEO best practice — worth noting for any WordPress/content-design audience since the two disciplines rarely get the same advice pointed at them for once. ## 📚 References - [Designing for people with disabilities](https://tetralogical.com/blog/) — series index (TetraLogical) - [Designing for people with anxiety](https://tetralogical.com/blog/) — series entry cited for the 9–11 reading-age claim - [Designing for people with low vision](https://tetralogical.com/blog/) — series entry - [Designing for people who are blind](https://tetralogical.com/blog/) — series entry - [Designing for people who are D/deaf](https://tetralogical.com/blog/) — series entry - [Dyslexia Scotland: Guide to dyslexia-friendly typed content (PDF)](https://www.dyslexiascotland.org.uk/) — cited resource - [Content Design London: Readability Guidelines](https://readabilityguidelines.co.uk/) — cited resource, source of the Sarah Winters quote - [GOV.UK Blog: Dos and don'ts on designing for accessibility](https://accessibility.blog.gov.uk/2016/09/02/dos-and-donts-on-designing-for-accessibility/) — cited resource - [Understanding WCAG 2.2 Success Criterion 3.1.5 Reading Level](https://www.w3.org/WAI/WCAG22/Understanding/reading-level.html) — cited resource, primary W3C source ## 🗣️ Paraphrase Reading isn't something people simply "can" or "can't" do — it runs on a spectrum, and for people with dyslexia, hyperlexia, or alexia, the basic act of turning letters into meaning takes real mental energy before comprehension even starts. That effort has nothing to do with intelligence; it's how their brains process written symbols. Designing around that reality means treating content and interface work as shared territory for writers and designers alike, not a checklist item handled solely by whoever owns accessibility compliance. The practical moves are unglamorous but specific: write in plain, direct language instead of academic phrasing; left-align text at 70–80 characters per line; use sentence-case, hierarchically-sized headings; and judge typefaces by letter features — distinct shapes, tall x-heights, open counters — rather than chasing a single "accessible font." Aim content at roughly a 9–11-year-old reading level, expand acronyms on first use, and don't be afraid to swap a paragraph for a diagram or video when it explains the idea faster. None of this waters content down — it just removes friction that was never necessary in the first place, and the people who benefit most (readers with reading disabilities) sit alongside everyone reading quickly, under pressure, or in a second language. ## 📰 Newsletter Turns out the fastest way to make your WordPress site more readable isn't a new font — it's fixing your line length. TetraLogical's latest "Designing for disabilities" entry digs into dyslexia, hyperlexia, and alexia, and lands on genuinely actionable guidance: left-align (skip justified text), cap lines around 70–80 characters, use sentence-case headings sized to match hierarchy, and pick typefaces for x-height and open letterforms rather than a single "dyslexia-friendly" label. If you're auditing a DevHub page, a plugin readme, or your own blog, it's a quick two-pass job — one pass with [Hemingway](https://hemingwayapp.com) for reading grade level, one pass eyeballing your heading structure. Bonus: the "no click here" link-text rule is good SEO hygiene too, so this is one of those rare accessibility fixes that pays for itself twice. ## ✅ Action Items #### DevRel - Developer advocacy: when demoing docs or SDKs live, model the plain-language habit — read code comments and error messages aloud and ask "would a 9th-grader parse this?" - Education: add a reading-level check (Hemingway or similar) to the workshop/tutorial content checklist before publishing. - Developer experience: audit quickstart docs for acronym density and justified-text CSS in rendered output. - Developer marketing: review campaign landing pages for line length and heading hierarchy, not just conversion copy. #### OSPO - Policy & Governance: no direct tie-in identified; low priority for this article. - License Compliance: no direct tie-in identified. - Security Management: security advisories are a strong candidate for plain-language + acronym-expansion review — high-stakes reading under time pressure is exactly the scenario this article targets. - Software Inventory: no direct tie-in identified. - Developer Support: support macros/canned responses are worth a plain-language pass. - Community Engagement: no direct tie-in identified. - Strategic Alignment: no direct tie-in identified. #### Community - Maintainers: add a "readability check" step to roadmap/governance doc templates. - Contributors: "first issue" onboarding docs are a good candidate for the 9–11 reading-age target, since new contributors are already under cognitive load. - Sponsors: no direct tie-in identified. - Ecosystem: no direct tie-in identified. #### WordPress - Core: no direct tie-in identified for this cycle. - Core Performance: no direct tie-in identified. - Core AI: AI-generated help text/error copy is a natural place to enforce plain-language and acronym rules programmatically. - Core Program Team: no direct tie-in identified. - Mobile: check justified-text rendering and line length on narrow viewports. - Playground: no direct tie-in identified. - Community: meetup/WordCamp slide decks are a common source of unexplained acronyms — worth a style-guide note. - Training: build a short lesson on writing for reading disabilities into the existing accessibility curriculum track. - Marketing: audit hero copy and CTAs against the "click here"/"read more" ban. - Support: response templates are prime real estate for the plain-language + short-paragraph guidance. - Design: fold the font-feature criteria (x-height, open counters, distinct glyphs) into design-token/typography review, independent of whichever typeface ships. - Documentation: DevHub/HelpHub pages are long-form and jargon-heavy — strong candidate for a heading-structure and line-length pass. - Photos: alt-text quality (not just presence) ties directly to this article's point about image descriptions. - TV: caption quality review. - Polyglots: reading-level guidance should travel with translations, not just the English source. - Accessibility: map this article's recommendations to WCAG 2.2 SC 3.1.5 (Reading Level) directly — it's the standards anchor already cited in the source. - Meta: no direct tie-in identified. - CLI: command help text and error messages are a good target for plain-language review. - Hosting: onboarding checklists for new site owners often skew technical — worth a pass. - Tide: no direct tie-in identified. - Openverse: alt-text/description quality guidance applies directly to image moderation criteria. - Themes: default theme typography should be evaluated against the letter-feature criteria, not against a single "accessible font" claim. - Plugins: plugin readme files are frequently acronym-dense and justified by default in some renderers — worth a lint check. #### The WPCC - Programs: no direct tie-in identified. - Projects: documentation sprints are a natural home for a plain-language/reading-level pass across contributor-facing docs. - Funding experiments: no direct tie-in identified. ### FAIR - Technical independence: no direct tie-in identified. - Policies and covenants: no direct tie-in identified. - Productized governance artifacts: charters and operator agreements are exactly the kind of dense, high-stakes document this article's plain-language and heading-structure guidance was written for. ## 🧪 Hypotheses - H1: Applying the article's layout rules (line length, left-align, heading hierarchy) to a documentation site measurably reduces average time-on-page for task-completion flows without reducing completion rate. - H2: A reading-level reduction (via Hemingway-style editing) to a 9–11 grade target increases self-reported comprehension among non-native-English readers more than among native readers. - H3: Font choice guided by letter-feature criteria (x-height, open counters, distinct glyphs) produces fewer transcription/typo errors in form fields than font choice guided by brand preference alone. - H4: Expanding acronyms on first use reduces support-ticket volume for jargon-related confusion in technical documentation. - H5: Descriptive link text ("download the 2024 report") outperforms generic link text ("click here") on both task-completion time and organic search click-through rate simultaneously. ### 📊 Methodology - H1/H2: A/B test two versions of the same documentation page (current vs. reformatted) with task-based usability testing; segment results by self-identified reading disability and by English-as-second-language status; use Hemingway or Flesch-Kincaid scoring as the independent variable. - H3: Controlled form-completion study across 2–3 typeface conditions chosen to vary specifically on x-height and counter openness, holding brand color/weight constant; measure field-level error rate. - H4: Before/after analysis of support-ticket tagging for a documentation set that adds first-use acronym expansion, controlling for overall traffic changes. - H5: Paired landing pages differing only in link-text style, tracked for both on-site completion and SEO click-through over a matched time window. ### ❓ Questions - Does the 9–11 reading-age target hold across technical/specialist audiences (developers, legal, medical), or does it need a separate calibrated target per domain? - How do the layout rules (line length, heading hierarchy) interact with responsive/mobile layouts where line length is already constrained by viewport rather than by design choice? - What's the actual failure mode when technical writing can't avoid jargon — does a glossary link get used in practice, or is it dead weight? - How does hyperlexia (strong decoding, weak comprehension) get designed for differently than dyslexia, given the article treats both under one recommendation set? ### 🔮 Future Research - A study directly comparing "one accessible font" claims (e.g., specific typefaces marketed as dyslexia-friendly) against the article's letter-feature criteria, to test whether the criteria approach actually predicts real-world readability better than font branding. - Longitudinal work on alexia specifically, since it's the one condition in this piece where reading ability changes after a baseline is already established — most web accessibility guidance implicitly assumes a stable reading profile. - Research quantifying alt-text *quality* (not presence) as a measurable metric, since the article flags this as underexamined. ### 💡 Implications - **Practice**: shifts editorial review from "did we run an accessibility scanner" to "did a human evaluate line length, heading structure, and reading grade level" — a workflow change, not just a tooling one. - **Policy**: strengthens the case for citing WCAG 2.2 SC 3.1.5 (Reading Level) explicitly in internal style guides rather than leaving it implicit in a general accessibility policy. - **Security**: security advisories and phishing-education copy are high-stakes, time-pressured reading contexts where this guidance has outsized impact. - **Education**: supports building "write for a 9–11 reading level" into onboarding/training curricula as a default skill, not a specialist one. - **Funding models**: none directly implicated by this article. ### 🧠 Learning Styles Assessment - Reading level estimate: approximate Flesch-Kincaid Grade ~8–9 for the source article itself (moderate sentence length, some domain terms like "alexia," "hyperlexia," short paragraphs) — estimated from sentence/paragraph structure, not run through a scoring tool. #### 👀 Visual learners - Present: an annotated x-height comparison image, a "thinking" concept illustration. - Improve: a labeled before/after example (justified vs. left-aligned block; wide vs. narrow line length) would make the formatting advice concrete rather than descriptive. #### 🔊 Aural learners - Present: none — no audio/podcast version linked. - Improve: a 2–3 minute narrated summary of the six design-consideration sections would suit this article's own subject matter unusually well. #### 🗣️ Verbal learners - Present: clear condition definitions (dyslexia/hyperlexia/alexia), a direct quote from Sarah Winters as an analogy anchor. - Improve: a worked "before/after" sentence rewrite (academic → plain language) would reinforce the abstract instruction with a concrete example. #### 🧩 Kinesthetic learners - Present: a step-by-step list under each design consideration. - Improve: a downloadable checklist or Hemingway-style live exercise would convert the guidance into a repeatable task. #### 🧠 Logical learners - Present: enumerated, criterion-based typography guidance (specific letter features). - Improve: a decision tree ("is this content technical? → use glossary link; is it acronym-dense? → expand and space out") would formalize the article's implicit logic. #### 🧑‍🤝‍🧑 Social learners - Present: none — no discussion prompts or community links. - Improve: a linked discussion thread or peer-review prompt for teams applying this to their own style guides. #### 🧘‍♀️ Solitary learners - Present: self-contained guidance usable without a group. - Improve: a self-audit checklist readers could apply to their own site before/after reading. #### 🌿 Naturalistic learners - Present: none. - Improve: not a strong fit for this content domain — low priority. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: descriptive image captions noted in source (e.g., "annotated x-height comparison"). - Improve: verify heading landmarks in the live page match the sentence-case/hierarchy advice the article itself gives — worth checking the article practices what it preaches. #### Keyboard navigation - Present: not assessable from article text alone. - Improve: standard skip-link and focus-order checks apply; no article-specific gap identified. #### Contrast and readability - Present: the article's own guidance (open fonts, adequate x-height) doubles as a contrast/readability recommendation. - Improve: apply the "squint test" the article recommends to the article's own body text as a self-check. #### Text resizing and reflow - Present: not assessable from text alone. - Improve: verify 70–80 character line length target holds at 200% zoom, since character count and viewport width interact. #### Media and captions - Present: image alt text implied but not verifiable from provided content. - Improve: article calls out description *quality* as the real gap — worth an explicit audit of its own images against that standard. #### Forms and interactions - Present: n/a — no forms on this content page. - Improve: n/a. #### Standards reference - Maps most directly to WCAG 2.2 SC 3.1.5 (Reading Level), and secondarily to SC 1.4.8 (Visual Presentation, line length/justification) and SC 1.4.12 (Text Spacing). ### 🌍 DEIB Assessment #### Cultural breadth - Present: explicit mention of second-language readers as a beneficiary group. - Improve: no non-English or region-specific examples included. #### Inclusive language - Present: person-first, non-pathologizing framing ("difference in how the brain processes," not "deficit" or "disorder"). - Improve: could define "hyperlexia" and "alexia" slightly more before using them, since they're less commonly known than "dyslexia." #### Neurodiversity support - Present: this is the article's core subject — chunked sections, consistent heading structure, explicit reading-disability focus. - Improve: could add a worked example per condition (dyslexia vs. hyperlexia vs. alexia) rather than one shared recommendation set. #### Representation - Present: acknowledges reading disability isn't tied to intelligence or education level. - Improve: no first-person accounts or quotes from people with reading disabilities themselves — the Sarah Winters quote is about content design, not lived experience. #### Psychological safety - Present: respectful, non-judgmental framing throughout ("nothing to do with intelligence"). - Improve: no content warning needed; tone is already careful. ### ✅ Logical Validity #### Strong reasoning - Analogical reasoning: implicitly applies a curb-cut-effect argument (design for the edge case, everyone benefits) — stated directly in the closing line about people in a hurry or reading a second language. Clear and effective without being overstated. - Criterion-based reasoning: the typography section replaces a single prescriptive answer ("use this font") with falsifiable criteria (x-height, open counters, distinct glyphs) — stronger and more durable than a font recommendation. #### Fallacies - Unsupported statistic: the "9–11 year old average adult reading age" claim is stated as established fact and only sourced via a link to the site's own earlier post, not a primary source in this piece — a mild appeal-to-repetition rather than appeal to authority. Fix: cite the underlying literacy study directly in this post too, not just via cross-reference. - Mild false-dichotomy risk: "plain language vs. academic writing style" is presented as roughly binary; the technical-writing subsection actually complicates this (acceptable jargon with glossary support), which resolves the tension — but a reader skimming only the plain-language section could walk away with an oversimplified rule. #### Tone of voice - Practical, instructive, mildly informal ("dip into other posts," direct imperatives: "Be direct," "Use tools like Hemingway"). Confident but not prescriptive to the point of being preachy — consistent with a specialist-firm blog aimed at working practitioners rather than a general audience. ## 🛡️ DARVO Analysis - This is instructional/educational content with no accusation, conflict, or defensive posture present — DARVO framework does not meaningfully apply. - Deny: n/a — no denial or minimization is present; the article is direct about the reality and prevalence of reading disabilities. - Attack: n/a — no target being attacked or discredited. - Reverse victim/offender: n/a — no victim/offender framing exists in this content. - Emotional cues/rhetoric: tone stays informative rather than persuasive-through-emotion; the strongest rhetorical device is the closing curb-cut-effect line, which is affirming rather than manipulative. ## 🎯 Conclusion Reading disabilities sit on a spectrum most design systems don't account for, and TetraLogical's piece converts that gap into concrete, testable moves — line length, heading hierarchy, letter-feature typography criteria, and a 9–11 reading-age target — rather than another abstract accessibility principle. The practical next step for most teams is small: run existing docs through a reading-level check, audit for justified text and acronym density, and evaluate the current typeface against x-height and open-counter criteria instead of assuming an "accessible font" label already solved it. ## 🔄 Refactor Appendix — Designing for people with reading disabilities > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. > > Konik claim-header rules: present tense, declarative, ≤10 words when > possible, searchable, unique, mirrors annotation focus if present. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) #### Reading disabilities reflect brain processing, not intelligence > [!quote] > Reading disabilities have nothing to do with intelligence. They are a difference in how the brain processes written information. **Context & use**: - From the "Thinking" framing section, early in the piece. - Sets the non-pathologizing tone the rest of the article's recommendations build on — worth anchoring any UX copy or support-macro rewrite to this framing. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> #### Plain language opens access, it doesn't dumb content down > [!quote] > If you make your content easy to read, you aren't 'dumbing down', you are opening up your information to anyone who wants to read it. **Context & use**: - Sarah Winters (Content Design London) quote, "Use plain language" section. - The reframe to reach for whenever a stakeholder resists simplifying copy. **Tags**: #xref #aphorisms <!-- atomicity: 1 idea ✓ --> #### Letter features beat font branding for readability > [!quote] > Research shows that letter features matter more than using a specific 'accessible' font. **Context & use**: - Opens the "Prioritise font features" section. - Replaces "pick this typeface" advice with checkable criteria (x-height, open counters, distinct glyphs) — applies even to a brand's existing font choice. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### Designing for reading disabilities widens access for everyone **Claim** (one sentence, Courtney's voice): Content designed to reduce decoding effort for people with reading disabilities — plain language, short lines, criterion-based typography — also measurably helps people reading in a hurry, under stress, or in a second language. **Evidence pointer**: [[Designing for people with reading disabilities#Reading disabilities reflect brain processing, not intelligence]] **Scope & conditions**: - Holds when: the content is general-audience or mixed-technical, and the reduction in complexity doesn't remove information the reader needs to act. - Breaks when: highly specialized fields (medicine, law, deep technical docs) require precision that plain-language rewriting would erode — the article's own fix here is glossary links and first-use expansion, not blanket simplification. **Links**: - [[Curb-cut effect]] — because extends - [[Plain language writing]] — because applies-in content design and documentation - [[WCAG 2.2 Success Criterion 3.1.5]] — because evidence-for <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Run Hemingway (or similar) reading-level check as a standard editorial step, not a one-off audit — https://hemingwayapp.com #fleeting #inbox - [F2] Look into WCAG 2.2 SC 3.1.5 (Reading Level) as the formal standards anchor for future accessibility-writing notes — #fleeting #inbox #articleseed ### → Things 3 (max 2 actions) - [ ] Audit flagship site's default body font against x-height / open-counter / distinct-glyph criteria — typography-review #things - [ ] Run top 5 documentation pages through a reading-level checker and flag any above grade ~11 — content-audit #things <!-- deep-read:sections end --> ## Highlights - Reading disabilities have nothing to do with intelligence. They are a difference in how the brain processes written information. - Note: 📚 Reading disabilities reflect brain processing, not intelligence · - From the "Thinking" framing section, early in the piece. - Sets the non-pathologizing tone the rest of the article's recommendations build on — worth anchoring any UX copy or support-macro rewrite to this framing. · #atom/literature/h1 - If you make your content easy to read, you aren't 'dumbing down', you are opening up your information to anyone who wants to read it. - Note: 📚 Plain language opens access, it doesn't dumb content down · - Sarah Winters (Content Design London) quote, "Use plain language" section. - The reframe to reach for whenever a stakeholder resists simplifying copy. · #atom/literature/h2 - Research shows that letter features matter more than using a specific 'accessible' font. - Note: 📚 Letter features beat font branding for readability · - Opens the "Prioritise font features" section. - Replaces "pick this typeface" advice with checkable criteria (x-height, open counters, distinct glyphs) — applies even to a brand's existing font choice. · #atom/literature/h3 - Designing for reading disabilities widens access for everyone - Note: Holds when: the content is general-audience or mixed-technical, and the reduction in complexity doesn't remove information the reader needs to act. · - [[Curb-cut effect]] — because extends · #atom/zettel/z1 - Run Hemingway (or similar) reading-level check as a standard editorial step, not a one-off audit — https://hemingwayapp.com - Note: ✏️ Fleeting capture #atom/fleeting/f1 - Look into WCAG 2.2 SC 3.1.5 (Reading Level) as the formal standards anchor for future accessibility-writing notes — #fleeting #inbox #articleseed - Note: ✏️ Fleeting capture #atom/fleeting/f2 ## New Highlights added 2026-07-20 at 10:55 AM - Reading disabilities have nothing to do with intelligence. They are a difference in **how the brain processes written information**. When reading is exhausting, people have less energy for understanding and decision-making. ([View Highlight](https://read.readwise.io/read/01kxzyq6e0x2jcptd3g8szmp6f)) - Note: Reframes reading disability as a processing difference, not a capability deficit — and names the cognitive-fatigue cost. - Tags: atom/literature/h1 - Research shows that letter features matter more than using a specific "accessible" font. Follow these typography guidelines when you can: ([View Highlight](https://read.readwise.io/read/01kxzyqawk70pxjb96ates1pjb)) - Note: Debunks the "dyslexia font" myth — distinguishable letter features beat any branded accessible typeface. - Tags: atom/literature/h2 ## Links - [[3. Resources/Permanent Notes/Readable Typography Depends on Letter Features Not a Branded Dyslexia Font]] — evidence-for: concrete letter features outperform a universal font prescription. - [[3. Resources/Permanent Notes/A Defense Experts Fail Is Not a Defense for Users]] — applies-in: readable content must work without specialist interpretation.