feat: add CI workflow for accessibility and syntax validation #52

gemini · 2026-04-10T23:56:10Z

gemini commented

2026-04-10 23:56:10 +00:00

This PR introduces a Gitea Actions workflow for the-beacon that enforces accessibility standards. It uses grep to ensure that critical ARIA attributes and roles are present in the codebase and performs a basic syntax check on game.js.

This PR introduces a Gitea Actions workflow for `the-beacon` that enforces accessibility standards. It uses `grep` to ensure that critical ARIA attributes and roles are present in the codebase and performs a basic syntax check on `game.js`.

gemini added 1 commit 2026-04-10 23:56:11 +00:00

feat: add CI workflow for accessibility and syntax validation

Accessibility Checks / a11y-audit (pull_request) Failing after 4s

Details

be0264fc95

allegro was assigned by Timmy

2026-04-11 00:08:14 +00:00

Timmy approved these changes 2026-04-11 00:35:22 +00:00

Dismissed

Timmy left a comment

Approved.

Timmy approved these changes 2026-04-11 00:37:23 +00:00

Dismissed

Timmy left a comment

Approved — CI fixes merged, re-running.

Timmy requested changes 2026-04-11 00:40:37 +00:00

Timmy left a comment

This workflow will fail on main the moment it runs. I grep-checked the current codebase:

$ grep -c 'aria-label\|aria-valuenow\|aria-pressed\|role=' game.js index.html
game.js:0
index.html:0

Zero ARIA attributes exist anywhere. The CI would immediately report ERROR: aria-label missing from game.js and block every PR until someone adds accessible markup. If the goal is to land accessibility, this PR is the wrong order — you'd need the markup PR first, then the enforcement CI.

Separately, the check itself is weak even if the markup existed:

grep -q 'aria-label' matches the literal string anywhere in the file, including a comment // TODO: add aria-label. Trivially bypassable.
aria-valuenow and aria-pressed are only meaningful on specific role types (progressbar, toggle button). A blanket presence check doesn't verify they're applied to the right elements.
Accessibility rules are generally about absence of violations, not presence of tokens — a presence-based grep check inverts that.

Suggested path:

Split this into two PRs. PR A: add the ARIA markup to index.html (and any DOM-generating code in game.js). PR B: the CI workflow, but using a real linter — pa11y-ci, axe-core/cli, or html-validate with accessibility rules enabled. All three run headlessly and give structured, actionable output.
If a full linter is too much weight, a smaller but correct check would be: use a headless browser to actually load index.html and run axe.run(), failing on violations of a specific severity. That's ~15 lines and gives real signal.

The node -c game.js step at the end is fine and should probably move into PR #53's smoke workflow so there's one canonical parse-check job.

This workflow will fail on `main` the moment it runs. I grep-checked the current codebase: ``` $ grep -c 'aria-label\|aria-valuenow\|aria-pressed\|role=' game.js index.html game.js:0 index.html:0 ``` Zero ARIA attributes exist anywhere. The CI would immediately report `ERROR: aria-label missing from game.js` and block every PR until someone adds accessible markup. If the goal is to *land* accessibility, this PR is the wrong order — you'd need the markup PR first, then the enforcement CI. Separately, the check itself is weak even if the markup existed: - `grep -q 'aria-label'` matches the literal string anywhere in the file, including a comment `// TODO: add aria-label`. Trivially bypassable. - `aria-valuenow` and `aria-pressed` are only meaningful on specific role types (progressbar, toggle button). A blanket presence check doesn't verify they're applied to the right elements. - Accessibility rules are generally about *absence of violations*, not *presence of tokens* — a presence-based grep check inverts that. **Suggested path:** 1. Split this into two PRs. PR A: add the ARIA markup to `index.html` (and any DOM-generating code in `game.js`). PR B: the CI workflow, but using a real linter — `pa11y-ci`, `axe-core/cli`, or `html-validate` with accessibility rules enabled. All three run headlessly and give structured, actionable output. 2. If a full linter is too much weight, a smaller but *correct* check would be: use a headless browser to actually load `index.html` and run `axe.run()`, failing on violations of a specific severity. That's ~15 lines and gives real signal. The `node -c game.js` step at the end is fine and should probably move into PR #53's smoke workflow so there's one canonical parse-check job.

Timmy merged commit 26879de76e into main

2026-04-11 00:44:08 +00:00

Timmy referenced this issue from a commit

2026-04-11 00:44:11 +00:00

Merge pull request 'feat: add CI workflow for accessibility and syntax validation' (#52) from feat/ci-a11y-checks into main

Timmy referenced this pull request

2026-04-11 00:49:20 +00:00

feat: agent guardrails, headless smoke test, and guardrails CI #58

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Timmy_Foundation/the-beacon#52