chore(release): v4.13.0 by attest-team-ci · Pull Request #5288 · dequelabs/axe-core

attest-team-ci · 2026-08-05T16:06:50Z

All notable changes to this project will be documented in this file. See commit-and-tag-version for commit guidelines.

4.13.0 (2026-08-05)

Features

aria-actions: add aria-actions to allowed ARIA attributes (#5200) (029655d), closes #4584 #5199, references #5215 #5215
aria-allowed-attr: flag deprecated ARIA attributes as needs-review (#5246) (518f3cc), closes #3341
aria-prohibited-attr: allow many elements to be named and disallow label and body from being named (#5259) (d8b1ea5)
aria-roles: add sectionheader and sectionfooter roles (#5238) (c36c109), closes #4734, references #4734
aria/get-aria-value: new function to get aria values of a node (#5109) (a7d8f3e), references #5042
aria/has-attr-value: new function to check if node has aria value (#5136) (61f2624), references #5109
aria: support role=image as equivalent to role=img (#5248) (5aa8aaf), closes #4656, references #5272
checks/aria: support ARIA element internals properties (#5172) (9b7f754)
checks/label: support ARIA element internals properties (#5170) (21c5f8b)
checks/navigation: support ARIA element internals properties (#5167) (2c3a98f)
commons/aria: support ARIA element internals properties (#5171) (31f09e7)
commons/dom: support ARIA element internals properties (#5163) (f0a12cf)
commons/forms: support ARIA element internals properties (#5165) (27a4686)
commons/matches/fromPrimative: deprecate in favor of correct spelling (#5270) (31cfb2e)
commons/text: support ARIA element internals properties (#5169) (e841a33)
commons/text: support form-associated labels via element internals (#5182) (57cfe0a), closes #5045, references #5170 #5039 #5151 #5039
dom/getResolvedRefs: new function to get the resolved virtual nodes of idrefs (#5151) (489cdea), references #5109
element-internals: enable ElementInternals by default (#5284) (2740d42), closes #5277
i18n: Add Swedish locale (#5190) (dcd13f2), references #5189
matches: add inSectioningContent, hasChild, and isSummaryForDetails matches (#5262) (c47cdcd)
rules: support ARIA element internals properties (#5168) (065baf7)
standards/ariaAttrs: add caseInsensitive property for attributes (#5224) (bcd791c)

Bug Fixes

aria-allowed-role: allow roles on a non-details summary (#5242) (3bd9875), closes #3911, references #3443 #3911
aria-allowed-role: restrict figure roles with child figcaption (#5240) (178a635), closes #3443
aria-prohibited-attr: visible aria-labelledby requires review only (#5285) (fd6fa9f)
axe.d.ts: make enabled property of RuleMetadata optional (#5129) (90fce18)
color-contrast: fix various stacking context bugs (#5214) (d5e5b04), references #8 #5213
gather-internals: handle non-HTMLElement nodes (#5161) (06e84c3)
get-selector: escape control characters in attribute selectors (#5273) (4b60ac5), closes #5204 #5204
image-alt: allow whitespace alt on presentational images (#5218) (c5dd0ef), closes #5216
landmark-unique: exclude section/form with non-landmark roles from landmark match (#5085) (c5fd013), closes #4722 #5064
name the image role in role-img-alt and svg-img-alt metadata (#5279) (995a269), closes #5272, references #5248 #5248
standards: update aria-errormessage and aria-details to be idrefs (#5157) (fb94f8a)

This PR was opened by a robot 🤖 🎉

…5109) The `getAriaValue` function gets the value from the 3 different locations for aria data (attribute, property, element internals). The function will always return am object of `{ value: String, source: String }` or null. However this is a slight problem when an idref(s) property is used as they return DOM nodes or arrays of such. In order to still report what the value is as a string, the function massages the data into a string by taking the node name of the DOM node as that's probably the easiest way to report it to the user. This would result in something like `node.ariaLabelledbyElements = [div, div];` having a value of `'[div,div]'` instead of `''` if we only used the attribute value. In a separate PR we'll create two functions for resolving idref(s) values into vNodes that should be used 99% of the time instead of `getAriaValue`. `getAriaValue` for idref(s) should only be used when reporting the value to the user (such as in `aria-validate-attr-value`). Closes: #5042 --------- Co-authored-by: Chris Hutchins <[email protected]>

Migrating Karma to use Web Test Runner (WTR). Out of the box it has some problems that needed to be addressed, and some things we'll need to get use to using a new test runner. * WTR uses Playwright by default, but Playwright doesn't support Firefox Nightly. We'll use the Selenium driver in order to support that * However the Selenium driver automatically runs each test inside an iframe, which we do not want (and also breaks our tests). The Selenium driver doesn't have an option to disable this, so had to hack a way around this to ensure each test ran in the root document and no iframe * WTR runs each test file in an isolated Mocha context, so using `.only` no longer works across test files, just within the file it's used in. A bit annoying, but we can get use to this (tried to hack a way around this but it became way too complicated and broke a bunch of other stuff). `develop` still will watch files and run the changed test file for us * WTR `--manual` is used to replace `test:debug`. This didn't have a UI at first, so added the `html` style mocha reporter that we are use to. The only difference now is that the browser doesn't open automatically (have to press 'D') and that the landing page is a list of links to each test file * WTR doesn't have a preprocess step like Karma had, so we had to move it to it's own file and do the preprocessing for integration tests before we run them Additionally: * Noticed that our axe.log stubbing in various tests weren't working since we moved to ES6 modules (the code directly calls `log` and doesn't go through `axe.log`), this meant the asserts testing the messages weren't being run at all. So I fixed that by adding a `axe._setLogger` helper that would let us designate the logger stub. This allows us to both stub the logger or suppress it (so we don't have to see performance timer logs in tests, etc.) * Puppeteer was [failing a lot recently](https://github.com/dequelabs/axe-core/actions/runs/26545263689/job/78398503218) so fixed that while I was here * WTR can support both our current test loading (relying on global axe and properties) and es6 imports to the `lib` directory. I updated `performance-timer` to show this being possible. This means we should be able to remove the `_thisWillBeDeletedDoNotUse` property that was added just to get things to the test and we can import those directly in the tests that need them. However, this isn't something we can do right away as the imported file is a different context from the same file being imported in axe (since we bundle the axe files together). This means file scope/state is different so we can't import the new `setLogger` function directly in tests and use it as it doesn't set the axe.js bundled `logger` variable scope. Closes #5115

This was an accidental breaking change if anyone uses `RuleMetadata` directly. --------- Co-authored-by: Jonathan Garbee <[email protected]> Co-authored-by: Chris Hutchins <[email protected]> Co-authored-by: Wilco Fiers <[email protected]>

In preparation for #5044, this will allow us to declaratively set aria prop values on the `testutils-element` using `with-aria-*` attributes (mimicking the `with-role` attribute). It handles converting idref(s) attributes to their DOM nodes.

…ue (#5136) Companion to #5109 but replaces `vNode.hasAttr`. This resulted in finding a bug in Firefox which crashes the browser when trying to access an empty array set to an idrefs property in element internals. This is why the Firefox tests are failing (technically crashing). Filled here https://bugzilla.mozilla.org/show_bug.cgi?id=2045887.

- Replaces all uses of grunt with build scripts. - Migrate build dir to .mjs - Remove grunt from qunit test example

…odes of idrefs (#5151) A new function that is very similar to `commons.dom.idrefs` function, but understands handling ARIA idrefs properties and element internals properties and additionally returns virtual nodes rather than DOM nodes. This was the leftover work from #5109 to handle idrefs being a string (attribute) or array of nodes (property). I also update the `queryShadowFixture` function to allow both `#shadow` and `#target` ids to exist in the light DOM. I looked at all uses of `queryShadowFixture` and almost all of them use the `#shadow` in the light DOM and `#target` in the shadow DOM, though a few rely on `#target` in the light DOM (but no `#shadow`). The changes prioritize the order of find things so that `#shadow` is used first as the container, then `#target` (instead of the other way around) and the target selector is found in the shadow DOM first, then in the light DOM after (instead of the other way around). Lastly to support changing either selector I allowed the 3rd parameter to be an object that could define them (no current uses of `queryShadowFixture` pass a 3rd parameter, but I left the option to just pass the target selector as a string). --------- Co-authored-by: Chris Hutchins <[email protected]> Co-authored-by: Wilco Fiers <[email protected]>

This started because `chromedriver` wasn't the latest version in the package-lock so every time I switched between the grunt removal branch and any other branch I had to reinstall chromedriver to the latest. It then spiraled to looking at all the npm warnings and updating what made sense. * `@babel/plugin-proposal-object-rest-spread` was deprecated as it was merged into the spec and we can now use the actual package `@babel/plugin-transform-object-rest-spread` * `standard-version` was deprecated and they recommend using `commit-and-tag-version` * `glob` was prevented from updating to v11 as it removed node version <20 and we still test under node 18. But looking at the code now we only use glob when we build, which we [already restore a cache version](https://github.com/dequelabs/axe-core/blob/develop/.github/workflows/test.yml#L236-L237) of before we test our code using different node versions. so we should be able to update it now The remaining warns can't be fixed at the moment. * `[email protected]` and `[email protected]` are both used by latest `commit-and-tag-version`. [an issue exists about it](absolute-version/commit-and-tag-version#295) * `[email protected]` is used by latest `http-server`. [an issue exists about it](http-party/http-server#973) * `[email protected]` is used by `node-notifier`, which hasn't been updated in several years. we could move to https://github.com/Aetherinox/node-toasted-notifier which is a fork of it, but I wasn't sure if we wanted to or not. Alternatively we could just drop the package, it's only used 1 time in our build to notify when axe-core build is completed (a nice to have but not necessary). * `[email protected]` is used by latest `mocha`, but the next major mocha version looks like it updates to the latest glob

@chutchins25

…nals (#5164) Discovered as part of the [conversion of commons/dom](#5163). @chutchins25 had pointed out that the `null` only check would fail if the value was ever `undefined`, but since all browsers supported `null` on all ARIA prop values I didn't think it was necessary. Well turns out that when we set the internals to an object for the external api code, the values no longer return `null` when missing but `undefined`. So need to add the `undefined` check for those cases. Is `chore` as we don't need to announce this fix in the changelog as the feature hasn't be released yet

Updates the `commons/forms` directory to use the new `getAriaValue` or `hasAriaValue` functions where it makes sense. Also updated the test files to use `queryFixture` instead of appending to fixture directly and trying to find the node after. Here's a report of the full directory: * `commons/forms/is-native-textbox` - looks at `type` attribute, keep .attr Refs: #5142

This allows `queryFixture` to now support declarative shadow DOM, replacing the need for `queryShadowFixture` and `createNestedShadowDom`. I wanted the detection to be conditional so we didn't need to do the expensive calls of `setHTMLUnsafe` and querying for every shadow on every test. So the code only does the expensive operations when it detects a declarative shadow DOM. Alternatively if we don't like the regex we could just have the `options.shadow` be passed into the `queryFixture`, but that would be a bit odd when the 2nd param is the query, but would be fine for the few times we actually use the functions: `queryFixture('<div>', '#target', { shadow: true });`

Updates the `commons/dom` directory to use the new `getAriaValue` or `hasAriaValue` functions where it makes sense. Also update any uses of `node.getAttribute` or `node.hasAttribute` where it made sense as well. Here's a report of the full directory: * `commons/dom/focus-disabled` - hasAttr(disabled), disabled (not aria-disabled) is not an ARIA prop so remains hasAttr * `commons/dom/get-element-by-reference` - looks up non-aria attrs, should still use .attr, but do we need to split the logic to handle non-aria vs aria attributes differently? * `commons/dom/tabbable-elements` - looks at tabindex, should still use .attr * `commons/dom/has-lang-text` - looks at lang attr, should still use .attr * `commons/dom/idrefs` - superceded by `get-resolved-refs` so won't update uses * `Commons/dom/inserted-into-focus-order` - looks at tabindex, should still use .attr * `commons/dom/is-current-page-link` - looks at href, should still use .attr (or getAttribute in this case since it has to deal with html anchor only properties) * `commons/dom/is-focusable` - tabindex, use .attr * `commons/dom/is-in-tab-order` - tabindex, use .attr * `commons/dom/is-inert` - inert, use .hasAttr * `commons/dom/is-natively-focusable` - href, use .hasAttr * `commons/dom/is-visibile (deprecated)` - no conversion * `commons/dom/url-props-from-attribute` - needs node (`ownerSVGElement` prop), so no conversion from getAttribute * `commons/dom/visibility-methods` - only the aria-hidden use should move to getAriaValue, others are non-aria attrs Refs: #5142 Refs: #5043

Updates the `checks/aria` directory to use the new `getAriaValue`, `hasAriaValue`, and `getResolvedRefs` functions where it makes sense. Here's a report of the full directory: * `checks/aria/aria-busy` - aria-busy → getAriaValue with `{ lowercase: true }` (boolean type) * `checks/aria/aria-conditional-checkbox-attr` - aria-checked → getAriaValue with `{ lowercase: true }` (normalizeAriaChecked calls toLowerCase) * `checks/aria/aria-conditional-radio-attr` - aria-checked → getAriaValue with `{ lowercase: true }` (same reason as checkbox) * `checks/aria/aria-conditional-row-attr` - checks aria-rowindex/aria-colspan, but only via `.attrNames` presence check, no value access * `checks/aria/aria-errormessage` - aria-errormessage → getAriaValue + hasAriaValue; aria-invalid → getAriaValue + hasAriaValue; `idrefs()` → getResolvedRefs; since getResolvedRefs returns a VirtualNode, changed `idref.getAttribute('aria-live')` to `idref.attr('aria-live')`; aria-describedby → getAriaValue * `checks/aria/aria-hidden-body` - aria-hidden → getAriaValue (nmtoken type, no toLowerCase since original didn't use it) * `checks/aria/aria-level` - aria-level → getAriaValue (int type, no toLowerCase) * `checks/aria/aria-required-attr` - aria-valuetext → getAriaValue; aria-expanded → getAriaValue (in isClosedCombobox); required attr presence check → hasAriaValue (so internals-set required attrs are recognized) * `checks/aria/aria-required-children` - aria-busy → getAriaValue with `{ lowercase: true }` (boolean type, two uses) * `checks/aria/aria-valid-attr-value` - preCheck functions for aria-haspopup, aria-controls, aria-expanded, aria-selected, aria-current, aria-owns, aria-describedby, aria-labelledby → getAriaValue; the main attrNames loop and `const attrValue = virtualNode.attr(attrName)` remain as-is since validation iterates over actual HTML attributes only * `checks/aria/braille-label-equivalent` - aria-braillelabel → getAriaValue (string type) * `checks/aria/braille-roledescription-equivalent` - aria-brailleroledescription and aria-roledescription → getAriaValue (both string type); defaulted roleDesc to null so `typeof roleDesc !== 'string'` check is preserved * `checks/aria/abstractrole` - checks role attribute, not an ARIA prop * `checks/aria/aria-allowed-attr` / `aria-allowed-attr-elm` / `aria-prohibited-attr` / `aria-unsupported-attr` / `aria-valid-attr` - iterate over `attrNames`, validate ARIA attribute names (not values) * `checks/aria/aria-allowed-role` - checks role attribute, not an ARIA prop * `checks/aria/aria-required-parent` - checks role hierarchy, no ARIA attr value access * `checks/aria/aria-roledescription` - checks aria-roledescription presence via `attrNames`, no value access * `checks/aria/deprecatedrole` / `fallbackrole` / `invalidrole` / `unsupportedrole` - check role attribute, not an ARIA prop * `checks/aria/has-global-aria-attribute` - checks for presence of any global ARIA attr via `attrNames`, no value access * `checks/aria/has-widget-role` - checks role, not an ARIA prop * `checks/aria/is-element-focusable` - checks focusability, no ARIA attr value access * `checks/aria/no-implicit-explicit-label` / `valid-scrollable-semantics` - no ARIA attr value access Refs: #5142

…5167) Updates the `checks/navigation` directory to use the new `getAriaValue` function where it makes sense. Here's a report of the full directory: * `checks/navigation/heading-order` - aria-level → getAriaValue * `checks/navigation/identical-links-same-purpose` - compares accessible names, no ARIA attr access * `checks/navigation/internal-link-present` - checks href, no ARIA attr access * `checks/navigation/meta-refresh` - checks meta content attribute, not an ARIA prop * `checks/navigation/p-as-heading` - checks text styles, no ARIA attr access * `checks/navigation/region` - aria-live → getAriaValue * `checks/navigation/skip-link` - checks link destination, no ARIA attr access * `checks/navigation/unique-frame-title` - checks title attribute, not an ARIA prop Closes: #5148

Updates the `commons/text` directory to use the new `getAriaValue` and `hasAriaValue` functions where it makes sense. Here's a report of the full directory: * `commons/text/form-control-value` - aria-selected → getAriaValue; aria-valuenow → hasAriaValue + getAriaValue * `commons/text/accessible-text` / `accessible-text-virtual` - computes accessible names via commons/aria functions; no direct ARIA attr access * `commons/text/label-text` / `label-virtual` / `label` - delegates to commons/aria functions; no direct ARIA attr access * `commons/text/native-text-alternative` / `native-text-methods` / `native-element-type` - checks native HTML semantics (type, value, placeholder, etc.), not ARIA props * `commons/text/title-text` - checks title attribute, not an ARIA prop * `commons/text/visible-virtual` / `visible` / `visible-text-nodes` / `subtree-text` - text visibility utilities, no ARIA attr access * `commons/text/sanitize` / `unicode` / `has-unicode` / `remove-unicode` / `is-human-interpretable` / `is-icon-ligature` / `is-valid-autocomplete` - text processing utilities, no ARIA attr access Closes: #5141

Use `Node` instead of `HTMLElement` when checking the element internals prop value so we include all node types, such as SVGs. This is the follow up to a [similar problem in the `get-aria-value` pr](#5109 (comment)). I also added an eslint rule to prevent us from using `HTMLElements` in the future so we don't make the same mistake again.

[//]: # (dependabot-start) ⚠️ **Dependabot is rebasing this PR** ⚠️ Rebasing might not happen immediately, so don't worry if this takes some time. Note: if you make any changes to this PR yourself, they will take precedence over the rebase. --- [//]: # (dependabot-end) Bumps [chromedriver](https://github.com/giggio/node-chromedriver) from 149.0.2 to 150.0.0. <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/giggio/node-chromedriver/commit/85919db4badaeccb1a61d0abfd0741d16188dca7"><code>85919db</code></a> Bump version to 150.0.0</li> <li><a href="https://github.com/giggio/node-chromedriver/commit/7d81064131319a559cc91a694225c560997cf0a0"><code>7d81064</code></a> Bump version to 149.0.4</li> <li><a href="https://github.com/giggio/node-chromedriver/commit/14ab6c2952ea36ee3c3cf1656e45f0dedf1c3629"><code>14ab6c2</code></a> Bump version to 149.0.3</li> <li>See full diff in <a href="https://github.com/giggio/node-chromedriver/compare/149.0.2...150.0.0">compare view</a></li> </ul> </details> <br /> [![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=chromedriver&package-manager=npm_and_yarn&previous-version=149.0.2&new-version=150.0.0)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

#5178) The `context.md` examples labeled "Test a Node list" and "Test everything except these DOM nodes" used `document.querySelector(...)`, which only ever returns a single node, so they didn't actually show a NodeList. Switched both to `document.querySelectorAll(...)` and tweaked the comments so the examples demonstrate the NodeList support that already works. Also added two `Context` unit tests: one for a NodeList passed as the bare context, and one for NodeLists passed via `include`/`exclude`. (`doc/API.md` already lists NodeList as an accepted context, so it didn't need a change.) Heads up: I couldn't get the browser test runner going in my environment, so the new assertions were checked against the built `axe.js` bundle under jsdom rather than web-test-runner — prettier and eslint are clean. Worth a CI run to confirm in-browser. Closes: #3348

…nflict resolution (#5175) Audited `lib/checks/shared` for the #5044 conversion — no `getAriaValue`/`hasAriaValue` conversion applies: - `aria-label` / `aria-labelledby` checks delegate to the already-converted `commons/aria` helpers (`arialabelText` / `arialabelledbyText`), so they're internals-aware transitively. - `presentational-role` uses one global-ARIA **presence** check for role conflict resolution, which stays `hasAttr` — element internals must **not** trigger conflict resolution (no browser supports it yet; see #5162). This matches the convention already set in #5172 (`has-global-aria-attribute`) and #5171 (`get-role`). So this is a **test-only** change: it adds a test demonstrating that a global ARIA attribute supplied via element internals does **not** override a presentational role. No production code changes. Closes #5145

Updates the `checks/label` directory to use the new `getAriaValue`, `hasAriaValue`, and `getResolvedRefs` functions where it makes sense. Here's a report of the full directory: * `checks/label/help-same-as-label` - aria-describedby: replaced `node.getAttribute` + `idrefs()` with `hasAriaValue` + `getResolvedRefs`; since `getResolvedRefs` returns VirtualNodes, updated `accessibleText(thing)` to `accessibleText(thing.actualNode)` * `checks/label/multiple-label` - aria-labelledby: replaced `idrefs()` with `getResolvedRefs`; since VirtualNodes are returned, updated `.includes(domNode)` to `.some(ref => ref?.actualNode === domNode)` * `checks/label/title-only` - aria-describedby: replaced `.attr()` truthy check with `hasAriaValue` since only presence is needed * `checks/label/alt-space-value` - checks alt attribute, not an ARIA prop * `checks/label/duplicate-img-label` - compares accessible names, no direct ARIA attr access * `checks/label/explicit` - checks label[for] association, no ARIA attr access * `checks/label/hidden-explicit-label` - checks label visibility, no ARIA attr access * `checks/label/implicit` - checks implicit label wrapping, no ARIA attr access * `checks/label/label-content-name-mismatch` - computes accessible names, no direct ARIA attr access * `checks/label/no-implicit-explicit-label` - no direct ARIA attr access (in aria directory, not label) Closes: #5146 --------- Co-authored-by: Chris Hutchins <[email protected]> Co-authored-by: JC Franco <[email protected]>

Ignoring the breaking tests until we can update our code to handle them. See #5207

## Summary Adds `aria-actions` to axe-core's known ARIA attributes so it is recognized as valid, allowed, and prohibited on the roles the spec prohibits it on — and re-enables the APG `tabs-actions` example that had been disabled for lack of `aria-actions` support. Per the [spec draft](w3c/aria#1805), `aria-actions`: - **Value type:** ID reference list → `idrefs` - **Global:** yes (like `aria-describedby`) - **Empty allowed:** yes — the spec permits `aria-actions=""` (the deferred-DOM case) → `allowEmpty: true` - **Prohibited roles:** the name-prohibited roles the spec also prohibits it on (all axe `prohibitedAttrs` roles except `none`/`presentation`, which the spec still permits) - **ElementInternals reflection:** `ariaActionsElements` ## Accessibility-supported rationale Following the [Impact on ARIA](https://github.com/dequelabs/axe-core/blob/develop/doc/accessibility-supported.md#impact-on-aria) decision framework: 1. Supported by all platforms? No — shipped in WebKit and Firefox; **Chromium pending**. 2. Does its use negatively impact accessibility? **No** — unsupported browsers simply ignore the attribute (progressive enhancement), and the spec hard-guards exposure. → **allow.** > **Note for reviewers:** the ARIA spec change is still [PR #1805](w3c/aria#1805), not yet merged — this aligns to the two engines shipping ahead of spec approval. We can patch the config later in the unlikely event the spec shifts. ## Changes **Attribute recognition** — `lib/standards/aria-attrs.js`: add the `aria-actions` entry (`idrefs`, global, `allowEmpty`). **Prohibited-on-role** — `lib/standards/aria-roles.js`: add `aria-actions` to `prohibitedAttrs` for `caption`, `code`, `deletion`, `emphasis`, `insertion`, `mark`, `paragraph`, `strong`, `subscript`, `superscript`, `suggestion`. Per [w3c/aria#1805](w3c/aria#1805) these roles prohibit it; `none`/`presentation` do not, so they are left unchanged. **APG test re-enable (Closes #4584)** — bump `aria-practices` to latest `main` (the `tabs-actions` page did not exist at the previously pinned commit) and remove it from `skippedPages`. axe recognizes the attribute but not the authoring *pattern*, so `aria-required-children` (tabs-actions) and `nested-interactive` (listbox-actions) are disabled per-page pending #5215. **Review feedback** — update the stale `wai-aria-1.1` `Source:` comment to the unversioned WAI-ARIA URL; add an `aria-actions=""` pass case exercising `allowEmpty`. ## Testing - `get-global-aria-attrs`, `aria-prohibited-attr` (check + virtual-rule), `aria-valid-attr`, `aria-allowed-attr`, `aria-valid-attr-value` unit + integration tests ✓ - Full APG suite green (76 passing) ✓ - `npm run build` clean; no auto-generated committed files change ## Follow-ups - #5215 — teach `aria-required-children` / `nested-interactive` about the `aria-actions` pattern, then remove the per-page disables in `apg.spec.js` Closes #5199 Closes #4584

The tests only set up the virtual tree from the `fixture` down. This causes problems in our tests when code walks up the DOM tree (not the virtual tree) and tries to get virtual nodes from the walk. This causes tests to fail when it wouldn't fail in an actual run (as doing `axe.run` setups the virtual tree for the entire page). This updates the testutils functions to set up the virtual tree using the entire DOM to parity an actual run.

## What changed - **Lockfile:** `package-lock.json` removed, `pnpm-lock.yaml` seeded via `pnpm import` so resolutions carry over. `packageManager` in `package.json` pins pnpm 11; pnpm honors that field itself, so contributors only need pnpm installed, not a specific version (and never Corepack, which is gone in Node 25+). - **Patching:** `patch-package` is dropped in favor of pnpm's native `patchedDependencies`. The `colorjs.io` patch moves to pnpm's naming, and `prepare` no longer has to run a patch step — which also removes the `npm run prepare && npm run build` pairing from every workflow. - **Build scripts:** `pnpm-workspace.yaml` declares `allowBuilds` explicitly. `esbuild` and `chromedriver` need their postinstall; the `core-js` family and `es5-ext` do not. The two git-hosted W3C test corpora are keyed by resolved tarball spec, so bumping either pin means updating that key too. The nightly jobs that install those corpora from a floating branch can't know the resolved commit ahead of time, so they opt into all builds for that install. - **Strict `node_modules`:** `core-js-pure` was being used through npm's hoisting and is now a direct dependency. - **CI:** every workflow gains `pnpm/action-setup` ahead of `setup-node` (needed for `cache: pnpm` to resolve the store path) and uses `pnpm ci`. - **Deploy pipeline:** `pnpm publish` needs `--no-git-checks` because the version bump is uncommitted and the branch isn't `master`. `pnpm version` has no `--ignore-scripts`, so the bump writes the manifest field directly. Package validation no longer touches global package-manager state: `validate-package.mjs` symlinks the repo into its own `node_modules` instead of `npm link`, and `validate-npm-deploy.sh` installs into a throwaway project instead of globally. - **Docs:** setup instructions and command examples across `CONTRIBUTING.md`, `doc/`, and the example projects now use pnpm. Closes: #5111 --------- Co-authored-by: Copilot Autofix powered by AI <[email protected]>

Adds the new ARIA 1.3 `sectionheader` and `sectionfooter` roles to axe-core's standards data. ## What & why Per [w3c/aria#1931](w3c/aria#1931) (merged into the ARIA spec `main`), `sectionheader` and `sectionfooter` are new **concrete structural roles** with superclass `section`. axe-core did not recognize them, so `role="sectionheader"` / `role="sectionfooter"` were flagged as invalid roles. Definitions were grounded directly against the spec source (`w3c/aria` `main`): - `roleInfo.js` — `parentRoles: ["section"]`, no required / prohibited / local (non-global) properties. - `index.html` characteristics table — **Is Abstract:** no (concrete), **Name From:** author (so no `nameFromContent`), **Accessible Name Required:** no. They are modeled on the existing `blockquote` precedent (`type: 'structure', superclassRole: ['section']`). ## Note on scope — bundling `sectionfooter` The issue (#4734) names only `sectionheader`, but the spec introduced `sectionheader` and `sectionfooter` together and there is no separate `sectionfooter` issue. They are bundled here as one cohesive "ARIA 1.3 section header/footer roles" change. ## Out of scope / follow-up The updated HTML-AAM implicit-role mapping (`<header>` / `<footer>` scoped inside sectioning content → implicit `sectionheader` / `sectionfooter`) is **not** included here — it has a much larger blast radius (landmark/region computations, `aria-allowed-role`) and will be tracked as a separate issue. ## Tests - `aria-roles` integration HTML/JSON — pass cases for both roles. - `aria-roles` virtual-rule — pass cases for both roles. - Verified `abstractrole` / `fallbackrole` / `unsupportedrole` / `aria-allowed-role` check suites still pass. Closes #4734

@WilcoFiers

…iew (#5246) Flags the deprecated ARIA attributes `aria-grabbed` and `aria-dropeffect` as "needs review". ## What & why WAI-ARIA 1.1 deprecated `aria-grabbed` and `aria-dropeffect` globally, but axe had no signal for deprecated ARIA *attributes* (it already handles deprecated *roles* via `aria-deprecated-role`). Following the approach in the issue thread ([@WilcoFiers](#3341)): add a new **`aria-deprecated-attr` check to the existing `aria-allowed-attr` rule** (rather than a standalone rule), which **incompletes** an element using deprecated ARIA, or lets the rule **fail** when the element also uses an unsupported/unallowed attribute. ## Implementation - `deprecated: true` on `aria-grabbed` / `aria-dropeffect` in `lib/standards/aria-attrs.js`. - New data-driven `aria-deprecated-attr` check: returns **incomplete** when any attribute with `deprecated: true` is present, pass otherwise. - Added to the `aria-allowed-attr` rule's `all` array. Because a failing sibling check (`aria-allowed-attr` / `aria-unsupported-attr`) outranks an incomplete, an element with a deprecated attribute is: - **needs review** when that's its only ARIA issue, or - a **violation** when it also has an unsupported/unallowed attribute. ## Behavior change Any element using `aria-grabbed` or `aria-dropeffect` now reports under `aria-allowed-attr` (needs-review, or a violation when combined with an unsupported attribute). The `passes.html` integration fixture used these two as "global attribute" filler on 68 pass blocks; they've been removed from those blocks (each still tests global-attribute allowance via its other global attributes), with dedicated incomplete/failure coverage added. ## Tests - New `aria-deprecated-attr` check unit — incomplete (single/multiple), data-driven via `axe.configure`, and an open **Shadow DOM** case. - `aria-allowed-attr` virtual-rule — incomplete for a deprecated attr; violation when combined with an unallowed attr. - `aria-allowed-attr` integration — `incomplete.html` (deprecated-only, singular + plural) and `failures.html` (#fail12: deprecated + unallowed → violation); 68 pass blocks updated. ## Follow-up Per the issue discussion, a separate ticket will track a future standards mechanism to return "needs review" for not-recommended-but-valid roles/attributes generally. Closes #3341 --------- Co-authored-by: Steven Lambert <[email protected]>

Just adds the `aria-allowed-role` integration cases for the `<button>` element (`separator`, `slider`, `treeitem`; `gridcell` was already covered), which is all #4142 needs on top of #4398. Closes #4142 --------- Co-authored-by: Steven Lambert <[email protected]>

…elling (#5270) Corrects the spelling of `fromPrimative` to `fromPrimitive` and deprecates the former function.

Adds support for `role="image"` as a valid role equivalent to `role="img"` (ARIA 1.3, [w3c/aria#1370](w3c/aria#1370)). ## What & why ARIA 1.3 adds `image` as an alias of `img` with an identical mapping; axe previously treated `role="image"` as an invalid role. Per the review discussion, this does **not** use a synonym-normalization mechanism (which would force every reporting path to remember the role the author used vs. the one our code resolved it to). Instead, `image` is a first-class role that shares `img`'s definition and is allowed wherever `img` is: - `image` is added to `lib/standards/aria-roles.js`, spread from a shared `imgRole` object so it stays in sync with `img`. - `image` is added to every `html-elms` `allowedRoles` list that includes `img` (`embed`, `iframe`, `object`). `svg` needs no change — it is `allowedRoles: true`, so it already accepts any role. - The `role-img-alt` and `svg-img-alt` selectors match both roles via `:is([role='img'], [role='image'])`. Without the `svg-img-alt` change, `<svg role="image">` matched neither rule — `svg-img-alt`'s selector omitted it and `role-img-alt` is gated by `html-namespace-matches` — so axe accepted the role and then never checked for an accessible name. - `image` is added to the `aria-roledescription` check's `supportedRoles`, so `role="image"` passes where `role="img"` does. Because there is no synonym resolution, an unallowed `role="image"` reports **`image`** (the role the author used), not `img`. ## Tests - `is-valid-role` / `aria-roles` integration — `image` is a valid role. - `get-element-unallowed-roles` — `image` allowed on `svg`/`embed`/`object`/`iframe`; reported as authored when unallowed (e.g. on `hr`). - `role-img-alt` integration + virtual-rules — matches `role="image"`. - `svg-img-alt` integration + virtual-rules — matches `role="image"`. - `aria-roledescription` — `role="image"` passes against the check's default `supportedRoles`. - ACT specs `7d6734` and `23a2a8` still pass with the broadened selectors. ## Not in scope `role-img-alt` and `svg-img-alt` metadata still name only `img` in their `description`/`help` strings. Updating them regenerates `locales/_template.json`, invalidates those translations, and needs a matching axe-rule-help change — tracked in #5272. Closes #4656 --------- Co-authored-by: Steven Lambert <[email protected]>

…ails matches (#5262) This should allow us to handle the variant matching in `htmlElms` needed for header, footer, [figure](#3443), and [summary](#3911). ```js { header: { variant: { sectioned: { matches: { inSectioningContent: true } } } }, figure: { variant: { figcaption: { matches: { hasChild: 'figcaption' } } } }, summary: { variant: { details: { matches: { isSummaryForDetails: true } } } } } ``` --------- Co-authored-by: Chris Hutchins <[email protected]>

@type

) Follow-up to #5248. Since that change, `role-img-alt` and `svg-img-alt` match both `role="img"` and `role="image"` (via `:is([role='img'], [role='image'])`), but their metadata still named only `img` — so an author who wrote `<div role="image">` got a message referencing a role they didn't write. ## Changes - **`role-img-alt`** — description/help now name `[role="img"]` **and** `[role="image"]`. - **`svg-img-alt`** — description/help now include the `image` role alongside `img`/`graphics-document`/`graphics-symbol`. - Regenerated `locales/_template.json` and `doc/rule-descriptions.md` (via `pnpm run build`). ## Notes - Editing these four strings **invalidates the existing translations** for those keys until they're retranslated — this was deliberately deferred from #5248 and is expected. Only `locales/_template.json` is regenerated here; the translated `locales/*.json` files are left for the translation workflow. - A **matching `axe-rule-help` update** (the `role-img-alt`/`svg-img-alt` help pages) is a follow-up, tracked separately. Closes #5272

@WilcoFiers

Models `presentation` as a synonym of `none` and removes the hardcoded `['none', 'presentation']` membership checks, per [@WilcoFiers on #4656](#4656). > **Stacked PR** — targets `chut/4656-role-image-synonym` (#4656), which introduced the `synonym` mechanism this builds on. GitHub will auto-retarget to `develop` once #4656 merges. ## What & why Uses the `synonym` mechanism from #4656: - `presentation` role gets `synonym: 'none'`, so `getExplicitRole`/`getRole` resolve it to the canonical `none`. - The **implicit** presentation role (empty-alt `<img>`) is also normalized to `none` at the data level (`implicit-html-roles.js`), so `getRole` never returns `'presentation'` from *either* the explicit or implicit path. With role resolution always yielding `none`, the scattered `['none', 'presentation'].includes(role)` checks that read from `getRole`/`getExplicitRole` collapse to a single `role === 'none'` — 18 sites simplified. ## Intentionally left with both terms - `fallbackrole-evaluate.js` — reads **raw** `role` attribute tokens (`tokenList`), so it needs the literal `presentation` and `none` tokens. - `presentation-role-conflict.json` (CSS selector) and `html-elms.js` `allowedRoles` arrays — raw/selector paths. - `lookup-table.js` `evaluateRoleForElement` — has no call sites, so its input couldn't be verified as normalized. ## Behavior note `getRole`/`getExplicitRole` now return `'none'` where they previously could return `'presentation'` (they're synonyms — `none` is the canonical term). **End-to-end rule results are unchanged** (all integration + virtual-rule suites pass without expectation changes); only internal `commons` role-resolution output and the corresponding unit-test expectations changed. ## Tests - `implicit-role`, `get-role` (13 inheritance cases), `presentational-role`, `aria-allowed-role` — result expectations updated `presentation`→`none`. - Full `commons` / `checks` / integration / virtual-rule suites green; no generated-file drift. Closes #5249 Co-authored-by: Steven Lambert <[email protected]>

…5240) Restricts the roles allowed on a `<figure>` element when it has a child `<figcaption>`, per the ARIA in HTML update. ## What & why Per [ARIA in HTML](https://www.w3.org/TR/html-aria/) (`#el-figure`, [w3c/html-aria#415](w3c/html-aria#415)): - A `figure` **with** a valid `figcaption` descendant allows **no role other than `figure`**, plus the DPub role **`doc-example`**. - A `figure` **without** a `figcaption` allows **any role** (though `figure` itself is NOT RECOMMENDED) — unchanged. axe previously modeled `figure` with a flat `allowedRoles: true` and an inline comment admitting it couldn't match the figcaption case. This replaces that with a `variant` using a `condition` matcher. ## Implementation notes - The implicit `figure` role still passes via the existing `allowImplicit` short-circuit, so the with-figcaption branch only needs `allowedRoles: ['doc-example']`. - The matcher checks **direct children** (`vNode.children?.some(...)`), not a descendant walk: HTML's content model only permits `figcaption` as the first/last child of `figure`, and a direct-child check avoids a nested-`<figure>` false match (an inner figure's figcaption wrongly restricting the outer figure). ## Behavior change A `<figure>` with a `<figcaption>` and an explicit role other than `figure`/`doc-example` (including `role="none"`/`role="presentation"`) now flags on `aria-allowed-role` (minor impact). This is spec-correct but will surface new findings for existing users. ## Tests - `get-element-spec` unit — variant resolution with/without figcaption. - `is-aria-role-allowed-on-element` and `aria-allowed-role` check units — incl. an open **Shadow DOM** case. - `aria-allowed-role` virtual-rule — figcaption-child cases (built with `SerialVirtualNode`) plus the no-figcaption default. - `aria-allowed-role` integration HTML/JSON — pass (`doc-example`, implicit `figure`) and violation (`group`) cases; existing no-figcaption pass retained as a regression anchor. Closes #3443 --------- Co-authored-by: Steven Lambert <[email protected]>

Updates the roles allowed on a `<summary>` element based on whether it is its parent `<details>` element's disclosure trigger, per the ARIA in HTML update. ## What & why Per [ARIA in HTML](https://www.w3.org/TR/html-aria/) (`#el-summary`, [w3c/html-aria#435](w3c/html-aria#435)): - A `summary` that **is** the "summary for its parent `details`" (the first `summary` child of a `details`) allows **no explicit role** — browsers expose it as the disclosure trigger. - A `summary` that is **not** the details summary (standalone, or a 2nd+ `summary`) is exposed as generic and allows **any role**. axe previously modeled `summary` with an unconditional `allowedRoles: false`. This converts it to a `variant` using a `condition` matcher (the same pattern introduced for `figure` in #3443). ## Scope — role side only Issue #3911 covers both the allowed **roles** and the allowed **`aria-*` attributes** for `summary`. This PR implements the **role** side. The attribute side (the spec disallows `aria-expanded`/`aria-pressed` on a details-summary) is intentionally deferred — it requires an element-level disallowed-attribute mechanism axe does not have today, and is tracked in **#5241**. ## Behavior change A standalone / non-details `<summary>` now permits **any** role, where previously only the implicit `button` role was allowed. This is a spec-correct loosening; a `<details>`-summary's role handling is unchanged in effect (still restricted to its implicit `button` role). ## Tests - `get-element-spec` unit — variant resolution for the three cases (details summary, non-first summary, standalone). - `aria-allowed-role` check unit — incl. an open **Shadow DOM** case. - `aria-allowed-role` virtual-rule — details/summary structures built with `SerialVirtualNode`, incl. the no-parent default. - `aria-allowed-role` integration HTML/JSON — first-summary fail, 2nd-summary pass, standalone pass, implicit-button pass. Closes #3911 --------- Co-authored-by: Steven Lambert <[email protected]>

@straker

…5273) Fixes #5204. When an element's attribute value contains a C0 control character (observed: form feed `U+000C`), `generateSelector` emitted it raw into an attribute selector. In CSS, form feed is a string-terminating newline, so `img[alt=" \f¼"]` is **invalid**, `Element.matches` throws inside `getNthChildString`, and the **entire `axe.run()` fails** — one bad attribute value on a page kills the whole audit. ## Fix `escapeAttribute` (in `lib/core/utils/get-selector.js`) previously escaped only `\`, `"`, and CR/LF newlines — missing form feed and every other control character. It now escapes **all C0 control characters (`U+0000–U+001F`) and DEL (`U+007F`)** as CSS numeric escapes (`\<hex> `), which subsumes the existing newline handling (`U+000A` → `\a `, `U+000C` → `\c `). This matches the issue's minimal proof that `CSS.escape('\f')` produces a valid selector. ## Compatibility No behavior change for existing cases: newline (`U+000A`) still escapes to `\a `. CR and CRLF now escape to `\d `/`\d \a ` (previously both collapsed to `\a `) — more correct round-tripping, and not covered by any existing test. All existing `get-selector` escape tests still pass. ## Test `test/core/utils/get-selector.js` — an attribute value containing form feed, vertical tab, and `U+001F` now produces a valid selector that both matches the expected escaped string and passes `matchesSelector` (which threw on the pre-fix code). Confirmed by @straker on the issue. Closes #5204

Removes the `axe._enableElementInternals` feature flag, graduating ElementInternals support to on-by-default. Closes #5277. ## Changes - **`lib/core/base/virtual-node/virtual-node.js`** — the `elementInternals` getter no longer gates on the flag, so ElementInternals is always computed. This also un-gates the `externalAPIs` `getElementInternals` path, which relied on this getter. - **Tests** — removed the flag setup and flag-specific tests: the global toggle in `testutils.js`, the `afterEach` hooks that reset it, and the "feature flag on/off" and "requires the feature flag" tests. Existing tests (`caches`/`sets`/`gets element internals`, the external-apis "correctly sets…" test) continue to cover the behavior. - **Docs** — removed the "behind a feature flag" instructions from `doc/element-internals.md` and `doc/external-apis.md`. ## Notes Per the ElementInternals epic, the commons ElementInternals surface is unreleased, so removing the flag is not a breaking change — it's the feature landing on by default. Verified: no `_enableElementInternals` references remain; `virtual-node` + `native-text-alternative` unit tests pass; the `external-apis` full integration test passes (3/3) with the flag gone.

Adds a regression test for #4335, where `axe.run` threw **`TypeError: Cannot read properties of undefined (reading 'props')`** when a `<section>`'s `aria-labelledby` referenced a `<slot>` in the same shadow root. The slot is not tracked in axe's virtual tree, so accessible-name computation dereferenced an undefined virtual node. ## Already fixed — this is a regression test The underlying error is **already resolved on `develop`** by the move to `getAccessibleRefs` for accessible-name idref lookups. Per review guidance (Steve / Wilco), the goal is only to **guarantee the error stays fixed — not to add `<slot>` support**. So this PR adds test coverage only; there are no `lib/` changes. ## The test `test/integration/full/aria-labelledby-slot/` — a full integration test that builds Steve's exact repro (a shadow root with `<section aria-labelledby="foo">` + `<slot id="foo">`), runs `axe.run`, and asserts: 1. it does not throw, 2. no result carries the `Cannot read properties` error, and 3. the shadow DOM content is actually evaluated (guards against a silent no-op). ### Why all rules instead of just `aria-allowed-role` The original stack trace ran through `aria-allowed-role` → `getElementUnallowedRoles`. On current `develop`, `aria-allowed-role` is **inapplicable** to a role-less `<section>`, so a rule-scoped test there would be a no-op. Per Steve's note that axe-core 4.11.1 produced errored incomplete results on `axe.run` for this page, the test runs the full rule set — which I confirmed exercises the section (5 rules) and would have failed pre-fix. Closes #4335

…low label and body from being named (#5259) After looking over the HTML in ARIA spec, I realized that we could better handle how we determine when an attribute is prohibited. Basically if the element doesn't have an explicit role, then we use the `htmlElm` spec to determine prohibited attrs and naming, otherwise we use the `ariaRoles` spec to determine that. This should allow us to eliminate the `elementsAllowedAriaLabel` option that was [introduced to fix which elements allowed naming](#2935) and then modified when we [added Chromium roles](#2948) to fix conflict name resolution. However the option still has the `applet` element which isn't in our html spec so I'm leaving it for now. Elements which allow naming now include: `section`, `blockquote`, `address`, `hgroup`, `ruby`. This also adds enforcement for elements that are not allowed any aria-* attribute (which has never been used in our code) by changing the `noAriaAttrs` spec property to an empty `allowedAriaAttrs` so that they now throw in the rule `aria-allowed-attr`. Closes: #5185 Closes: #3410

#5157) This is in the current [WAI-ARIA 1.3 draft](https://www.w3.org/TR/wai-aria-1.3/#aria-errormessage) and both attributes were changed to `idrefs` types. Since the AOM property is an idrefs type (returns an array) this allows us to be in sync with that for the Element Internals work. The `aria-errormessage` check [already accounts the attribute being an idrefs value](#4973) and will incomplete if the value has more than one id, so no changes should be needed with this pr.

Tested in latest Firefox (153.0) and this looks like it doesn't crash the browser anymore. The other non-crash issues still exist (logging the warning, `null` for empty `ariaLabelledByElements `), but we should be able to reenable the test now. Closes: #5139

* Add Swedish locale translation Closes: #5189 --------- Co-authored-by: Wilco Fiers <[email protected]>

…om landmark match (#5085) Closes #4722, #5064 Updated `landmark-unique-matches` to change the matching logic for `section` / `form` elements as follows: before | | No `aria-label` | Has `aria-label` | | ----------------------- | :-------------: | :--------------: | | No explicit `role` | ❌ | ✅ | | Explicit landmark role | ❌ | ✅ | | Non-landmark role | ❌ | ✅ ← bug | after | | No `aria-label` | Has `aria-label` | | ----------------------- | :-------------: | :--------------: | | No explicit `role` | ❌ | ✅ | | Explicit landmark role | ✅ | ✅ | | Non-landmark role | ❌ | ❌ | ~~Unrelated to this issue, but I think `section` / `form` with an explicit landmark role and no accessible name might also need to match, opened a separate issue for it: #5064~~ --------- Co-authored-by: Wilco Fiers <[email protected]>

### Summary npm now [scans published packages before they go live](https://github.blog/changelog/2026-07-28-npm-publish-time-malware-scanning-and-dual-use-metadata/), adding a delay of up to 15+ minutes between calling `publish` and the package becoming available. Our `wait-for-npm-ready.sh` retry loop was tuned for near-instant availability (10s × 30 = ~5 min), so it can now time out before the package appears. This raises the retry interval to **120s** and caps attempts at **12** (~22 min worst case). ### Notes - The two callers in `deploy.yml` (`validate-next-deploy`, `validate-deploy`) rely on the 360-min default job timeout, so no `timeout-minutes` changes were needed. Closes #5266

…ly (#5285) If the only prohibited attribute is aria-labelledby, it doesn't reference hidden elements, mark the element as needs review. Ignore aria-label as a prohibited attribute if this is the case, as the acc name fallback would have skipped it anyway. Closes: #5180, closes #4118

#5224) Add the `caseInsensitive` property to the aria attrs standard. This is used to automatically lowercase the value for `commons.aria.getAriaValue` instead of having to manually pass `{ lowercase: true }` every time you wanted to access one of the attributes. This updates `aria-expanded`, `aria-hidden`, `aria-haspopup`, `aria-selected`, `aria-invalid`, `aria-disabled`, and `ara-live` to be case insensitive (which we have tested in prior prs). Additionally, as a `chore` style change this also updates `getAriaValue` to not return `null` anymore but instead `{ value: null, source: null }` so that we don't have to conditionally access the `value` property of the return.

…refs (#5287) ### Summary Adds tests codifying how axe-core handles idref references that point outside its virtual tree — the two scenarios in #5221: 1. **Closed shadow DOM** — a custom element self-labels via `ElementInternals.ariaLabelledByElements` with a node inside its own closed shadow root. Closed roots aren't flattened into the virtual tree, so the reference is unreachable. 2. **Out-of-tree node** — `ariaLabelledByElements` points at a node appended after `axe.setup()`, so it never enters the tree. Both codify the current behavior: `getResolvedRefs` maps the unreachable node to `null`, the accessible-name function drops it, and `arialabelledbyText` returns `""` **without throwing**. ### Notes - Tests-only; no runtime behavior change. - The closed-shadow case is built with manual DOM (`attachShadow({ mode: "closed" })`) since `queryShadowFixture` is open-mode only. Closes #5221

WilcoFiers

Release audit

*) Missing the security review check somehow.

straker and others added 30 commits June 1, 2026 15:31

chore: merge master into develop (#5126)

46a0ead

chore: merge master into develop (#5153)

d76505f

chore: replace grunt with custom build scripts (#5104)

6c41927

- Replaces all uses of grunt with build scripts. - Migrate build dir to .mjs - Remove grunt from qunit test example

test: ignore latest changes to act-test 2ee8b8 (#5208)

734d4a4

Ignoring the breaking tests until we can update our code to handle them. See #5207

Garbee and others added 26 commits July 29, 2026 08:30

feat(commons/matches/fromPrimative): deprecate in favor of correct sp…

31cfb2e

…elling (#5270) Corrects the spelling of `fromPrimative` to `fromPrimitive` and deprecates the former function.

feat(i18n): Add Swedish locale (#5190)

dcd13f2

* Add Swedish locale translation Closes: #5189 --------- Co-authored-by: Wilco Fiers <[email protected]>

chore(release): 4.13.0

a1c9ebb

attest-team-ci requested a review from a team as a code owner August 5, 2026 16:06

WilcoFiers approved these changes Aug 5, 2026

View reviewed changes

WilcoFiers merged commit 1cc54b9 into master Aug 5, 2026
22 checks passed

WilcoFiers deleted the release-2026-08-05 branch August 5, 2026 16:42

Navigation Menu

Uh oh!

chore(release): v4.13.0 - #5288

chore(release): v4.13.0#5288
WilcoFiers merged 72 commits into
masterfrom
release-2026-08-05

attest-team-ci commented Aug 5, 2026

Uh oh!

WilcoFiers left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

Uh oh!

Conversation

attest-team-ci commented Aug 5, 2026

4.13.0 (2026-08-05)

Features

Bug Fixes

Uh oh!

WilcoFiers left a comment

Choose a reason for hiding this comment

Release audit

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants