The latest spec PR(w3c/aria#1805) requires
has-actions to be exposed on every host whose role supports aria-actions
and that sets the attribute, regardless of whether any referenced target
survives IsValidAriaActionsTarget.

Widen the kHasActions gate in AXObject::SerializeUnignoredAttributes so
the attribute is added when aria-actions is set on a supporting role, in
addition to the existing path that triggers when kActionsIds is
non-empty (which covers implicit-actions on menuitem-like roles). The
previous gate keyed only on a non-empty kActionsIds, leaving assistive
tech unable to distinguish "no aria-actions" from "aria-actions present
but all targets filtered."

Bug: 408040289, 514751946
Change-Id: Id621008fefd84a8b999565049735ff2c6f47a6a4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7895414
Reviewed-by: Benjamin Beaudry <benjamin.beaudry@microsoft.com>
Commit-Queue: Jacques Newman <janewman@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1641975}

In creating the [aria-actions PR](w3c/aria#1805), it came up that the list of supported value types for a custom UIA property didn't include arrays, even though arrays are supported. This PR updates the docs to explicitly include the respective array types for each of the supported types.

The aria-actions spec PR (w3c/aria#1805) §6.8
includes an Author SHOULD that targets be visible when the host has DOM
focus. Today we gave this behavior is chromium due to
CanSetFocusAttribute() returning false for the hidden subtree, and
IsValidAriaActionsTarget() already rejects targets that are not
keyboard-focusable.

This change codifies the existing behavior to protect against
regression, with no behavioral change.

Bug: 408040289
Change-Id: I12e4bc2bd8f2b1cac9f96dbcac1979ea085c3604
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7852706
Commit-Queue: Kurt Catti-Schmidt <kschmi@microsoft.com>
Reviewed-by: Kurt Catti-Schmidt <kschmi@microsoft.com>
Auto-Submit: Jacques Newman <janewman@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1651177}

…PG test

Prohibit aria-actions on the 11 name-prohibited roles per w3c/aria#1805, add
an allowEmpty pass case, and bump aria-practices to re-enable the tabs-actions
APG example. aria-required-children / nested-interactive don't yet support the
aria-actions pattern, so they're disabled per-page pending #5215.

Closes #4584

## 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