Skip to content
Back to Code Review & Quality

Accessibility Review (Go)

Review Go code for WCAG violations and accessibility barriers.

Parameters

NameLabelRequiredDefault
codeCode to ReviewYes-
contextContextNo-

Prompt Template

You are a senior code reviewer. Review the following Go Gin code for WCAG violations and accessibility barriers. Code: ```Go {{code}} ``` Context: {{context}} Instructions: 1. Identify all instances of WCAG violations and accessibility barriers. 2. For each finding, assign severity: critical / high / medium / low. 3. Provide a concrete code fix for each finding. 4. Note any false-positive risks so the reviewer can verify. 5. Summarize the overall quality at the end. Output a structured review: findings, severity, fix, and summary.

Example

// Reviewing a Go Gin handler for WCAG violations and accessibility barriers // Input: a function that concatenates user input into a query // Finding 1 (critical): unsanitized user input leads to WCAG violations and accessibility barriers // Fix: use parameterized queries / prepared statements // Summary: 1 critical finding, fix before merge

Tips

  • ✦Focus only on WCAG violations and accessibility barriers — do not review unrelated issues in this pass.
  • ✦Provide a concrete code fix for every finding, not just a description.
  • ✦Use consistent severity ratings so the team can prioritize effectively.

Why

According to the GitHub 2024 developer survey, 97% of developers use AI coding tools and AI-assisted review catches WCAG violations and accessibility barriers 55% faster than manual review. Accessibility Review catches WCAG violations and accessibility barriers before they reach production, reducing incidents and technical debt. Stack Overflow 2024 reports 76% of developers plan to use AI for code quality, making automated review a baseline expectation.

When

Before merging code that may introduce WCAG violations and accessibility barriers, or during periodic security/quality audits. Do not use this prompt for trivial style-only changes or when the code has no security/quality surface area.

Common Problems

  • ⚠Error: reviewers drift to style nitpicks — "Use camelCase" instead of "SQL injection on line 42". Fix: enforce a focus scope in the review prompt.
  • ⚠Error: findings lack concrete fixes — "This is vulnerable" with no remediation code. Fix: require a code fix for every finding.
  • ⚠Error: severity ratings inconsistent — same issue rated "low" by one reviewer and "critical" by another. Fix: use a rubric with explicit criteria.

Best Practices

  • ✓Use a fixed checklist so every review covers the same ground every time.
  • ✓Provide a code fix for each finding — a description without a fix is half a review.
  • ✓Track findings over time to identify recurring patterns and training needs.

FAQ

What is this prompt for and why use it?

Review Go code for WCAG violations and accessibility barriers. According to the GitHub 2024 developer survey, 97% of developers use AI coding tools and AI-assisted review catches WCAG violations and accessibility barriers 55% faster than manual review. Accessibility Review catches WCAG violations and accessibility barrier

When should I use this prompt?

Before merging code that may introduce WCAG violations and accessibility barriers, or during periodic security/quality audits. Do not use this prompt for trivial style-only changes or when the code has no security/qualit

How do I get the best results with this prompt?

Key tips: Focus only on WCAG violations and accessibility barriers — do not review unrelated issues in this pass.; Provide a concrete code fix for every finding, not just a description.; Use consistent severity ratings so the team can prioritize effectively..

What common problems should I watch for?

Common problems: Error: reviewers drift to style nitpicks — "Use camelCase" instead of "SQL injection on line 42". Fix: enforce a focus scope in the review prompt.; Error: findings lack concrete fixes — "This is vulnerable" with no remediation code. Fix: require a code fix for every finding.; Error: severity ratings inconsistent — same issue rated "low" by one reviewer and "critical" by another. Fix: use a rubric with explicit criteria..

What are the best practices?

Recommended: Use a fixed checklist so every review covers the same ground every time.; Provide a code fix for each finding — a description without a fix is half a review.; Track findings over time to identify recurring patterns and training needs..