Text Style Adjustable

LaZay opens #161 asking that font selection join the other user-adjustable properties in 1.4.8, noting publishers still ship serif paper fonts in digital products where they blur on screen, and that any offered families have to exist on the user's machine — a harder implementation problem than other CSS overrides. LaurenceZaysser makes the same case in #340 as a gap rather than an enhancement: 1.4.4 Resize Text has no font-family equivalent, browsers and ebook reading systems already do this, and WCAG 2.2 is therefore not the full EAA cover it is claimed to be, since Annex I requires fonts of suitable shape. Proposes a new SC 1.4.14 Change font family with a sufficient technique naming OpenDyslexic.

Argues in #245 that a meaningful, testable normative standard covering all font use cases is out of reach, though blocks of body text might be a candidate. The reason is that line-height, letter-spacing, font-weight and font-size are all relative to decisions the font designer made, so two faces set at 16px and weight 400 rasterise at different real sizes and weights. Proposes CSS-level fixes — a property to set x-height directly, already filed with the CSSWG, and line-height expressed against x-height — and gives concrete targets: critical size is an x-height at least twice measured acuity height, lowercase aspect ratio under 1.5:1, baselines about 2.5 x-heights apart. Notes a century of research has produced little consensus beyond "blackletter fonts are hard to read".

In #245 in 2022, before the OpenDyslexic proposals in #161 and #340 were filed, argues that fonts like OpenDyslexic and Dyslexie are not actually useful, because they assume dyslexia is a visual problem when it is language-specific. Cites Marinus, Mostard et al., where increasing letter spacing on plain Arial produced the same benefit as Dyslexie, implying the gain comes from reduced crowding rather than glyph shape. Adds that dyslexia is almost unheard of in Korean, which is a clear language, so glyph-level remedies do not generalise across writing systems — of which there are at least 40 common ones.

If CSS is not expressive enough for authors to declare these properties or for tools to query them from a rendered page, and font choice is effectively unlimited, a tester would have to run the numbers against every font an author picked — complicated further by user agents and operating systems shipping their own slight variants of nominally identical fonts and doing substitutions. Pushes chaals directly: if the user agent does not supply an accessible font, does the site then fail in that user agent? Draws the line at information, advice and best practice being fine, while mandatory requirements built on the same evidence is where it gets interesting.

Where the user agent supplies the font, the requirement belongs on the user agent to offer accessible fonts. Research on this has existed for a long time, so publishing information about which fonts are more accessible — and to whom, and when — should not be beyond the group. Adds the author-side corollary: if you choose fonts and want accessible content, logic says you check whether the fonts you chose achieve that.

In #413, reads G183's "if there are not a large number of links" caveat as an implicit allowance for a different treatment in high link-density content such as wikis and glossaries. Argues G182's non-underlined alternatives — blue bold, red italic — are not reliably read as links, because user expectation is anchored to underlines. Proposes a Method under the adjustable text style guideline using text-decoration-style: dotted, with a demo file attached, to keep links perceivable while cutting visual clutter.