Add table caption validation check for core/table block

[huzaifaalmesbah]

What?

Closes #28

This PR adds a new WCAG-oriented validation check check_table_caption for the core/table block in the Core block accessibility rules module.

Why?

Under WCAG 1.3.1 (Info and Relationships), Technique H39 recommends that data tables provide an associated <caption> to help screen reader users identify the topic or purpose of the table without reading through each cell. Currently, only header rows are validated (check_table_headers).

Because H39 is a sufficient technique rather than a WCAG requirement, the check is registered with a default level of none (disabled). Site owners who want to encourage captions can enable it as a warning or error in Validation settings.

How?

• PHP Registration: Registered check_table_caption under core/table in Core_Block_Validation_Rules.php at level: none.
• JS/TS Validation: Updated src/editor/core-block-rules/table.ts to inspect attributes.caption, stripping HTML, whitespace and non-breaking spaces to verify meaningful content exists.
• Settings Integration: Automatically surfaced in the Validation admin table, disabled by default; site administrators can set the severity to warning or error.

Testing Instructions

1. Go to the Validation admin page, find Table caption recommended, and set its severity to Warning. (By default it is Disabled, so no warning appears.)
2. Open the block editor (Posts → Add New Post).
3. Insert a Table block (/table) with headers and some data cells.
4. Leave the table caption empty.
5. Open the Validation sidebar panel.
   • Expected: The table has an amber/yellow warning outline (validation-api-block-warning), and the sidebar shows:
     Consider adding a caption to this table. (core/table)
6. Type a caption into the table's "Write caption..." field.
   • Expected: The yellow outline immediately disappears and the warning in the sidebar is cleared.

Testing Instructions for Keyboard

With the check set to Warning as in step 1 above:

1. Navigate to the editor using the keyboard (Tab).
2. Insert a Table block via the keyboard slash inserter (/table).
3. Press Tab to navigate through cells without filling the caption.
4. Use Tab / Shift+Tab to reach the top bar and activate the Validation sidebar button.
5. Verify the warning is announced and reachable via keyboard.
6. Navigate back to the table, reach the caption area, type text, and verify the issue resolves.

Screenshots or screencast

Screenshots show the check with its severity set to Warning.

Before (No caption)	After (Caption added)

Use of AI Tools

AI assistance: Yes
Tool(s): Google Antigravity
Used for: Implementation skeleton, TypeScript/PHP integration, local testing in browser, and PR formatting. Reviewed and verified locally.
Tool(s): Claude Code
Used for: Rebasing on main and applying review feedback (default level none, non-breaking space handling). Reviewed before pushing.

[troychaplin]

Thanks for the contribution @huzaifaalmesbah, the implementation looks solid and this is almost ready to merge.

Before we do, I think we need alignment with the rest of the Accessibility Team on our approach to default severity for non-mandatory accessibility concerns. Table captions aren't required by WCAG (H39 is a sufficient technique for 1.3.1, not a mandatory one), so my take is this should default to none rather than warning, leaving the severity in the site owner's hands to configure as they see fit. I'd want to apply the same default (none unless there's a clear WCAG violation) to any future validation checks we add for non-mandatory concerns, reserving error/warning defaults for cases where there's an actual conformance failure.

Let's get that settled as a team before merging so we're consistent going forward.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: huzaifaalmesbah <[email protected]>
Co-authored-by: troychaplin <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[huzaifaalmesbah]

Thanks @troychaplin! That makes sense — since H39 is a sufficient technique rather than a requirement, I've changed the default level to none in a257d82, so it's off unless a site owner enables it in Validation settings. I also made captions containing only   count as empty, and rebased on main to resolve the conflict with the lint changes.

Happy to adjust if the team settles on a different default policy.