W3C's accessibility mapping spec reached Candidate Recommendation on October 21, 2026 — the unglamorous step that decides whether sectionheader, sectionfooter and ariaNotify actually reach assistive technology.
TL;DR: On October 21, 2026, the W3C's Accessible Rich Internet Applications Working Group pushed Core Accessibility API Mappings (Core AAM) 1.2 to Candidate Recommendation, alongside refreshed drafts of Accessible Name and Description Computation 1.2, HTML Accessibility API Mappings 1.0, and SVG Accessibility API Mappings — all listed the same day on the ARIA Working Group's publications page. Core AAM is the spec that tells browsers how to translate WAI-ARIA roles and properties into the platform accessibility calls — MSAA, UIA, ATK/AT-SPI, the macOS AX API, Android — that screen readers actually consume. This update is the first to formally define mappings for the sectionheader and sectionfooter roles and the ariaNotify API that WAI-ARIA 1.3 introduced back in June.
It's a quiet release — nobody is shipping a new CSS property or a flashy browser demo this week — but it's the release that decides whether those June additions mean anything to a screen reader user. Teams doing standards-compliant web development at YuSMP are increasingly the ones who end up explaining this gap to clients: a role can exist in the DOM for months before any assistive technology stack actually knows what to do with it, because the ARIA spec and the API mapping spec are deliberately two separate documents that advance on separate schedules.
Core AAM 1.2 moved from Working Draft to Candidate Recommendation — the stage where the Working Group is saying the spec is technically complete and now wants implementations and wide review, not more design churn. Three companion documents were refreshed the same day: Accessible Name and Description Computation 1.2, which governs how a browser decides what string to read out for an element's accessible name; HTML Accessibility API Mappings 1.0, which does the Core AAM job specifically for native HTML elements; and SVG Accessibility API Mappings, the same exercise for inline SVG. None of these are roles-and-states specs — they're the plumbing underneath the roles-and-states spec, and plumbing updates rarely make headlines even though they're what makes the headline features work.
WAI-ARIA defines the vocabulary: role names, states, properties, and what they mean in the abstract. It does not define how an operating system's accessibility layer should represent any of it, because that's platform-specific and ARIA is explicitly platform-agnostic. That gap is filled by Core AAM, which is the only document that says, concretely, "when a browser encounters this ARIA role, it should expose this control type with this set of properties to this specific accessibility API." Skip that step and an ARIA role is semantically defined but functionally invisible — the DOM says one thing, the accessibility tree says nothing, and a screen reader user gets silence.
The two headline additions in this Core AAM 1.2 draft are mappings for the sectionheader and sectionfooter roles and for ariaNotify. The roles — first introduced in the WAI-ARIA 1.3 Working Draft published in June — give a name to the introductory and closing material of a content section: a sectionheader groups a section's heading and byline-style metadata, and a sectionfooter groups trailing material like authorship, related links, or copyright for that same section, distinct from the page's global <header> and <footer>. ariaNotify is a scripted API for pushing an announcement to assistive technology directly, without the long-standing workaround of writing text into a hidden aria-live region and hoping the browser notices the DOM mutation in time.
Nothing changes in your markup today. A Candidate Recommendation is not a browser commitment, and Core AAM existing on paper doesn't mean any given screen reader honors it yet — implementers now have a concrete, reviewable target to build against, which is the step that has to happen before that can occur. If you're already experimenting with sectionheader/sectionfooter or planning to replace a hidden live-region hack with ariaNotify, treat both as progressive enhancement: keep your existing <header>/<footer> landmarks and aria-live fallback in place, test with at least two screen reader and browser combinations before relying on either in production, and don't assume parity across engines — a mapping spec reaching Candidate Recommendation is necessary for consistent cross-browser behavior, but it isn't sufficient on its own.
Candidate Recommendation is not the finish line. The next formal steps are a wide-review period, then Proposed Recommendation, then Recommendation — a process that has historically taken accessibility API mapping specs anywhere from several months to a couple of years, since it depends on independent implementations from multiple browser and assistive-technology vendors, not just a vote. Don't plan a 2026 launch around these mappings; do start watching MDN and your screen reader vendor's release notes, since mapping updates like this one are usually the leading indicator that real support is coming.
It's the W3C specification that defines how browsers should expose WAI-ARIA roles, states and properties to platform accessibility APIs — MSAA, UIA, ATK/AT-SPI, the macOS AX API and Android — so that screen readers and other assistive technology can interpret them.
Not reliably. The roles are still a Working Draft addition from WAI-ARIA 1.3, and their accessibility API mapping only reached Candidate Recommendation on October 21, 2026. Keep using native <header> and <footer> landmarks as your baseline until support is confirmed across the browsers and screen readers you target.
It lets a script push an announcement to assistive technology directly, replacing the common workaround of writing text into a hidden aria-live region and depending on the browser to notice the mutation and announce it reliably.
It means the Working Group considers the spec technically complete and is seeking wide review and independent implementations — a necessary step toward browser support, not a guarantee of a ship date.