DEV Community

babycat
babycat

Posted on

"Build an Accessible Findings Queue That Shows Its Evidence Type"

#a11y #frontend #github #ai

A keyboard user opens a finding and hears only “High severity issue.” They cannot tell whether it came from a repeatable CodeQL query or AI-assisted detection, and the proposed Autofix looks like an already approved change. The missing UI state is provenance plus review status.

GitHub made Code Quality generally available on July 20 for Enterprise Cloud and Team. Its latest verified official signal describes deterministic CodeQL, AI-assisted detection, and reviewable Autofix. GitHub's internal resolution metric is GitHub-reported, not an accessibility or universal-quality benchmark. I found no newer reliable official July 27 release and rejected unverified secondary claims.

Model evidence separately from workflow 

type Finding = {
  id: string;
  title: string;
  origin: "deterministic" | "ai_assisted";
  rule?: string;
  location: { file: string; line: number };
  evidence: string;
  fix: null | { patch: string; status: "proposed" | "accepted" | "rejected" };
};
Enter fullscreen mode Exit fullscreen mode

origin says how a finding was produced; it does not say whether it is correct. fix.status records a human workflow decision; it does not rewrite provenance. Keep these dimensions independent.

A small semantic card 

<article aria-labelledby="f-17-title">
  <h3 id="f-17-title">Unsanitized redirect target</h3>
  <p><strong>Detection:</strong> Deterministic CodeQL rule</p>
  <p><strong>Location:</strong> <code>routes.ts:44</code></p>
  <details>
    <summary>Review evidence and proposed fix</summary>
    <p id="f-17-evidence">Source reaches a redirect sink.</p>
    <pre tabindex="0" aria-label="Proposed patch">...</pre>
  </details>
  <fieldset aria-describedby="f-17-evidence">
    <legend>Autofix decision</legend>
    <label><input type="radio" name="f-17" value="accept"> Accept after review</label>
    <label><input type="radio" name="f-17" value="reject"> Reject with reason</label>
  </fieldset>
  <button type="button">Save decision</button>
</article>
Enter fullscreen mode Exit fullscreen mode

Use visible words, not color or icons alone. “AI-assisted finding” is clearer than a sparkle. “Proposed Autofix” is clearer than “Fixed.” A focusable pre lets keyboard users scroll long patches, but a real implementation also needs line-by-line additions/deletions and a plain-text fallback.

State behavior

Announce counts politely, saving briefly, failures assertively, and resolution without reading the whole patch. Keep focus on the triggering control after expansion, move it to an error summary after failure, and send it to the next card when one disappears.

Normal path: the reviewer filters by origin, opens evidence, inspects the patch, selects a decision, and receives a durable confirmation without focus moving unexpectedly.

Failure path: saving returns an error or the finding revision changed. Preserve the choice locally, mark the record stale, focus a linked error summary, and require the new patch to be reviewed. Never submit the old acceptance against a changed Autofix.

A revision-aware request might be:

{
  "findingId": "f-17",
  "findingRevision": 3,
  "decision": "accept",
  "reviewedPatchHash": "sha256:..."
}
Enter fullscreen mode Exit fullscreen mode

The server rejects mismatched revisions with 409 Conflict. The interface then says “The proposed fix changed; review it again,” expands the new evidence, and leaves the decision unset.

Accessibility QA

Test keyboard order and traps, screen-reader labels, 400% reflow, reduced motion, and high-contrast status cues. Record browser, OS, assistive technology, and versions; this proposed matrix was not executed.

Release checklist:

  • Expose deterministic versus AI-assisted origin in text.
  • Keep severity, confidence, provenance, and decision as separate fields.
  • Require explicit review before an Autofix is accepted.
  • Bind decisions to a patch hash or finding revision.
  • Support reject-with-reason and retry after save failure.
  • Preserve focus when sorting or removing cards.
  • Check current plan availability and product behavior.

Limits: this component does not establish CodeQL semantics, finding correctness, WCAG conformance, or GitHub UI behavior. A card view may be insufficient for very large patches; provide a full diff. Product labels and availability can change.

Evaluate the same UI discipline elsewhere

MonkeyCode can be evaluated after these states are defined. Verified material describes an open-source AGPL-3.0 AI development platform, overseas online option, managed server-side cloud development environments, model/task/requirement management, and build/test/preview, free to start. I have not tested its interface. If it fits your candidate list, use the official campaign route and repeat the keyboard, stale-revision, and failure review rather than assuming accessibility.

Disclosure: This article promotes MonkeyCode using an official campaign link. I’m a MonkeyCode user, not affiliated with the project, and I receive no commission from this link.

AI assistance disclosure: This article was drafted with AI assistance and reviewed against the cited primary sources.

Top comments (0)