Accessibility release notes: announcing changes to assistive-technology users

Accessibility changes are some of the highest-stakes things a product ships, and some of the least announced. When they appear in release notes at all, it’s usually as two words — “improved accessibility” — which tells a screen-reader user nothing about whether the bug that’s been blocking them for months is fixed, and tells an accessibility auditor nothing they can cite. This guide is about doing better: how to announce accessibility fixes, how to warn assistive-technology users before you change the interface they’ve memorized, and how your changelog relates to the formal conformance documents (VPAT, ACR) that procurement teams increasingly ask for.

Two different readers care, and they read differently. The first is a person who uses your product through assistive technology — a screen reader, voice control, switch access, magnification, or just the keyboard — and who needs to know exactly what changed in their interface. The second is an accessibility specialist, auditor, or buyer tracking your conformance claims over time. Both are chronically underserved, which means serving them well is unusually visible.

The interface you never see is still an interface

For a screen-reader user, your heading structure, landmark order, focus order, and accessible names are the UI. They aren’t an invisible implementation detail — they’re the surface the product is operated through. That has a consequence most teams miss: a visual-only redesign, the kind that changes no APIs and gets shipped as a routine improvement, can be a breaking change for assistive-technology users:

  • Muscle memory breaks. Experienced screen-reader and keyboard users navigate by memorized sequence — jump to the third heading, Tab twice, Enter. Reorder the landmarks or the focus order and that sequence now activates the wrong thing.
  • Scripts and voice commands break. JAWS scripts, Dragon voice commands, and switch-access setups are often keyed to accessible names and element order. Renaming a button’s accessible label is an interface rename, exactly like renaming a menu item — the localization problem from the localization guide, aimed at a different audience.
  • Documented shortcuts break. If you publish keyboard shortcuts, they’re an interface contract. Changing one silently strands the users who depend on them most.

The rule that follows: changes to keyboard paths, focus order, shortcuts, or accessible names get announced like breaking changes — before or at release, with the old and new behavior stated plainly, per the breaking-changes playbook. “The Save shortcut moved from Ctrl+S to Ctrl+Shift+S; Tab from the search field now lands on the results list instead of the filters” is one sentence, and it converts a morning of silent confusion into a ten-second adjustment. A redesign entry that describes only the visual changes is telling assistive-technology users the release notes aren’t for them.

Fixes are features here

An accessibility fix is not a “misc fix.” To the person affected, it is the release — often the difference between being able to use a workflow and needing a colleague to do it for them. Write these entries with the same care as feature launches, and with the same symptom-first discipline as any good changelog entry:

  • Name the assistive technology precisely. “Fixed: NVDA and JAWS read the invoice table headers in the wrong order” — not “improved screen reader support.” Screen-reader bugs are usually specific to an AT-and-browser pairing, and the person searching your changelog knows exactly which pairing they use. Say which were affected and, when you know, which weren’t.
  • Describe the symptom the user experienced, not the attribute you changed. “The date picker can now be operated with arrow keys” beats “added ARIA attributes to the calendar component.” The second is a diff; the first is a capability.
  • Close the loop. Accessibility bugs are disproportionately reported by the people they block, and those reporters may have waited months while the fix worked through the backlog. A specific entry is how they learn it shipped — and per the beta guide’s credit rule, “reported by a user — thank you” costs nothing and buys the next report.

There’s also a colder business read: every accessibility fix expands who can use your product. Announcing them specifically is how prospective users — and the specialists who advise them — discover that your product works with their setup at all.

Announce regressions like the incidents they are

Accessibility regressions land harder than most bugs because workarounds are scarce. A sighted user routes around a broken button by clicking something else; a screen-reader user may have no path at all. When a release breaks an assistive-technology flow, treat it with hotfix-communication rules: a prompt, honest entry naming the symptom and the affected AT versions, a workaround if one exists (“the action is still available from the row’s context menu”), and an edit to the same entry when the fix ships. A known-issues line in the release entry that broke it — “known issue: VoiceOver doesn’t announce the new filter chips; fix scheduled” — is the cheapest trust you can buy, and its absence reads as not having tested with a screen reader at all.

Two documents, two clocks: the changelog and the conformance report

If enterprises or public-sector customers buy your product, accessibility has a second, formal document: the Accessibility Conformance Report (ACR), usually built on the VPAT template, stating how the product measures against WCAG, Section 508, or EN 301 549. Procurement asks for it, and since the European Accessibility Act became enforceable in June 2025, more buyers ask than ever.

