How This Website Meets
WCAG AA Requirements
WCAG 2.2/2.1 AA Compliance Documentation
Last Updated: July, 2025
Purpose
This document provides comprehensive evidence of WCAG 2.1 Level AA conformance. All testing was performed by IAAP-certified professionals using industry-standard tools and manual verification methods.
Testing Methodology
- Automated Tools: axe DevTools, WAVE, ARC Toolkit
- Screen Readers: NVDA (Windows), VoiceOver (Mac/iOS), TalkBack (Android)
- Manual Testing: Keyboard-only navigation, color contrast analysis, browser zoom testing
- Devices: Desktop, tablet, and mobile testing across multiple browsers
| Feature/Element | WCAG Criteria | Testing Method | Status | Notes |
|---|---|---|---|---|
| PRINCIPLE 1: PERCEIVABLE | ||||
| Informative Images | 1.1.1 Non-text Content | Screen reader testing (NVDA, VoiceOver, TalkBack), code inspection | Compliant | Informative images include descriptive alt text. Maps and complex images include text alternatives or contact information for clarification. |
| Decorative Images & Icons | 1.1.1 Non-text Content | Screen reader testing, code inspection | Compliant | Decorative images and icons use aria-hidden="true" or alt="" to prevent redundant announcements. |
| Semantic HTML Structure | 1.3.1 Info and Relationships | Code inspection, screen reader testing, axe DevTools | Compliant | Proper semantic HTML5 elements (<nav>, <main>, <footer>, <article>) define page structure. |
| Lists (Ordered & Unordered) | 1.3.1 Info and Relationships | Screen reader testing (NVDA, VoiceOver, TalkBack) | Compliant | Proper <ul>, <ol>, and <li> markup. Screen readers announce “list with X items.” |
| Data Tables | 1.3.1 Info and Relationships | axe DevTools, screen reader testing, code inspection | Compliant | Tables include proper <th> headers with scope attributes. Screen readers announce row/column relationships. |
| Form Labels | 1.3.1 Info and Relationships | Screen reader testing, axe DevTools | Compliant | All form fields have visible labels programmatically associated using <label for=""> or aria-labelledby. |
| Heading Hierarchy | 1.3.1 Info and Relationships | WAVE, axe DevTools, screen reader testing | Compliant | Logical heading structure (H1 → H2 → H3) throughout site. Screen reader users can navigate by heading level. |
| Grouped Content (Buttons, Cards) | 1.3.1 Info and Relationships | Screen reader testing (NVDA, VoiceOver, TalkBack) | Compliant | Related items use role="list" or semantic grouping. Screen readers announce group context. |
| ARIA Landmarks | 1.3.1 Info and Relationships | Screen reader testing, code inspection | Compliant | ARIA landmarks (role="navigation", role="main", etc.) define page regions for screen reader navigation. |
| Tab Panels Association | 1.3.1 Info and Relationships | Screen reader testing, code inspection | Compliant | Tab controls are programmatically linked to their content panels using aria-controls and aria-labelledby. |
| Reading Order | 1.3.2 Meaningful Sequence | Screen reader testing, keyboard navigation | Compliant | Content flows logically from top to bottom. Responsive design maintains meaningful sequence on all devices. |
| Form Input Purpose | 1.3.5 Identify Input Purpose | Code inspection, browser autofill testing | Compliant | Form fields use appropriate autocomplete attributes (e.g., given-name, email, tel). |
| Use of Color | 1.4.1 Use of Color | Visual inspection, manual testing | Compliant | Information is not conveyed by color alone. Tabs use icons + color, links use underlines, required fields use asterisks + ARIA. |
| Text Contrast | 1.4.3 Contrast (Minimum) | Colour Contrast Analyzer, WAVE | Compliant | All text meets 4.5:1 contrast ratio (7:1 for large text). Page titles use solid background overlays to ensure contrast. |
| Text Resize | 1.4.4 Resize Text | Browser zoom to 200% | Compliant | Text can be resized to 200% without loss of content or functionality. No horizontal scrolling required. |
| Reflow | 1.4.10 Reflow | Browser zoom to 400%, mobile device testing (iOS, Android) | Compliant | Content reflows to single column at 320px width without horizontal scrolling. Responsive design adapts to all screen sizes. |
| Non-text Contrast (Icons, Buttons) | 1.4.11 Non-text Contrast | Colour Contrast Analyzer, visual inspection | Compliant | Interactive elements and focus indicators meet 3:1 contrast ratio against background. |
| Text Spacing | 1.4.12 Text Spacing | Browser bookmarklet, custom CSS testing | Compliant | Content adapts when users apply custom text spacing (line height, letter spacing, word spacing) without loss of functionality. |
| PRINCIPLE 2: OPERABLE | ||||
| Keyboard Navigation | 2.1.1 Keyboard | Manual keyboard-only testing (Tab, Shift+Tab, Enter, Space, Arrow keys) | Compliant | All interactive elements (links, buttons, forms, menus) are fully keyboard accessible. No mouse required. |
| No Keyboard Trap | 2.1.2 No Keyboard Trap | Manual keyboard navigation testing | Compliant | Users can navigate into and out of all interactive components using standard keyboard commands. Menus allow Escape to close. |
| Skip to Content Link | 2.4.1 Bypass Blocks | Manual keyboard testing (Tab key) | Compliant | Skip link appears on first Tab press on every page, allowing users to bypass repetitive navigation. |
| Page Titles | 2.4.2 Page Titled | Code inspection, screen reader testing | Compliant | Every page has a unique, descriptive <title> tag that identifies the page topic. |
| Focus Order | 2.4.3 Focus Order | Manual keyboard testing, visual inspection | Compliant | Keyboard focus follows logical visual order (top to bottom, left to right). Tab order is predictable and meaningful. |
| Link Purpose | 2.4.4 Link Purpose (In Context) | Screen reader testing, code inspection | Compliant | All links have descriptive text or hidden aria-labels. “Read More” links include hidden descriptive context. |
| Multiple Ways to Navigate | 2.4.5 Multiple Ways | Manual site exploration | Compliant | Users can navigate via main menu, footer links, search (if enabled), and sitemap. |
| Headings and Labels | 2.4.6 Headings and Labels | WAVE, screen reader testing | Compliant | Headings and form labels are descriptive and clearly identify their purpose. No vague labels like “Click here.” |
| Focus Visible | 2.4.7 Focus Visible | Manual keyboard testing, visual inspection | Compliant | Clear, high-contrast focus indicators on all interactive elements. Focus is always visible during keyboard navigation. |
| Pointer Gestures | 2.5.1 Pointer Gestures | Mobile device testing (iOS, Android) | Compliant | All functionality works with single-pointer actions (tap, click). No complex gestures (pinch, swipe with multiple fingers) required. |
| Pointer Cancellation | 2.5.2 Pointer Cancellation | Manual testing (mouse, touch) | Compliant | Click/tap actions complete on “up” event, allowing users to cancel by moving pointer away before release. |
| Label in Name | 2.5.3 Label in Name | Code inspection, voice control testing | Compliant | Accessible names match or include visible text labels, supporting voice control users. |
| Motion Actuation | 2.5.4 Motion Actuation | Manual testing | Compliant | No functionality relies on device motion or user gestures. All features have interface-based alternatives. |
| Target Size (Enhanced) | 2.5.5 Target Size (Level AAA – Exceeds Requirements) | Visual inspection, mobile testing | Compliant | Touch targets meet minimum 44×44 pixels. Most exceed this for better usability. |
| PRINCIPLE 3: UNDERSTANDABLE | ||||
| Language of Page | 3.1.1 Language of Page | Code inspection | Compliant | HTML lang attribute set to “en” on all pages. |
| Language of Parts | 3.1.2 Language of Parts | Code inspection (if applicable) | Compliant | Content in other languages is marked with appropriate lang attribute (e.g., lang="es"). |
| On Focus | 3.2.1 On Focus | Manual keyboard testing | Compliant | Receiving focus does not automatically trigger context changes. Users must explicitly activate controls. |
| On Input | 3.2.2 On Input | Manual form testing | Compliant | Form inputs do not automatically submit or change context when values change. Users must explicitly submit. |
| Consistent Navigation | 3.2.3 Consistent Navigation | Multi-page inspection | Compliant | Navigation menus appear in same location and order across all pages. |
| Consistent Identification | 3.2.4 Consistent Identification | Multi-page inspection | Compliant | Components with same functionality use consistent labels and icons throughout site. |
| Error Identification | 3.3.1 Error Identification | Manual form testing, screen reader testing | Compliant | Form validation errors are clearly identified with descriptive text next to the problematic field. |
| Labels or Instructions | 3.3.2 Labels or Instructions | Visual inspection, screen reader testing | Compliant | All form fields have clear labels. Required fields marked with asterisk and aria-required. |
| Error Suggestion | 3.3.3 Error Suggestion | Manual form testing | Compliant | Error messages provide specific guidance on how to correct input (e.g., “Please enter a valid email address”). |
| Error Prevention (Legal, Financial, Data) | 3.3.4 Error Prevention | Manual form testing | Compliant | Forms can be reviewed before submission. Contact forms provide confirmation before sending. |
| PRINCIPLE 4: ROBUST | ||||
| Parsing (HTML Validity) | 4.1.1 Parsing | W3C HTML Validator, axe DevTools | Compliant | HTML is well-formed with no duplicate IDs or invalid nesting. Validated against W3C standards. |
| Name, Role, Value | 4.1.2 Name, Role, Value | Screen reader testing, axe DevTools, code inspection | Compliant | All custom controls use appropriate ARIA attributes. States (expanded, selected, checked) are programmatically exposed. |
| Status Messages | 4.1.3 Status Messages | Screen reader testing, code inspection | Compliant | Dynamic status messages use role="status" or aria-live to announce updates without moving focus. |
| ADDITIONAL BEST PRACTICES & ENHANCEMENTS | ||||
| PDF Accessibility | Best Practice | Adobe Acrobat accessibility checker | Compliant | Template includes guidance for PDF remediation. Districts responsible for ensuring uploaded PDFs are tagged with proper structure. |
| Spam Protection | Best Practice | Manual form testing | Compliant | Honeypot spam filtering instead of CAPTCHA eliminates accessibility barriers while preventing spam. |
| Media Controls | Best Practice | Manual testing | Compliant | Slideshows, videos, animations have visible play/pause controls. Auto-playing content can be stopped. |
| Form Enhancements (Planned) | Enhancement | In development | Planned | Future iteration will add aria-describedby for more detailed field instructions and form submission status announcements. |
Testing Tools Used
- axe DevTools: Automated WCAG testing browser extension
- WAVE: Web accessibility evaluation tool
- ARC Toolkit: Accessibility testing toolkit
- Colour Contrast Analyzer: Desktop application for contrast testing
- NVDA: Screen reader for Windows
- VoiceOver: Screen reader for Mac/iOS
- TalkBack: Screen reader for Android
Certification & Auditing
This website template has been reviewed and tested by IAAP-certified (International Association of Accessibility Professionals) accessibility specialists and validated by users with disabilities who rely on assistive technologies.
Questions about this compliance documentation? Contact All Terrain Studios at Hello@AllTerrainStudios.com or 303-335-0474.
| Element / Module | Relevant WCAG 2.2 AA Criteria | Method of Verification | Status | Notes/Explanation |
|---|---|---|---|---|
| Skip to Content | Manual keyboard testing (Tab + Shift, Tab) | ✅ Compliant | The first element to receive focus on every page is the “Skip to Content” button which is visible for keyboard-only, swipe/tapping users, and screen readers – required of all three for compliance. | |
| Navigation (Desktop & Mobile) and FAQ Accordions | 1.3.1 Info and Relationships 2.1.1 Keyboard 2.4.3 Focus Order 4.1.2 Name, Role, Value | Manual keyboard testing (Tab / Shift + Tab), screen reader navigation (NVDA & VoiceOver), axe DevTools | ✅ Compliant | All menu items reachable by keyboard (Tab, Tab + Shift, Enter/Space) and swiping/tapping; visible focus indicator maintained; ARIA roles applied to nested lists; expanded/collapsed states announced; proper number of list items announced across columns and containers. |
| Hero Section | 1.4.3 Contrast (Minimum) 1.4.11 Non-Text Contrast 2.4.6 Headings and Labels | Color-contrast analyzer, WAVE | ✅ Compliant | Headline & buttons meet ≥ 4.5:1 contrast ratio; logical heading structure (H1 → H2). |
| Recent News List | 1.3.1 Info and Relationships 2.4.4 Link Purpose (in Context) 2.4.3 Focus Order | Screen reader output (NVDA, VoiceOver), keyboard navigation, axe DevTools | ✅ Compliant | News items announced as “list of XYZ items.” “Read More” links use hidden aria-labels for descriptive destinations. |
| Footer Contact Info | 1.3.1 Info and Relationships 1.4.3 Contrast (Minimum) | Visual inspection, contrast check tool | ✅ Compliant | Address, phone, and email presented semantically; high-contrast text on dark background. |
| Color Palette / Typography | 1.4.3 Contrast (Minimum) 1.4.4 Resize Text 1.4.10 Reflow | Browser zoom (200%), contrast testing, responsive check | ✅ Compliant | Text resizes without loss of content or function; mobile layout preserves readability. |
| Buttons | 2.4.7 Focus Visible 1.4.11 Non-Text | Keyboard navigation, manual focus test, WAVE | ✅ Compliant | Focus ring meets contrast standards; button states (hover/focus/active) distinct visually and programmatically. |
| Forms | 3.3.1 Error Identification 3.3.2 Labels or Instructions 2.1.1 Keyboard | Manual entry tests, screen reader form mode (Virtual Cursor off) | 🟡 Compliant with Minor Enhancement | Each field labeled; error messages announced. Next iteration to add aria-describedby for field-specific guidance and form submitting status announced. |
| Images & Icons | 1.1.1 Non-Text Content 1.4.11 Non-Text Contrast | Code inspection, screen reader test | ✅ Compliant | Informative images that add context to the page have alt text; decorative images and icons have aria-hidden="true". |
| Alerts / Status Messages | 4.1.3 Status Messages | Code inspection, screen reader output | ✅ Compliant | Live regions (role="status") used for non-modal alerts; screen readers announce updates without focus loss. |
| Autoplay controls | Manual keyboard testing | ✅ Compliant | Slideshows, videos, animations, and carousels have Play/Pause buttons | |
| High Contrast Text | 1.4.3 Contrast Minimum | WAVE | ✅ Compliant | All text meets a 4.5:1 contrast ratio against backgrounds, ensuring readability for users with low vision. All page titles use a solid color background overlay behind the text (not directly on the photo), ensuring the text maintains proper 4.5:1 contrast ratio and remains readable for users with low vision. |
| Full Keyboard Access | 2.1.1 Keyboard | Manual keyboard testing | ✅ Compliant | Every interactive element like buttons, links, forms, and menus works perfectly with keyboard-only navigation. No mouse required. |
| Visible Focus Indicators | 2.4.7 Focus Visible | Manual keyboard testing | ✅ Compliant | Clear visual outlines show exactly where keyboard focus is at all times eliminating guessing which element is active. |
| Touch Target Size | 2.5.5 Target Size – Level AAA, but good practice | WAVE? ARC? | ✅ Compliant | All mobile menu items are at least 44×44 pixels—easy to tap without accidentally hitting the wrong button. |
| Tabs contain Visual Indicators Beyond Color | 1.4.1 Use of Color | Visual confirmation | ✅ Compliant | selected tabs are identified by an icon AND color ensuring users who can’t perceive color differences can still navigate effectively. Choose from 200+ icons to match your brand. |
| Tab Keyboard Navigation | 2.1.1 Keyboard | Manual keyboard testing | ✅ Compliant | navigate tabs using arrow keys, activate with Enter or Space which is standard keyboard behavior that assistive technology users expect. |
| Tab Focus Management | 2.4.3 Focus Order, 2.4.7 Focus Visible | Visual Confirmation | ✅ Compliant | clear focus indicators show exactly which tab is active, and focus moves logically through content. |
| Screen Reader Support for Tabs | 4.1.2 Name, Role, Value | NVDA on PC, VoiceOver Mac/iOS, Talkback Android | ✅ Compliant | proper ARIA attributes tell screen readers which tab is selected, how many tabs exist, and what content each tab controls. |
| Tabs Semantic Structure | 1.3.1 Info and Relationships | Manual keyboard testing | ✅ Compliant | tabs are programmatically associated with their content panels, maintaining relationships that assistive technology can interpret. |
| Accessible Data Tables | 1.3.1 Info and Relationships | axe DevTools, Visual Code Inspection | ✅ Compliant | tables include proper <th> headers and scope attributes, so screen readers can announce “Row 2, Column 3: Transfer of Title Fee” instead of just reading numbers randomly. |
| Grouped Content | 1.3.1 Info and Relationships | NVDA on PC, VoiceOver Mac/iOS, Talkback Android | ✅ Compliant | Similar items are visually grouped with consistent styling and spacing, but don’t rely solely on position – semantic markup ensures assistive technology understands the relationship. For example, screen readers announce “list with 2 items” before reading the remaining content. |
| Structured Lists | 1.3.1 Info and Relationships | NVDA on PC, VoiceOver Mac/iOS, Talkback Android | ✅ Compliant | proper <ul> and <li> markup tells screen readers “list with X items,” helping users understand content structure before diving in. |
| No Duplicate Links | 2.4.4 Link Purpose | NVDA on PC, VoiceOver Mac/iOS, Talkback Android | ✅ Compliant | For posts, only the “Read More” button is clickable which avoid the common mistake of making titles, images, AND buttons all link to the same place. Duplicate link error. |
| Text Alternative for Complex Images like Maps | 1.1.1 Non-text Content | NVDA on PC, VoiceOver Mac/iOS, Talkback Android | ✅ Compliant | for maps with detailed information, we recommend including a text description or contact information below the image so residents can confirm service availability by phone, email, or address lookup. |
| Keyboard-Accessible Interactive Maps | 2.1.1 Keyboard | Manual keyboard testing | ✅ Compliant | when using ArcGIS integration, all map controls (zoom, pan, layer toggles) are fully keyboard accessible – no mouse required. |
| Color Contrast in Maps and Images with Text | 1.4.3 Contrast Minimum | Visual inspection with Colour Contrast Analyzer | ✅ Compliant | service area boundaries and labels use high-contrast colors that remain visible for users with low vision or color blindness. |
| Responsive Grid Layout | 1.4.10 Reflow | iOS and Android | ✅ Compliant | board member cards automatically reflow from multi-column to single-column on smaller screens—no pinching, zooming, or horizontal scrolling required on mobile devices. |
| Contact Information Accessibility | 1.4.4 Resize Text | Browser zoom, visual inspection | ✅ Compliant | email addresses and phone numbers remain readable and functional even when users zoom to 200% or apply text spacing so no horizontal scrolling or cut-off text. |
| Clickable Contact Links | 2.1.1 Keyboard | ✅ Compliant | email addresses are proper mailto: links and phone numbers use tel: links, making them one-click accessible on mobile devices and compatible with assistive technology. | |
| Adequate Touch Targets | 2.5.5 Target Size | ✅ Compliant | each link meets the minimum 24×24 pixel target size (we exceed this for better usability), making them easy to tap on mobile devices without accidentally clicking the wrong document. | |
| PDF Accessibility Notice | WCAG Best Practice | ✅ Compliant | PDFs trigger accessibility warnings in automated tools like WAVE, so it’s important to ensure all uploaded documents are properly remediated with tagged structure, alt text for images, and readable text (not scanned images). All PDFs must be accessibility-checked before upload as this system does not automatically remediate your PDFs. | |
| Logical Reading Order | 1.3.2 Meaningful Sequence | ✅ Compliant | unlike visual timelines that jump left-right-left, this timeline flows in natural reading order ensuring screen readers, keyboard users, and mobile users all experience your history in chronological sequence. | |
| Clear Structure | 1.3.1 Info and Relationships | ✅ Compliant | each milestone includes a bold year marker and descriptive heading, making it easy to scan visually or navigate with assistive technology. | |
| Organized with Proper Headings | 2.4.6 Headings and Labels | ✅ Compliant | uses H1 for the page title, H2 for major sections, and H3 etc creating a clear hierarchy that helps everyone navigate, especially screen reader users who use the H key to jump between headings | |
| Clear Expand/Collapse Indicators | 1.3.1 Info and Relationships, 4.1.2 Name, Role, Value | ✅ Compliant | screen readers announce whether each question is “expanded” or “collapsed” using proper ARIA states (aria-expanded="true" or "false"), so users always know which answers are currently visible without needing to see the screen. | |
| Clear Form Labels | 1.3.1 Info and Relationships, 3.3.2 Labels or Instructions | ✅ Compliant | every form field has a visible, descriptive label (“First Name,” “Last Name,” “Email,” “Comment or Message”) that’s programmatically associated with its input field. Screen readers announce the label when users navigate to each field, ensuring everyone knows what information to provide. | |
| Required Field Indicators | 3.3.2 Labels or Instructions | ✅ Compliant | required fields are marked with an asterisk (*) and include aria-required="true" attributes, so screen readers announce “First Name, required” when users enter the field. | |
| Error Prevention and Recovery | 3.3.1 Error Identification, 3.3.3 Error Suggestion | ✅ Compliant | if a required field is left blank or email format is invalid, clear error messages appear next to the specific field with actionable guidance, for example, “Email is required” or “Please enter a valid email address” which makes it easy to identify and correct mistakes. | |
| Spam Protection Without Barriers | WCAG Best Practice | ✅ Compliant | this form uses a honeypot spam filter instead of CAPTCHA, eliminating accessibility barriers that visual puzzles and audio challenges create for users with disabilities. Legitimate users never encounter verification steps – they just fill out and submit. | |
| Mobile-Friendly Form Fields | 1.4.10 Reflow, 2.5.5 Target Size | ✅ Compliant | form fields and the submit button are large enough for easy tapping on mobile devices (meeting minimum 24×24 pixel touch targets), and the form automatically adjusts to smaller screens without horizontal scrolling. | |
Input Purpose Identification | 1.3.5 Identify Input Purpose | ✅ Compliant | form fields use proper autocomplete attributes (e.g., autocomplete="given-name", autocomplete="email"), allowing browsers and assistive technology to auto-fill information accurately, saving time and reducing errors. |