[pending ParakhAI-frontend#442] test: mobile nav dialog accessible name

[saqibmanan]

Pending: covers open CivicDataLab/ParakhAI-frontend#442 (head 24db653). Skipped in CI until it merges. Safe to merge before it.

Source PR

CivicDataLab/ParakhAI-frontend#442 — "fix: add branded 404 page and fix mobile menu accessible name" (open, base dev, created 2026-07-31, >72h old, no existing coverage).

What behaviour changes

Two independent fixes in one PR:

1. app/not-found.tsx (new): a branded 404 page replacing the bare default Next.js 404.
2. components/layout/Sidebar.tsx: Sheet.Content (opub-ui, built on Radix) now receives title="Navigation menu". Per the PR body, Sheet.Content only renders Radix's DialogTitle when given a title prop — without it, the dialog's auto-generated aria-labelledby pointed at an id that was never in the DOM, so the open mobile menu had no accessible name.

Category chosen

accessibility (axe-core scan of the open mobile menu) for fix #2. No category added for fix #1 — see "Not covered" below.

Red → green → skip proof

1. Collection under CI's real filter (pytest tests/accessibility/ -m "accessibility"): the new test collects (35 items total, test present).

2. RED — marker stripped, run against dev.parakh.civicdataspace.in (current/unmerged behaviour):

tests/accessibility/test_mobile_nav_accessible_name.py::TestMobileNavAccessibleName::test_mobile_nav_dialog_has_accessible_name[chromium] FAILED
AssertionError: Dialog has no aria-labelledby at all — the #442 DialogTitle fix regressed (or never applied).
assert None
1 failed, 2 rerun in 27.41s

Confirmed directly before writing the assertion: opening the mobile menu on dev and running axe-core gives violations: ['aria-dialog-name', 'button-name', 'color-contrast'] — aria-dialog-name (impact "serious") is exactly the bug this PR fixes; the other two are pre-existing and out of scope.

3. GREEN — marker stripped, PR head (24db653) served locally (next dev, dev's GraphQL API, stub Keycloak/NextAuth env since the homepage itself needs no session):

tests/accessibility/test_mobile_nav_accessible_name.py::TestMobileNavAccessibleName::test_mobile_nav_dialog_has_accessible_name[chromium] PASSED
1 passed in 4.41s

Confirmed directly: aria-labelledby now resolves to an element whose text is "Navigation menu", and aria-dialog-name is no longer in axe's violation list (['button-name', 'color-contrast'] only).

4. Marker restored — re-ran against dev, confirmed the same SKIPPED ... pending_pr ParakhAI-frontend#442: not merged yet as step 1.

Not covered — and why

• The branded 404 page (fix Potential fix for code scanning alert no. 7: Workflow does not contain permissions #1) has no test here, pending or otherwise, and can't get one as an anonymous check. middleware.ts sets publicPages = ['/'] — literally every other path, including one that matches no route, requires auth and 307s to /api/auth/signin before Next.js's router ever resolves not-found.tsx. Verified both against dev and against a local build of the PR head: curl to a nonexistent path returns 307 to sign-in on both, never the 404 content. This isn't a credentials gap I can route around — an authenticated session is structurally required to reach the page at all, so there's nothing for this cloud routine (or any unauthenticated check) to prove. UNVERIFIED — not written, no credentialed session available in this environment to even attempt a red run. A human (or the local /pr-test-sync session, which has real test credentials) should log in, confirm /some-nonexistent-path now renders the branded 404 instead of the Next.js default, and add that as its own test once #442 merges.
• readonly: not applicable yet — the feature isn't on main/prod. Follow-up once #442 ships there.

Known edge (per pr-test-sync skill §9)

Merged isn't deployed: if dev's deploy fails its smoke gate after #442 merges and rolls back, this test will go red against the old page — that's a real signal, not a flake.

[saqibmanan]

CI is red on Test Summary, but not because of this PR's diff (which only adds tests/accessibility/test_mobile_nav_accessible_name.py).

This PR's new test behaved correctly: test_mobile_nav_dialog_has_accessible_name[chromium] shows SKIPPED — pending_pr ParakhAI-frontend#442: not merged yet, exactly as designed.

The actual failure is pre-existing and unrelated: tests/accessibility/test_accessibility_auth.py::TestDialogAccessibility::test_ux011_new_evaluation_dialog_selects_have_labels[chromium]:

FAILED ... - [XPASS(strict)] UX-011: Select fields in New Evaluation dialog have no accessible label — known bug

That test is decorated @pytest.mark.xfail(reason="UX-011: ... known bug") on main today. It just unexpectedly passed against dev — the known bug looks to have been fixed in the product — and the repo's strict-xfail setting turns an unexpected pass into a reported failure. Nothing in this PR touches that file or that page.

I did not push a fix into this PR: removing/updating someone else's xfail marker is out of scope for a test-sync PR (new tests only, never edit existing ones), and this PR's own base-merge carries no code change that would justify riding a fix along with it.

Proposed patch (for a separate PR, not this one): drop the @pytest.mark.xfail(...) decorator on test_ux011_new_evaluation_dialog_selects_have_labels in tests/accessibility/test_accessibility_auth.py once someone confirms the dialog's selects now carry accessible labels — or re-open UX-011 if this turns out to be a flake rather than a real fix.

---

Generated by Claude Code