Accessibility Preferences API for Browsers and JavaScript

[Kaelunyx]

Accessibility Preferences API Proposal

Summary

This proposal suggests a new browser-level accessibility system that allows users to define preferences — such as dyslexia support, color vision type, and contrast level — through a dedicated “Accessibility” settings tab. These preferences would be exposed to websites via JavaScript, enabling automatic adaptation of fonts, colors, and layout for better readability and inclusion.

---

Problem

People with dyslexia or color blindness often struggle to read websites comfortably. Today, they must manually install fonts, browser extensions, or rely on developers to offer accessibility toggles — which most sites don’t. Even when fonts like OpenDyslexic exist, they’re not universally supported, and many users can’t afford or configure them easily.

There’s no native way for a browser to tell a website:

“This user has dyslexia”

“This user has protanopia”

“This user prefers high contrast”

And there’s no standardized way for developers to respond to those needs automatically.

---

Proposed Solution

Browsers should offer a built-in Accessibility tab where users can set:

• Reading preference: Dyslexia-friendly mode (with optional custom font)
• Color vision type: Protanopia, Deuteranopia, Tritanopia
• Contrast preference: High, low, or default

These settings would be exposed to websites via a new JavaScript-accessible API, such as:

navigator.accessibilityPreferences

Example usage:

if (navigator.accessibilityPreferences?.font === "dyslexia") {
    document.body.classList.add("font-dyslexia");
}

if (navigator.accessibilityPreferences?.colorVision === "protanopia") {
document.body.classList.add("color-protanopia");}

---

Font Handling

If the user selects dyslexia support, the browser could apply a custom font automatically — either a system default or one chosen by the user. Developers wouldn’t need to invent new font names or load external files.

CSS could support something like:

font-family: preferred;

Or simply:

font-family: initial;

Where `preferred` refers to the user’s accessibility-defined font. This would make it easier for developers to support dyslexia-friendly fonts without complex JavaScript or font loading logic.

---

Why This Matters

This idea is about real inclusion. It helps people who read differently, see differently, and experience the web differently — without forcing them to install anything or fight with settings.

It’s also about fairness: not everyone can afford paid fonts or tools. Accessibility should be built into the browser, not sold separately.

If this idea — even just the core structure — isn’t considered, it would be a missed opportunity for the web to become truly inclusive. This proposal took effort to write, and it comes from someone who sees the world differently and wants to make it better.

[rohankh · Accepted solution]

Key benefits you’re aiming for

• Persistent, user-defined accessibility preferences that persist across sessions and devices (if synced).
• Consistent behavior across sites without requiring users to install fonts or extensions.
• A simple, browser-native way for sites to adapt content automatically via a standardized API.
• Reduced fragmentation: developers wouldn’t need to guess which fonts or color tweaks to ship.

Design considerations and concrete suggestions

1. Accessibility Preferences UI

• Placement: A dedicated Accessibility tab in browser settings, with clear sections:
  • Reading preferences (e.g., dyslexia-friendly mode, optional font selection)
  • Color vision type (none, protanopia, deuteranopia, tritanopia, etc.)
  • Contrast level (high, default, low)
  • Optional: motion sensitivity, font size scaling, line height
• Persistence and sync: Options to sync preferences across devices via the user’s browser account, with user-consent and clear privacy controls.
• Accessibility-first defaults: Ensure high-contrast and dyslexia-friendly defaults can be forced when needed, even if a site requests different styles.

1. JavaScript API design

• Proposed API surface: navigator.accessibilityPreferences
• Shape example:
  • gender-neutral naming and extensibility:
    • preferences: {
      reading: { dyslexia?: boolean, fontFamily?: string },
      colorVision?: "none" | "protanopia" | "deuteranopia" | "tritanopia" | "custom",
      contrast?: "default" | "high" | "low",
      fontSizeScale?: number
      }
• Fallback and privacy:
  • If the user disables sharing or denies permission, properties should be undefined or null to avoid breaking sites.
  • Consider a default values object for ease of feature detection.
• Eventing:
  • Provide a way for pages to react to preference changes at runtime (events or a getter + update event).

