Site icon QATechTools

Chrome Extension Accessibility Evidence for QA Bug Reports

bajpaiprashant
Chrome Extension Accessibility Evidence for QA Bug Reports featured image

Accessibility bugs are easier to triage when the report includes evidence from the page, not only a sentence like “screen reader issue” or “button is not accessible.” A lightweight helper can collect repeatable page signals before a QA engineer files the bug. This tutorial shows how to build Chrome extension accessibility evidence into a practical Manifest V3 workflow for QA teams.

The goal is not to replace a full accessibility audit, a screen reader pass, or a dedicated accessibility testing tool. The goal is to capture useful evidence quickly: missing image alt text, unlabeled controls, heading order signals, focusable elements, page metadata, and tester notes. That gives developers a clearer starting point when they reproduce and fix the issue.

What the Extension Should Capture

Keep the first version small. A focused evidence collector is easier to trust than a large tool that claims too much. Use a tester action, such as clicking the extension button, to capture the current page state.

Chrome extension documentation supports this architecture with a manifest file, service worker or extension page, content scripts, and optional side panel UI. The official activeTab permission is useful for a tester-clicked workflow because it grants temporary access to the active tab after a user gesture.

Manifest V3 Starter Setup

Create a small extension folder with a manifest, popup or side panel, and one content script. Start with narrow permissions. You can add more later if the workflow truly needs them.

{
  "manifest_version": 3,
  "name": "QA Accessibility Evidence Helper",
  "version": "1.0.0",
  "description": "Capture page accessibility evidence for QA bug reports.",
  "permissions": ["activeTab", "scripting", "storage", "sidePanel"],
  "action": {
    "default_title": "Capture accessibility evidence",
    "default_popup": "popup.html"
  },
  "background": {
    "service_worker": "service-worker.js"
  },
  "side_panel": {
    "default_path": "sidepanel.html"
  }
}

This setup uses stable Chrome extension building blocks: a manifest, user-triggered tab access, script execution, storage, and an optional side panel. Avoid broad host permissions until you have a real reason. For internal QA tools, a tester-clicked capture button is usually enough for the first version.

Chrome Extension Accessibility Evidence Workflow

The practical workflow is simple:

  1. The tester opens the page with the suspected accessibility issue.
  2. The tester clicks the extension button.
  3. The extension injects a capture function into the active tab.
  4. The capture function inspects the DOM for accessibility evidence.
  5. The popup or side panel displays findings and lets the tester add notes.
  6. The tester copies the evidence summary into the bug report.

Content scripts run in an isolated world, but they can inspect the page DOM. That is enough for many evidence checks, such as whether an image has an alt attribute or whether a form control has a visible label, aria-label, or aria-labelledby. Do not claim that this captures every assistive-technology behavior. Treat it as evidence, not a verdict.

Starter Snippet: Capture Page Signals

The snippet below is intentionally small. It returns a JSON-friendly summary that can be shown in a popup, side panel, or copied into a bug report.

function captureAccessibilityEvidence() {
  const missingAltImages = [...document.images]
    .filter((img) => !img.hasAttribute("alt") || img.getAttribute("alt").trim() === "")
    .map((img) => ({
      src: img.currentSrc || img.src,
      selector: img.id ? `#${img.id}` : img.tagName.toLowerCase()
    }));

  const controlsWithoutLabels = [...document.querySelectorAll("button, input, select, textarea, a[href]")]
    .filter((el) => {
      const text = (el.innerText || el.value || "").trim();
      const aria = el.getAttribute("aria-label") || el.getAttribute("aria-labelledby");
      const id = el.getAttribute("id");
      const label = id ? document.querySelector(`label[for="${CSS.escape(id)}"]`) : null;
      return !text && !aria && !label;
    })
    .map((el) => ({
      tag: el.tagName.toLowerCase(),
      type: el.getAttribute("type") || "",
      selector: el.id ? `#${el.id}` : el.tagName.toLowerCase()
    }));

  const headings = [...document.querySelectorAll("h1,h2,h3,h4,h5,h6")]
    .map((heading) => ({
      level: Number(heading.tagName.slice(1)),
      text: heading.innerText.trim().slice(0, 80)
    }));

  return {
    url: location.href,
    title: document.title,
    capturedAt: new Date().toISOString(),
    missingAltImages,
    controlsWithoutLabels,
    headings
  };
}

Run this function only after the tester clicks the extension. The scripting API can inject a function into the active tab, and the returned result can be passed back to the extension UI.

Show Findings in a Side Panel

A side panel is useful for QA because the evidence stays visible beside the page. The tester can compare the findings with the UI and add notes without losing context. Keep the panel dense and practical:

Use Chrome storage for recent evidence and notes. The storage API persists JSON-serializable values asynchronously across extension contexts, which fits this workflow. Store only what helps the bug report. Avoid collecting sensitive form values or personal data unless your organization has a clear policy and consent process.

Bug Report Template

Give testers a repeatable format. This helps developers see what was observed, what was expected, and which signals need review.

Accessibility evidence summary
Page: [URL]
Title: [document title]
Captured at: [timestamp]

Observed issue:
[tester note]

Evidence:
- Images missing alt text: [count + examples]
- Controls without clear labels: [count + examples]
- Heading order notes: [outline or skipped level]
- Keyboard/focus notes: [tester observation]

Expected result:
[what should happen]

Reproduction steps:
1. Open the page.
2. Navigate to the affected section.
3. Run the accessibility evidence helper.
4. Review the listed elements and compare with the UI.

Screenshot Checklist

Capture exactly these screens while following the workflow:

  1. The target page showing the affected UI area.
  2. The extension popup or side panel with captured evidence counts.
  3. The DOM or page area showing the specific unlabeled control or missing alt case.
  4. The final bug report summary with tester notes and expected behavior.

Common Mistakes to Avoid

References

FAQ

Can a Chrome extension prove that a page is accessible?

No. A Chrome extension can collect helpful evidence from the page DOM, but accessibility still needs human review, keyboard testing, and often assistive-technology checks.

Should the extension store full page HTML?

Usually no. Store targeted evidence, element summaries, page URL, timestamp, and tester notes. Full HTML can expose sensitive data and make reports noisy.

Why use activeTab instead of broad host permissions?

The activeTab permission fits a user-triggered QA workflow because access is temporary and tied to a tester action on the current tab.

Conclusion

Chrome extension accessibility evidence is most useful when it stays focused. Capture visible page signals, let the tester add context, and export a clean summary for the bug report. That gives developers better reproduction data without pretending that a helper extension replaces a full accessibility review.


Exit mobile version