Fix: Add accessible labels to ToggleControl in Connector Approvals matrix

[ishitaj34]

What?

Closes #634

Adds descriptive accessible labels to the approval matrix toggle controls in ApprovalMatrixCard.tsx.

Why?

The toggle controls were rendered with label="", resulting in checkboxes with no accessible name. Screen reader users could not determine which caller and connector each toggle controlled.

How?

Replaces the empty label with a descriptive, translatable label using the caller and connector names using Allow %1$s to use %2$s, which provides each toggle with an accessible name.

Use of AI Tools

AI assistance: Yes

Tool(s): ChatGPT

Model(s): GPT-5.5

Used for: Review of implementation approach. Implementation and testing completed and verified manually.

Testing Instructions

• Navigate to Tools -> Connector Approvals.
• Inspect a toggle control in the approval matrix.
• Open the browser Accessibility pane.
• Verify that before the fix the checkbox has an empty accessible name (Name: "").
• Apply change and refresh the page.
• Verify if checkbox has a descriptive accessible name containing the caller and connector names.

Changelog Entry

Fixed - Add descriptive accessible labels to approval matrix toggle controls.

[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: ishitaj34 <ishitaj34@git.wordpress.org>
Co-authored-by: Trushiv04 <trushiv@git.wordpress.org>
Co-authored-by: dkotter <dkotter@git.wordpress.org>

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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.58%. Comparing base (35be266) to head (a9ddfd6).

Additional details and impacted files

@@            Coverage Diff             @@
##             develop     #637   +/-   ##
==========================================
  Coverage      74.58%   74.58%           
  Complexity      1754     1754           
==========================================
  Files             85       85           
  Lines           7547     7547           
==========================================
  Hits            5629     5629           
  Misses          1918     1918           

Flag	Coverage Δ
unit	74.58% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Trushiv04]

Hi @ishitaj34, thanks for jumping on this so quickly!

I also have a fix ready — happy to review your PR #637 and provide feedback.
If the approach aligns, I'm glad to defer to your PR rather than open a duplicate.

[ishitaj34]

Thanks @Trushiv04 !
Happy to get any feedback on the PR.

[Trushiv04]

Reviewed the changes the approach looks correct to me.
Replacing the empty label with a sprintf-based i18n string
properly addresses the WCAG 2.1 SC 4.1.2 violation. LGTM! 👍

[Trushiv04]

Hi @ishitaj34, I noticed the Plugin Check and E2E tests are failing.
It might help to sync with the latest develop branch:

git fetch upstream
git merge upstream/develop
git push origin fix/issue-634

This should resolve any conflicts and potentially fix the failing checks.
Let me know if you need help!

[ishitaj34]

@Trushiv04 Thanks for that. I did sync with the latest develop branch, and it is already up to date. I'll continue investigating why they're failing.
Appears unrelated to the PR for now.

[Trushiv04]

I looked into both failing checks:

E2E test (connector-approval.spec.js:105): The test fails waiting for .notice-warning to become visible within 5s. This appears unrelated to the label change it's checking the approval notice rendering, which our diff doesn't touch. This may be a flaky test or a pre-existing environment issue.

Plugin Check: The log shows No files were found with the provided path: .../plugin-check-results.txt this looks like a CI artifact/infrastructure issue rather than a code problem.

Syncing with the latest develop (in case these were fixed upstream) and re-running the checks might clear them. If they persist, it's likely worth flagging to a maintainer since they don't seem caused by this change.

[dkotter]

I looked into both failing checks:

E2E test (connector-approval.spec.js:105): The test fails waiting for .notice-warning to become visible within 5s. This appears unrelated to the label change it's checking the approval notice rendering, which our diff doesn't touch. This may be a flaky test or a pre-existing environment issue.

Plugin Check: The log shows No files were found with the provided path: .../plugin-check-results.txt this looks like a CI artifact/infrastructure issue rather than a code problem.

Plugin Check is a known failure due to upstream problems so we're fine there.

But for the failing E2E test, I did verify our tests pass on develop but fail on this PR so the changes in this PR are causing issues there.

In doing some quick testing, pretty sure it's failing here:

ai/tests/e2e/specs/experiments/connector-approval.spec.js

Lines 87 to 100 in f435d19

	// Trigger a fresh request if no pending row exists yet.
	const pendingRow = page
	.locator( 'table.widefat.striped tbody tr' )
	.filter( {
	has: page.locator( 'code', { hasText: 'ai/ai.php' } ),
	} )
	.filter( { hasText: 'OpenAI' } );
	if ( ( await pendingRow.count() ) === 0 ) {
	await admin.visitAdminPage( 'index.php' );
	await admin.visitAdminPage(
	'tools.php?page=ai-connector-approval'
	);
	}

I think that code is now matching due to the labels added in this PR. Two things:

1. Likely this E2E could be hardened to avoid this wrong matching
2. But bigger issue here, I don't think we should show visible labels in this approval table. Can we add screen reader labels instead?

[ishitaj34]

@dkotter Thanks for looking into it. I see what you mean about the row matching now. I'll take a look at using a screen reader-only label approach and retest it.

[ishitaj34]

Hi @dkotter
I've updated the implementation to use an aria-label instead. Also verified that the toggle exposes the expected accessible name while keeping the approval matrix visually unchanged. E2E test also passed. Thanks!