1. Font handling and content adaptation

• Dyslexia support:
  • Instead of shipping fonts via pages, offer a user-level font palette. The browser could map a user-selected dyslexia-friendly font to a CSS variable (e.g., --accessible-font) that sites can use with font-family: var(--accessible-font, initial);
  • Optional: a browser-managed font fallback stack that prefers a dyslexia-friendly font if available on the system.
• Color vision:
  • Prefer non-destructive CSS changes (e.g., CSS filters, color-macing via prefers-color-contrast-like variables) rather than forcing entire site rewrites.
  • Allow sites to opt into a baseline color transformation, with an override mechanism if content is already designed in an accessibility-friendly palette.
• Developer ergonomics:
  • Provide web-platform guidelines and a minimal polyfill for sites to adopt quickly.
  • Recommend CSS variables that sites can query (e.g., color-scheme-aware tokens) rather than hard-coding values.

1. Security, privacy, and boundaries

• Local control:
  • All preferences should be stored locally by the browser, with optional cloud sync under user control.
• API surface risk:
  • Exposure should be read-only from the page perspective, or at most allow a controlled write for experimental features (to prevent spoofing across sites).
• Web compatibility:
  • Proactively coordinate with standards bodies (W3C) to ensure the API is forward-compatible and well-specified.

1. Cross-device syncing and “active device” concept

• Cross-device sync could be implemented via:
  • Cloud-backed state with user consent, using a per-user identity.
  • The “active device” concept could be realized by allowing only the device that is currently in use or has the tab focused to trigger live changes or notifications, while other devices maintain their own separate state.
• Practical approach:
  • If a timer or notification is involved, treat accessibility preferences as a user preference, not an event source. Cross-device syncing would apply to the preference state itself, not to per-site DOM changes.
  • If sites rely on the API to adjust UI, ensure that changes are non-disruptive and reversible.

Implementation path (high level)

• Phase 1: API and UI spec

  • Draft a concrete API surface (navigator.accessibilityPreferences) with a stable shape, default values, and a small set of fields.
  • Define events or a subscription mechanism so pages can respond to preference changes without polling.
  • Propose a minimal set of CSS custom properties and recommended class names or tokens for dyslexia-friendly fonts, color themes, and contrast tweaks.

• Phase 2: Pilot and ecosystem engagement

  • Run a multi-browser pilot (e.g., Firefox, Chrome, and a Chromium-based browser) to test API ergonomics and site adoption.
  • Provide an official developer guide with examples (CSS variables, optional classes, and a small JS helper).

• Phase 3: Accessibility-first defaults and user research

  • Gather feedback from users with dyslexia and color vision differences.
  • Iterate on defaults (e.g., font sizes, spacing, color palettes) and responsiveness.

• Phase 4: Developer tooling

  • Provide a quick-start snippet for sites to opt into the API.
  • Build a simple web-wide sample library that demonstrates listening to navigator.accessibilityPreferences and applying CSS variables.

Potential challenges

• Consistency across sites with varying frameworks and hard-coded styles.
• Performance implications of runtime CSS changes on very large pages.
• Privacy concerns if any cross-site data is inferred; ensure transparency and user consent.

[silnith]

This is a good idea, but runs a real risk of creating a new persistent leak of private information.

The original intent of CSS was allowing browser users to override website styles for exactly the reasons you cite: changing fonts, colors, text padding and margins, etc. The CSS standard has provisions for sites to offer alternative stylesheets that users can switch between, Firefox used to expose that in the “View -> Page Style” menu (I have not checked lately). But the real power was supposed to be in user stylesheets that explicitly overrode whatever the site specified.

Unfortunately, the pervasiveness of pixel-specific units and forced layouts made user stylesheets very difficult to use in practice.

But given that the original design of the web was one of user control, and that has slowly been replaced with a world where webpages have control over users instead, and the people building these websites are the ones who asked for this reversal of power while also ignoring the accessibility needs of the users (and ignoring the accessibility features built into standards like HTML and CSS in favor of the control of client-side scripting), I suspect that just providing more private information to those web developers and politely asking them for support without exploitation… will not be particularly successful.