Accessibility

WCAG 2.1 AA, from the first wireframe.

The RFP requires WCAG 2.1 AA — screen-reader support, full keyboard access, 4.5:1 contrast, alt text, text resizing to 200%, and accessible forms. This prototype is built to that bar and re-tested with axe-core on every route.

170automated axe violations across 8 representative pages of the current City site (nrhtx.com)
0axe violations across this prototype's 15 routes
AAthe standard we design and test to: color, keyboard, forms, labels, and authoring

What we found

What the current-site issues mean for residents

Issue familyScaleResident impact
Lists that aren't real lists59 nodesSeveral pages expose list items outside proper lists, which can make menus and content groups confusing to screen-reader users.
Page sections a screen reader can skip to63 nodesRepeated or missing landmarks make it harder to jump between navigation, main content, sidebars, and footers.
Links that don't say where they go35 nodesSome links have no discernible text, so assistive technology cannot tell residents where the link goes.
Labels assistive technology relies on4 critical nodesCertain ARIA roles are missing required child roles. These are high-priority fixes because they can break expected keyboard or screen-reader behavior.
Data tables and heading order9 nodesA few pages have invalid table scope attributes or skipped heading levels, which affects page scanning and table interpretation.

How it stays fixed

Accessibility as a habit, not a one-time pass

DesignContrast, headings, tab order, focus states, and responsive text are checked before any visual is approved.
CMSImage fields require alt text, form labels are explicit, and the publish workflow includes an accessibility review step.
TestingAutomated axe-core scans, keyboard walkthroughs, VoiceOver and NVDA spot checks, and mobile overflow checks run before launch.
ReportingThe launch package includes the issue register, screenshots, remediation notes, and a public accessibility statement with a report-an-issue route.