Make settings feedback, Asset Manager, and cache observability accessible

Problem

Several active admin interactions expose visual state without an equivalent accessible contract. The React settings footer renders asynchronous save results in an ordinary div, and the frontend Assets Manager declares a modal dialog without implementing modal focus behavior. Cache observability tables also omit explicit row/column header scope. These gaps make settings feedback and the asset-scanning workflow unreliable for keyboard and screen-reader users.

Evidence

• assets/src/js/admin/Footer.jsx:25-38 shows success/error text and a spinner without a live region, alert semantics, or a busy relationship to the edited settings surface.
• src/Modules/Assets/AssetsManager.php:233-252 uses role="dialog" and aria-modal="true", but does not establish initial focus, trap focus, support Escape, or restore focus to the invoking control.
• src/Modules/Cache/PageCache.php:513-522 and 557-561 output data-table headers without explicit scope attributes or table captions.
• There is no accessibility-oriented browser coverage for save announcements, dialog focus, or table semantics.

Scope

Bring the active settings save feedback, Assets Manager overlay, and cache observability tables to baseline WordPress admin accessibility expectations.

Implementation plan

1. Add a persistent, non-duplicated save-status region: polite live announcement for success/progress and alert semantics for failures; expose a meaningful busy state while saving.
2. Ensure the save button and spinner have accessible names that communicate the operation without relying only on color or motion.
3. Replace the current Assets Manager dialog behavior with a real accessible modal pattern: initial focus, keyboard focus containment, Escape/close behavior, and restoration to the opening admin-bar control. If the surface is not actually modal, remove modal semantics and adopt the correct non-modal pattern.
4. Add captions or accessible labels and scope="row"/scope="col" to cache observability tables.
5. Add focused Playwright/axe or equivalent keyboard and screen-reader-contract tests covering all three surfaces.

Acceptance criteria

• A screen reader announces save progress, success, and failure exactly once.
• Keyboard users can enter, operate, close, and leave the Assets Manager without focus escaping or getting lost.
• The dialog's ARIA role accurately matches its behavior.
• Cache metric and map tables expose unambiguous header relationships.
• Existing admin actions remain usable with mouse and keyboard.

Validation

• npm run lint:js and npm run lint:css
• npm run build
• Isolated WordPress browser proof with keyboard-only navigation.
• Automated accessibility scan plus manual screen-reader spot check on the settings save and Assets Manager flows.

Non-goals and risk

• Do not redesign the settings information architecture or change Asset Manager optimization rules.
• Preserve the current administrator-only access model for the Asset Manager.

Start with assets/src/js/admin/Footer.jsx:25-38, src/Modules/Assets/AssetsManager.php:233-252, and src/Modules/Cache/PageCache.php:513-522 and 557-561. Review the existing admin interactions before adding focused browser accessibility coverage for save feedback, dialog focus behavior, and table semantics. Done means the three surfaces meet the acceptance criteria and npm run lint:js, npm run lint:css, npm run build, and isolated keyboard/browser checks pass.