Accessibility linting with GitHub Actions

Run ZemDomu on pull requests so semantic findings are visible in CI alongside editor and local CLI feedback. Start with a known failing fixture, confirm that GitHub places the finding on the expected file, and only then treat the workflow as a merge gate.

Add a complete pull-request workflow

Create .github/workflows/zemdomu.yml with the workflow below. It grants only read access to repository contents, checks out the pull request, and sends the supported HTML, JSX, TSX, and Vue source pattern to the ZemDomu Action.

The published Hub examples currently track the Action's main branch. For a stable production gate, replace @main with an audited release tag or full commit SHA when the Action project publishes the version you intend to standardize on.

# .github/workflows/zemdomu.yml
name: ZemDomu Semantic Checks

on:
  pull_request:

permissions:
  contents: read

jobs:
  zemdomu:
    name: Lint semantic accessibility
    runs-on: ubuntu-latest
    timeout-minutes: 10
    steps:
      - name: Check out repository
        uses: actions/checkout@v4
      - name: Run ZemDomu
        uses: Zemdomu/ZemDomu-action@main
        with:
          files: |
            **/*.{html,jsx,tsx,vue}

Verify the workflow with a known finding

Before relying on the check, open a test pull request containing a supported, intentional violation such as a page that jumps from h1 to h3. The workflow should report the affected source file and rule so a reviewer can navigate from the check to the code.

The annotation below is illustrative: exact wording and presentation can change with the Action version, but the useful fields are the file, line, rule code, rule name, and remediation message.

src/pages/Dashboard.tsx
Line 12 - ZMD002 - enforceHeadingOrder
Heading level jumps from h1 to h3; use h2 for the next section.

Handle a semantic failure

When ZemDomu reports a finding, the check is expected to remain unsuccessful until the source is corrected. Open the annotation's file and line, use its rule code to review the matching rule page, and fix the semantic relationship rather than only changing presentation.

Run npx zemdomu "**/*.{html,jsx,tsx,vue}" locally against the same pattern, push the correction, and wait for GitHub to rerun the pull-request workflow. Use an inline disable only after documenting why the reported source is a deliberate exception; a suppression does not validate the rendered experience.

  1. Open the failed ZemDomu job and distinguish a source finding from a setup failure.
  2. For a source finding, correct the referenced file and verify the same glob locally.
  3. Push the fix and confirm that the new workflow run succeeds before merging.

Troubleshoot setup and file matching

If the job fails before any semantic finding appears, expand the failed step and read its log first. A missing checkout, invalid YAML indentation, unavailable Action reference, or repository policy that blocks third-party actions is a workflow problem rather than an accessibility result.

If the job passes but expected files are absent, compare the files input with the repository root and extensions, preserve the quoted brace glob when reproducing it locally, and check that generated or build-output paths are not the only place the markup exists. The workflow scans committed source available to the runner, not an editor's unsaved changes.

If local and CI results differ, use the same source revision, glob, ZemDomu version or Action reference, cross-component settings, and import depth in both environments. Pinning an audited Action revision removes changes from @main as a variable.

Keep runtime testing beside CI linting

A passing Action run confirms only the supported source rules for the files that matched. It cannot prove focus order, dynamic announcements, contrast, keyboard operation, or assistive-technology output.

Keep browser, rendered-DOM, manual, and assistive-technology checks in the release process, especially for behavior created after interaction or data loading.

Related ZemDomu rules