Standards

WAI-Adapt

Also: Personalisation Semantics, WAI Personalization Semantics, Adapt

The W3C's emerging vocabulary for personalisation semantics — letting users adapt content to their cognitive, sensory, and motor preferences through declarative metadata rather than user-customised CSS.

WAI-Adapt (formerly “Personalisation Semantics”) is a W3C effort to give authors a way to declare what content means — what kind of element it is, what symbol could represent it, how distracting it is — so that user agents and assistive technologies can adapt the rendering to the user’s needs.

It’s still in working-draft status as of 2026. Adoption is early. But the framing is important enough that the term shows up in accessibility roadmaps, especially around cognitive accessibility.

Why the W3C started it

Today’s accessibility model is heavily user-pull: the user customises their browser, installs extensions, configures their screen reader, and hopes the site renders well under those customisations. WAI-Adapt inverts that: the content declares its semantics, and the user agent can transform the rendering to suit the user without changing what the content means.

A simple example: a webform asks for “first name” and “last name.” WAI-Adapt would let the author tag those inputs with semantic attributes that say “this is a personal-name field.” A user with cognitive disability could then have their assistive technology substitute symbol-based prompts (”👤 your name”) for the text labels — without the site author having to ship both versions.

The three modules

The draft splits into three modules:

  1. Content module — vocabulary for marking up content semantics that user-agent adaptation needs. data-purpose, data-action, data-destination, etc.
  2. Help and Support module — attributes for declaring help content variations (long form, plain language, symbol-supported, simplified).
  3. Tools module — interoperability with assistive technologies that provide personalisation features (symbol-set systems, predictive text tools, focus-and-attention aids).

Where it sits relative to other specs

WAI-Adapt is complementary to WCAG, ARIA, and the cognitive- accessibility task force’s findings. It’s not a replacement for any of them. WCAG defines the access floor; ARIA defines the assistive-tech interface; WAI-Adapt defines the personalisation channel.

It’s also complementary to WCAG 3, which is going further on cognitive accessibility than WCAG 2.x ever did. WAI-Adapt is one of the mechanisms WCAG 3 outcomes may rely on.

What it means for engineering teams today

For most teams the answer is: nothing operational yet. The vocabulary is still drafty. The user-agent support is essentially zero. There is no Pa11y rule, no axe-core rule, no Lighthouse audit for WAI-Adapt attributes.

But the framing is worth knowing. When you ship a site that lets users toggle “simpler view” or “show symbols,” you’re inventing — locally — what WAI-Adapt is trying to standardise. As the spec firms up over the next 2-3 years, expect to see the first wave of authoring tools generating WAI-Adapt attributes by default.