The relationship between the two documents mirrors security advisories vs the changelog: the changelog is the ship-time signal — dated, specific, append-only — while the ACR is the periodic formal claim, re-issued on its own clock. Three rules keep them honest together:

  • Date the ACR and pin it to a version. A conformance report that doesn’t say which release it evaluated is unfalsifiable. “Evaluated against v4.2, March 2026” makes it a real claim.
  • Let the changelog carry the movement. When you fix something the ACR listed as “partially supports,” the changelog entry ships now; the ACR catches up at its next revision and can cite the entries that closed the gap. Permalinked entries — stable URLs per fix — are exactly what an auditor or a customer’s accessibility team wants to link in their own assessment, the same evidence-trail role the changelog plays for compliance reviews generally.
  • Never let marketing outrun the report. If the site says “fully accessible” while the current ACR says “partially supports” on a dozen criteria, the buyer’s auditor will find the gap in minutes — and every other claim you’ve made gets re-read in that light.

Where accessibility notes live

Most products that take this seriously converge on three surfaces with distinct jobs:

  • An accessibility statement page — the snapshot: what standard you target, known limitations, how to reach you. This page is docs, not changelog: edited in place, current by definition. It should link to the changelog for history, and its “known limitations” list should shrink as entries ship.
  • The changelog itself, filterable. Tag accessibility entries and link the filtered view from the statement page — a living “what we’ve fixed lately” list that no one has to maintain by hand. An unbroken run of dated, specific accessibility entries is the strongest conformance signal a buyer can find, for the same reason SQLite’s unbroken history works as social proof.
  • Feeds. Many assistive-technology users prefer RSS or email — a feed item is plain, linear, fully accessible content, with none of the focus-management risk of in-app popovers. A per-tag or whole-project feed serves them updates in the channel that works best with their tools.

And the meta-rule, easy to state and embarrassing to fail: the changelog page itself must be accessible. Real headings per entry so screen-reader users can jump between releases, dates as text rather than icons, contrast that holds in both themes, and — if you use an in-app widget — a panel that’s keyboard-reachable, focus-managed, and dismissible with Escape, per the widget guide. An inaccessible page announcing accessibility fixes is a genre of irony no one forgets. The craft rules are in changelog page design; they’re identical to plain good HTML.

What a good entry looks like

Fixed — screen readers: invoice table headers announced correctly

Affected: NVDA and JAWS with Chrome and Firefox. VoiceOver was not affected.

What changed: the invoices table now uses real header cells, so each
value is announced with its column name instead of the headers being
read once at the top. Reported by a user — thank you.

Also in this release: after closing the edit dialog, focus returns to
the row you were editing (previously it jumped to the top of the page).

Conformance: addresses WCAG 2.2 SC 1.3.1 (Info and Relationships);
our conformance report will reflect this at its next revision.

Symptom first, assistive technologies named, capability described in the user’s terms, focus behavior called out, and the formal claim connected — every reader this entry is for can find what they need in ten seconds.

Six anti-patterns

  • “Improved accessibility.” The two-word entry. It gives the blocked user nothing to check, the auditor nothing to cite, and reads as box-ticking. If you can’t name what changed, the entry isn’t done.
  • The redesign entry with no assistive-technology line. Three paragraphs on the new look, zero on what happened to focus order, landmarks, or shortcuts. The people most affected by the change are the ones the entry ignores.
  • Silent shortcut and focus changes. Shipping a keyboard-path change with no entry at all — the assistive-technology equivalent of an unannounced breaking API change.
  • Hiding fixes out of embarrassment. Teams sometimes bury accessibility fixes because a specific entry admits the thing was broken. Wrong read: a public record of dated fixes is evidence of diligence; silence is evidence of neglect. Buyers’ auditors know which one they trust.
  • The frozen ACR. A conformance report last revised three years ago under a version two majors back, while the marketing site claims full conformance. Worse than no report — it documents that you stopped checking.
  • Announcing an overlay as a fix. “We’re now accessible — we added an accessibility widget” — third-party overlays don’t repair broken semantics, are widely distrusted by the users they claim to serve, and announcing one as conformance tells every accessibility specialist reading that no one on the team asked them.

How this works in Wakelog

Wakelog’s public changelog pages are built the way this guide asks: server-rendered semantic HTML with a real heading per entry, text dates, keyboard-navigable everything, contrast checked in light and dark themes, and zero axe violations as a maintained property — so the page announcing your accessibility work holds up under the same audit. Every entry gets a stable permalink you can cite in an ACR revision, a support reply, or an accessibility statement’s “recently fixed” list. Tags give you the filtered living view (?tag=fix today; use a project per audience if you want a dedicated accessibility stream), and every project ships RSS and JSON feeds for readers who’d rather meet updates in their feed reader than in a popover. The honest caveats: Wakelog won’t write your VPAT, can’t audit your product, and no tool can notice that Tab lands somewhere new — testing with a screen reader, and writing down what you find, stays your job.

Start your changelog — free   Next: release notes for non-technical users →

Related guides

Last updated 2026-07-29 · All guides