This audit ran the open-source axe-core 4.10.2 engine against 1 page of townofbrackmoor.gov and tested every WCAG 2.1 Level A and AA success criterion automated testing can cover. It found 10 rule failures across 30 elements, mapping to 7 distinct WCAG criteria. The next sections rank the issues by end-user impact and walk through every criterion with copy-paste fix code.
Violation severity breakdown by element count
Severity breakdown table, paired with the chart above
Severity
Elements
Share
Critical
6
20.0%
Serious
24
80.0%
Most-violated WCAG criteria, ranked by element count
Top WCAG criteria violated, ranked by element count
This audit is a hypothetical demonstration of the Site Brace report format, run against a fictional municipality (Town of Brackmoor). No real site was scanned. Order a real audit of your site for $149 flat, including 12 re-scans you can run anytime within 12 months.
Top 5 quick wins, ranked by user impact
Issues are ranked by how many real users they affect, weighted toward severe blockers and divided by typical effort to fix. Start at the top: clearing this list is what moves the needle most for users with disabilities visiting your pages.
Top quick-win violations ranked by end-user impact
Reading the effort column. Low is a one-attribute change or a CSS tweak; Medium is a markup refactor or a values lookup; High is a structural rewrite. Click each issue to jump to its detailed entry with copy-paste fix code and an LLM prompt.
Issues by WCAG criterion
Each block below corresponds to one WCAG 2.1 success criterion that the scan flagged on at least one page. Within each criterion, every axe-core rule that contributed is listed with a recommended fix, sample offending HTML, and a copy-paste prompt for an LLM that will generate framework-specific code.
Every interactive element has a programmatically determinable name, role, and current state, so assistive tech can describe it. Custom widgets need ARIA roles and state attributes.
Who is affected when this fails
Screen reader users hear what an element is (button, checkbox, slider) and its current state (checked, expanded, disabled). Custom widgets that skip these annotations show up as 'group' or silence in the screen reader, blocking interaction. Voice-input users also depend on the role and name.
Issue: Links must have discernible text
Serious axe-core rule link-name, found on 5 elements across this run.
How to fix
Add visible text inside the link. For image-only links, give the image meaningful alt text. For icon-only links, add an aria-label or a visually-hidden text span.
Every value below is pre-filled from your audit. Paste this entire block into Claude or ChatGPT and the AI will respond with corrected code.
I have a WCAG 2.1 Level A accessibility violation on my website. Please give me corrected code.
Page URL: https://townofbrackmoor.gov/
My website is built on: granicus
WCAG criterion: 4.1.2 Name, Role, Value (Level A)
What this criterion requires: Every interactive element has a programmatically determinable name, role, and current state, so assistive tech can describe it. Custom widgets need ARIA roles and state attributes.
Reference: https://www.w3.org/WAI/WCAG21/Understanding/name-role-value
axe-core rule: link-name (impact: serious)
Rule explanation: Links must have discernible text
Full rule docs: https://dequeuniversity.com/rules/axe/4.10/link-name?application=axeAPI
Offending HTML element:
<a href="https://facebook.com/townofbrackmoor"><i class="icon-facebook"></i></a>
CSS selector that targets this element:
.social-row > a:nth-child(1)
Please:
1. Show me the corrected HTML or CSS in granicus.
2. Explain what changed and why this fixes the WCAG violation.
3. Tell me how to verify the fix worked, including any screen reader behavior I should expect.
Issue: ARIA hidden element must not be focusable or contain focusable elements
Serious axe-core rule aria-hidden-focus, found on 3 elements across this run.
How to fix
Either remove aria-hidden, or remove the element (and its descendants) from the keyboard tab order using tabindex="-1" on each focusable child, or hide them entirely with display:none.
Every value below is pre-filled from your audit. Paste this entire block into Claude or ChatGPT and the AI will respond with corrected code.
I have a WCAG 2.1 Level A accessibility violation on my website. Please give me corrected code.
Page URL: https://townofbrackmoor.gov/
My website is built on: granicus
WCAG criterion: 4.1.2 Name, Role, Value (Level A)
What this criterion requires: Every interactive element has a programmatically determinable name, role, and current state, so assistive tech can describe it. Custom widgets need ARIA roles and state attributes.
Reference: https://www.w3.org/WAI/WCAG21/Understanding/name-role-value
axe-core rule: aria-hidden-focus (impact: serious)
Rule explanation: ARIA hidden element must not be focusable or contain focusable elements
Full rule docs: https://dequeuniversity.com/rules/axe/4.10/aria-hidden-focus?application=axeAPI
Offending HTML element:
<div aria-hidden="true" class="modal" id="alertModal"><button>Close</button><a href="/details">Details</a></div>
CSS selector that targets this element:
#alertModal
Please:
1. Show me the corrected HTML or CSS in granicus.
2. Explain what changed and why this fixes the WCAG violation.
3. Tell me how to verify the fix worked, including any screen reader behavior I should expect.
Issue: Buttons must have discernible text
Critical axe-core rule button-name, found on 2 elements across this run.
How to fix
Give the button an accessible name in one of these ways: visible text inside the button, an aria-label attribute on the button, an aria-labelledby pointing at a visible label, or a visually-hidden span inside the button. For icon buttons, aria-label is usually cleanest.
One screenshot per distinct selector pattern per page so you can see the affected element in context. Multiple shots from the same page mean multiple distinct templates were flagged.
Every value below is pre-filled from your audit. Paste this entire block into Claude or ChatGPT and the AI will respond with corrected code.
I have a WCAG 2.1 Level A accessibility violation on my website. Please give me corrected code.
Page URL: https://townofbrackmoor.gov/
My website is built on: granicus
WCAG criterion: 4.1.2 Name, Role, Value (Level A)
What this criterion requires: Every interactive element has a programmatically determinable name, role, and current state, so assistive tech can describe it. Custom widgets need ARIA roles and state attributes.
Reference: https://www.w3.org/WAI/WCAG21/Understanding/name-role-value
axe-core rule: button-name (impact: critical)
Rule explanation: Buttons must have discernible text
Full rule docs: https://dequeuniversity.com/rules/axe/4.10/button-name?application=axeAPI
Offending HTML element:
<button class="search-toggle" aria-label=""></button>
CSS selector that targets this element:
header .search-toggle
Please:
1. Show me the corrected HTML or CSS in granicus.
2. Explain what changed and why this fixes the WCAG violation.
3. Tell me how to verify the fix worked, including any screen reader behavior I should expect.
Issue: Elements must only use permitted ARIA attributes
Serious axe-core rule aria-allowed-attr, found on 2 elements across this run.
How to fix
Remove the disallowed attribute, or change the element's role to one that supports it. The ARIA spec defines the allowed attributes per role.
Every value below is pre-filled from your audit. Paste this entire block into Claude or ChatGPT and the AI will respond with corrected code.
I have a WCAG 2.1 Level A accessibility violation on my website. Please give me corrected code.
Page URL: https://townofbrackmoor.gov/
My website is built on: granicus
WCAG criterion: 4.1.2 Name, Role, Value (Level A)
What this criterion requires: Every interactive element has a programmatically determinable name, role, and current state, so assistive tech can describe it. Custom widgets need ARIA roles and state attributes.
Reference: https://www.w3.org/WAI/WCAG21/Understanding/name-role-value
axe-core rule: aria-allowed-attr (impact: serious)
Rule explanation: Elements must only use permitted ARIA attributes
Full rule docs: https://dequeuniversity.com/rules/axe/4.10/aria-allowed-attr?application=axeAPI
Offending HTML element:
<div role="button" aria-checked="false" tabindex="0">Subscribe</div>
CSS selector that targets this element:
.cta-banner > div[role=button]
Please:
1. Show me the corrected HTML or CSS in granicus.
2. Explain what changed and why this fixes the WCAG violation.
3. Tell me how to verify the fix worked, including any screen reader behavior I should expect.
Issue: Interactive controls must not be nested
Serious axe-core rule nested-interactive, found on 2 elements across this run.
How to fix
Flatten the structure. If a card needs to be clickable AND contain a separate action button, make the card a <a> wrapping non-interactive content, and pull the inner button out to a sibling. Or use a single outer link with the action moved to a separate row.
Every value below is pre-filled from your audit. Paste this entire block into Claude or ChatGPT and the AI will respond with corrected code.
I have a WCAG 2.1 Level A accessibility violation on my website. Please give me corrected code.
Page URL: https://townofbrackmoor.gov/
My website is built on: granicus
WCAG criterion: 4.1.2 Name, Role, Value (Level A)
What this criterion requires: Every interactive element has a programmatically determinable name, role, and current state, so assistive tech can describe it. Custom widgets need ARIA roles and state attributes.
Reference: https://www.w3.org/WAI/WCAG21/Understanding/name-role-value
axe-core rule: nested-interactive (impact: serious)
Rule explanation: Interactive controls must not be nested
Full rule docs: https://dequeuniversity.com/rules/axe/4.10/nested-interactive?application=axeAPI
Offending HTML element:
<a href="/news"><button>Latest news</button></a>
CSS selector that targets this element:
.hero a > button
Please:
1. Show me the corrected HTML or CSS in granicus.
2. Explain what changed and why this fixes the WCAG violation.
3. Tell me how to verify the fix worked, including any screen reader behavior I should expect.
Issue: Form elements must have labels
Critical axe-core rule label, found on 1 element across this run.
How to fix
Wrap the input in a <label> element, or use a separate <label> with a for attribute matching the input's id. Avoid relying on placeholder text as the only label.
<input type="text" id="q" name="q" placeholder="Search the site">
Show copy-paste prompt for Claude or ChatGPT
Every value below is pre-filled from your audit. Paste this entire block into Claude or ChatGPT and the AI will respond with corrected code.
I have a WCAG 2.1 Level A accessibility violation on my website. Please give me corrected code.
Page URL: https://townofbrackmoor.gov/
My website is built on: granicus
WCAG criterion: 4.1.2 Name, Role, Value (Level A)
What this criterion requires: Every interactive element has a programmatically determinable name, role, and current state, so assistive tech can describe it. Custom widgets need ARIA roles and state attributes.
Reference: https://www.w3.org/WAI/WCAG21/Understanding/name-role-value
axe-core rule: label (impact: critical)
Rule explanation: Form elements must have labels
Full rule docs: https://dequeuniversity.com/rules/axe/4.10/label?application=axeAPI
Offending HTML element:
<input type="text" id="q" name="q" placeholder="Search the site">
CSS selector that targets this element:
form.search-form > input#q
Please:
1. Show me the corrected HTML or CSS in granicus.
2. Explain what changed and why this fixes the WCAG violation.
3. Tell me how to verify the fix worked, including any screen reader behavior I should expect.
Text has a contrast ratio of at least 4.5:1 against its background. Large text (18pt or 14pt bold) only needs 3:1.
Who is affected when this fails
Low-vision users (the largest disability category, including most adults over 60) and anyone using a phone outdoors in bright light cannot read low-contrast text. This is the single most common WCAG failure on the web.
Issue: Elements must meet minimum color contrast ratio thresholds
Serious axe-core rule color-contrast, found on 10 elements across this run.
How to fix
Increase the contrast between the foreground (text) and the background. Either darken the text, lighten the background, or both. Avoid grey-on-grey and pale-color-on-white.
One screenshot per distinct selector pattern per page so you can see the affected element in context. Multiple shots from the same page mean multiple distinct templates were flagged.
Every value below is pre-filled from your audit. Paste this entire block into Claude or ChatGPT and the AI will respond with corrected code.
I have a WCAG 2.1 Level AA accessibility violation on my website. Please give me corrected code.
Page URL: https://townofbrackmoor.gov/
My website is built on: granicus
WCAG criterion: 1.4.3 Contrast (Minimum) (Level AA)
What this criterion requires: Text has a contrast ratio of at least 4.5:1 against its background. Large text (18pt or 14pt bold) only needs 3:1.
Reference: https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum
axe-core rule: color-contrast (impact: serious)
Rule explanation: Elements must meet minimum color contrast ratio thresholds
Full rule docs: https://dequeuniversity.com/rules/axe/4.10/color-contrast?application=axeAPI
Offending HTML element:
<a href="/contact">Contact</a>
CSS selector that targets this element:
footer .footer-links a
Please:
1. Show me the corrected HTML or CSS in granicus.
2. Explain what changed and why this fixes the WCAG violation.
3. Tell me how to verify the fix worked, including any screen reader behavior I should expect.
The purpose of every link is clear from the link text alone or together with its surrounding context. Avoid generic 'click here' or 'read more'.
Who is affected when this fails
Screen reader users frequently pull all links on a page into one flat list to scan. Out of that list, 'click here' and 'read more' tell them nothing about where each link goes.
Issue: Links must have discernible text
Serious axe-core rule link-name, found on 5 elements across this run.
How to fix
Add visible text inside the link. For image-only links, give the image meaningful alt text. For icon-only links, add an aria-label or a visually-hidden text span.
Every value below is pre-filled from your audit. Paste this entire block into Claude or ChatGPT and the AI will respond with corrected code.
I have a WCAG 2.1 Level A accessibility violation on my website. Please give me corrected code.
Page URL: https://townofbrackmoor.gov/
My website is built on: granicus
WCAG criterion: 2.4.4 Link Purpose (In Context) (Level A)
What this criterion requires: The purpose of every link is clear from the link text alone or together with its surrounding context. Avoid generic 'click here' or 'read more'.
Reference: https://www.w3.org/WAI/WCAG21/Understanding/link-purpose-in-context
axe-core rule: link-name (impact: serious)
Rule explanation: Links must have discernible text
Full rule docs: https://dequeuniversity.com/rules/axe/4.10/link-name?application=axeAPI
Offending HTML element:
<a href="https://facebook.com/townofbrackmoor"><i class="icon-facebook"></i></a>
CSS selector that targets this element:
.social-row > a:nth-child(1)
Please:
1. Show me the corrected HTML or CSS in granicus.
2. Explain what changed and why this fixes the WCAG violation.
3. Tell me how to verify the fix worked, including any screen reader behavior I should expect.
Provide a text alternative for every non-text element (images, audio, video, charts, icons) so assistive technology can announce it. Decorative images use empty alt.
Who is affected when this fails
Blind and low-vision users who rely on a screen reader cannot tell what an image is showing if it has no text alternative. People on slow or unreliable connections also lose information when images fail to load.
Issue: Images must have alternative text
Critical axe-core rule image-alt, found on 3 elements across this run.
How to fix
Add an alt attribute to every <img>. If the image conveys information, describe it concisely (one sentence). If the image is decorative or duplicates adjacent text, use alt="".
Examples:
<img src="/team-photo.jpg" alt="Five team members at the office whiteboard">
<img src="/decorative-divider.svg" alt="">
How to verify
View the page with images turned off (DevTools: disable images) or open the Accessibility tree. Every img should have an alt that makes sense in context.
One screenshot per distinct selector pattern per page so you can see the affected element in context. Multiple shots from the same page mean multiple distinct templates were flagged.
Every value below is pre-filled from your audit. Paste this entire block into Claude or ChatGPT and the AI will respond with corrected code.
I have a WCAG 2.1 Level A accessibility violation on my website. Please give me corrected code.
Page URL: https://townofbrackmoor.gov/
My website is built on: granicus
WCAG criterion: 1.1.1 Non-text Content (Level A)
What this criterion requires: Provide a text alternative for every non-text element (images, audio, video, charts, icons) so assistive technology can announce it. Decorative images use empty alt.
Reference: https://www.w3.org/WAI/WCAG21/Understanding/non-text-content
axe-core rule: image-alt (impact: critical)
Rule explanation: Images must have alternative text
Full rule docs: https://dequeuniversity.com/rules/axe/4.10/image-alt?application=axeAPI
Offending HTML element:
<img src="/assets/town-seal.png">
CSS selector that targets this element:
header > .site-brand > img
Please:
1. Show me the corrected HTML or CSS in granicus.
2. Explain what changed and why this fixes the WCAG violation.
3. Tell me how to verify the fix worked, including any screen reader behavior I should expect.
Use semantic HTML (headings, lists, tables, form labels, landmarks) so structure and relationships in the visual layout are programmatically determinable.
Who is affected when this fails
Screen reader users rely on real headings, lists, tables, form labels, and landmarks to navigate. Without those, the page sounds like a wall of unstructured text. Voice-control users also depend on programmatic structure to target elements.
Issue: Form elements must have labels
Critical axe-core rule label, found on 1 element across this run.
How to fix
Wrap the input in a <label> element, or use a separate <label> with a for attribute matching the input's id. Avoid relying on placeholder text as the only label.
<input type="text" id="q" name="q" placeholder="Search the site">
Show copy-paste prompt for Claude or ChatGPT
Every value below is pre-filled from your audit. Paste this entire block into Claude or ChatGPT and the AI will respond with corrected code.
I have a WCAG 2.1 Level A accessibility violation on my website. Please give me corrected code.
Page URL: https://townofbrackmoor.gov/
My website is built on: granicus
WCAG criterion: 1.3.1 Info and Relationships (Level A)
What this criterion requires: Use semantic HTML (headings, lists, tables, form labels, landmarks) so structure and relationships in the visual layout are programmatically determinable.
Reference: https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships
axe-core rule: label (impact: critical)
Rule explanation: Form elements must have labels
Full rule docs: https://dequeuniversity.com/rules/axe/4.10/label?application=axeAPI
Offending HTML element:
<input type="text" id="q" name="q" placeholder="Search the site">
CSS selector that targets this element:
form.search-form > input#q
Please:
1. Show me the corrected HTML or CSS in granicus.
2. Explain what changed and why this fixes the WCAG violation.
3. Tell me how to verify the fix worked, including any screen reader behavior I should expect.
Issue: <ul> and <ol> must only directly contain <li>, <script>, or <template> elements
Serious axe-core rule list, found on 1 element across this run.
How to fix
Wrap any non-li children in an <li>, or move them out of the list entirely. If the wrapper is needed for styling, restructure so each list item lives inside its own <li>.
Every value below is pre-filled from your audit. Paste this entire block into Claude or ChatGPT and the AI will respond with corrected code.
I have a WCAG 2.1 Level A accessibility violation on my website. Please give me corrected code.
Page URL: https://townofbrackmoor.gov/
My website is built on: granicus
WCAG criterion: 1.3.1 Info and Relationships (Level A)
What this criterion requires: Use semantic HTML (headings, lists, tables, form labels, landmarks) so structure and relationships in the visual layout are programmatically determinable.
Reference: https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships
axe-core rule: list (impact: serious)
Rule explanation: <ul> and <ol> must only directly contain <li>, <script>, or <template> elements
Full rule docs: https://dequeuniversity.com/rules/axe/4.10/list?application=axeAPI
Offending HTML element:
<ul class="quick-links"><div class="ql-section">Pay & Apply</div><a href="/pay-tax">Pay tax</a><a href="/permits">Permits</a></ul>
CSS selector that targets this element:
.quick-links
Please:
1. Show me the corrected HTML or CSS in granicus.
2. Explain what changed and why this fixes the WCAG violation.
3. Tell me how to verify the fix worked, including any screen reader behavior I should expect.
Form fields have visible labels or clear instructions describing the expected input.
Who is affected when this fails
All users, but especially cognitive disability and screen reader users, need a visible label or clear instruction on each form field to know what to type. Placeholder-only forms fail this.
Issue: Form elements must have labels
Critical axe-core rule label, found on 1 element across this run.
How to fix
Wrap the input in a <label> element, or use a separate <label> with a for attribute matching the input's id. Avoid relying on placeholder text as the only label.
<input type="text" id="q" name="q" placeholder="Search the site">
Show copy-paste prompt for Claude or ChatGPT
Every value below is pre-filled from your audit. Paste this entire block into Claude or ChatGPT and the AI will respond with corrected code.
I have a WCAG 2.1 Level A accessibility violation on my website. Please give me corrected code.
Page URL: https://townofbrackmoor.gov/
My website is built on: granicus
WCAG criterion: 3.3.2 Labels or Instructions (Level A)
What this criterion requires: Form fields have visible labels or clear instructions describing the expected input.
Reference: https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions
axe-core rule: label (impact: critical)
Rule explanation: Form elements must have labels
Full rule docs: https://dequeuniversity.com/rules/axe/4.10/label?application=axeAPI
Offending HTML element:
<input type="text" id="q" name="q" placeholder="Search the site">
CSS selector that targets this element:
form.search-form > input#q
Please:
1. Show me the corrected HTML or CSS in granicus.
2. Explain what changed and why this fixes the WCAG violation.
3. Tell me how to verify the fix worked, including any screen reader behavior I should expect.
The default human language of the page is declared programmatically, for example with the html lang attribute, so screen readers use correct pronunciation.
Who is affected when this fails
Screen readers use the page language to choose pronunciation rules; English vowels sound different than Spanish vowels. Without a declared language, the reader uses the user's default and mispronounces words. Translation tools also rely on the declared language.
Issue: <html> element must have a lang attribute
Serious axe-core rule html-has-lang, found on 1 element across this run.
How to fix
Add a lang attribute to your <html> element with the appropriate ISO 639-1 language code (en for English, es for Spanish, fr for French, etc).
Examples:
<html lang="en">
<html lang="en-US">
<html lang="es">
How to verify
View the page source and confirm the <html> tag has a lang attribute. A screen reader on the page should pronounce content in the declared language.
Every value below is pre-filled from your audit. Paste this entire block into Claude or ChatGPT and the AI will respond with corrected code.
I have a WCAG 2.1 Level A accessibility violation on my website. Please give me corrected code.
Page URL: https://townofbrackmoor.gov/
My website is built on: granicus
WCAG criterion: 3.1.1 Language of Page (Level A)
What this criterion requires: The default human language of the page is declared programmatically, for example with the html lang attribute, so screen readers use correct pronunciation.
Reference: https://www.w3.org/WAI/WCAG21/Understanding/language-of-page
axe-core rule: html-has-lang (impact: serious)
Rule explanation: <html> element must have a lang attribute
Full rule docs: https://dequeuniversity.com/rules/axe/4.10/html-has-lang?application=axeAPI
Offending HTML element:
<html>
CSS selector that targets this element:
html
Please:
1. Show me the corrected HTML or CSS in granicus.
2. Explain what changed and why this fixes the WCAG violation.
3. Tell me how to verify the fix worked, including any screen reader behavior I should expect.
Criticalimage-alt: Images must have alternative text (3 elements)
Criticalbutton-name: Buttons must have discernible text (2 elements)
Criticallabel: Form elements must have labels (1 element)
Seriouscolor-contrast: Elements must meet minimum color contrast ratio thresholds (10 elements)
Seriouslink-name: Links must have discernible text (5 elements)
Seriousaria-hidden-focus: ARIA hidden element must not be focusable or contain focusable elements (3 elements)
Seriousaria-allowed-attr: Elements must only use permitted ARIA attributes (2 elements)
Serioushtml-has-lang: <html> element must have a lang attribute (1 element)
Seriouslist: <ul> and <ol> must only directly contain <li>, <script>, or <template> elements (1 element)
Seriousnested-interactive: Interactive controls must not be nested (2 elements)
Methodology and limits
This audit uses the open-source axe-core 4.10.2 engine in a real headless Chromium browser, configured to test only WCAG 2.1 Level A and Level AA success criteria. Automated scanning catches roughly 30 to 40 percent of WCAG issues. The remaining issues require manual review.
For full WCAG conformance, also do the following manual checks:
Tab through every page using only the keyboard. Confirm every interactive element is reachable, and that focus is always visible.
Listen to every page with a screen reader (VoiceOver on macOS or iOS, NVDA or JAWS on Windows). Confirm announcements are meaningful.
Confirm every image and icon has meaningful alt text, or is correctly marked as decorative.
Confirm every form field has a visible label, not just placeholder text.
Resize text to 200 percent zoom and confirm no content is lost.
Use the WebAIM Contrast Checker on any color combination axe could not test programmatically.
Authoritative references the report links to throughout:
