Website accessibility audit

Evaluating digital accessibility through manual testing
Accessibility audits play a vital role in identifying barriers that can exclude users with disabilities and affect overall usability. They combine technical testing with real-world evaluation, ensuring websites meet WCAG standards and provide equitable access for everyone.
As a volunteer with Colorado Discover Ability (CDA), I observed that the organization’s website — which serves a community of individuals with disabilities — had accessibility challenges that limited ease of use. I conducted a complete manual audit using the Trusted Tester v5.1.3 framework, supplemented with additional WCAG 2.2 AA and usability criteria, to document these barriers and demonstrate a structured accessibility evaluation process.
Project overview
Comprehensive accessibility audit of the Colorado Discover Ability (CDA) website using the DHS Trusted Tester v5.1.3 framework, expanded to include additional WCAG 2.2 AA and usability criteria.
Project duration: November 2025
The problem: As a nonprofit providing adaptive outdoor recreation programs, Colorado Discover Ability (CDA) serves a community that depends on accessible communication. Yet its website had never been formally tested for accessibility. A comprehensive audit was needed to uncover potential barriers, improve usability, and align the organization’s digital presence with its inclusive mission.
The goal: Identify accessibility and usability barriers through a detailed manual audit using the Trusted Tester v5.1.3 framework and supplementary WCAG 2.2 AA criteria. Document findings clearly and provide a strong foundation for future remediation work.
My role: Accessibility auditor and UX accessibility consultant
Responsibilities:
- Planned and scoped a complete manual audit following the DHS Trusted Tester v5.1.3 process
- Applied additional WCAG 2.2 AA and usability criteria beyond the Trusted Tester framework
- Manually tested pages using ANDI, AXE, keyboard navigation, and browser developer tools
- Documented test results and structured findings by success criterion for clarity and traceability
- Evaluated design, content, and technical implementation for both accessibility and usability impact
Trusted Tester criteria
The first table in this audit includes every test condition defined in the official DHS Trusted Tester v5.1.3 framework. This methodology provides a standardized, repeatable process for evaluating web content against WCAG 2.1 Level A and AA success criteria.
Organizations choose to follow the Trusted Tester process because it offers consistency, traceability, and defensible results—qualities that are especially important for government agencies, contractors, and organizations seeking to demonstrate formal compliance.
As a Trusted Tester-certified accessibility professional, I applied each test to the Colorado Discover Ability website to evaluate technical conformance, usability, and overall accessibility. The results document whether each criterion was met, failed, or determined not applicable, along with detailed tester comments for context and traceability.
| Trusted Tester criteria | Test ID | Test condition | Result | Tester comment | Location | Global Issue | Screenshot |
|---|---|---|---|---|---|---|---|
| Alt-version-conformant | 1A | The identified version passes all applicable Test Conditions in this test process. | Does Not Apply | ||||
| Alt-version-equivalent | 1B | The identified version is up-to-date with the same information and functionality. | Does Not Apply | ||||
| Alt-version-access | 1C | The mechanism to reach the accessible equivalent version from the non-conforming page is accessible. | Does Not Apply | ||||
| Non-interference | 1D | Content in the non-conforming version(s) meets Conformance Requirement 5. | Does Not Apply | ||||
| 1.4.2-Audio-control | 2A | The user can pause, stop, or control the volume of audio content that plays automatically. | Does Not Apply | ||||
| 2.2.2-Blinking-moving-scrolling | 2B | The user can pause, stop, or hide moving, blinking, or scrolling content. | Fail | No visible pause button for moving content towards bottom of home page | Home page, after embedded facebook content. Location at screenshot | No | x |
| 2.2.2-Auto-updating | 2C | The user can pause, stop, hide, or control the frequency of automatically updating content. | Does Not Apply | ||||
| 4.1.2-Change-notify-auto | 2D | The page provides notification of each automatic update/change in content. | Does Not Apply | ||||
| 2.3.1-Flashing | 3A | If NO flashing content is found, then this Test Condition DOES NOT APPLY (DNA). If flashing content IS found, then this test should be recorded as NOT TESTED. | Does Not Apply | ||||
| 2.1.1-Keyboard-access | 4A | All functionality can be accessed and executed using only the keyboard. | Pass | All functionality is operable using the keyboard alone; no mouse input is required. | Yes | ||
| 2.1.1-No-keystroke-timing | 4B | Individual keystrokes do not require specific timings for activation of functionality. | Pass | No timing-dependent keystrokes are required to activate or operate any functions. | Yes | ||
| 2.1.2-No-keyboard-trap | 4C | There is no keyboard trap. | Pass | Focus can move freely through all interactive elements and return to the browser chrome without trapping. | Yes | ||
| 2.4.7-Focus-visible | 4D | A visible indication of focus is provided when focus is on the interface component. | Pass | This is true for all parts of the website that are within the scope of this test. (This is not true for the facebook embed that is not included in the scope of this test) | Yes | ||
| 3.2.1-On-focus | 4E | When an interface component receives focus, it does not initiate an unexpected change of context. | Pass | There are no unexpected changes of context | Yes | ||
| 2.4.3-Focus-order-meaning | 4F | The focus order preserves the meaning and operability of the web page. | Pass | Focus order is logical and consistent with the visual layout, maintaining operability and context. | Yes | ||
| 3.3.2-Label-provided | 5A | Visual labels or instructions are provided for form elements. | Fail | Home page newsletter signup and Support page credit card form rely only on placeholder text; labels are missing. | Home page Support page credit card info | No | x |
| 2.4.6-Label-descriptive | 5B | Each visual form label is sufficiently descriptive. | Pass | All visual form labels are descriptive | Yes | ||
| 1.3.1-Programmatic-label | 5C | The combination of the accessible name, accessible description, and other programmatic associations (e.g., table column and/or row associations) describes each input field and includes all relevant instructions and cues (textual and graphical). | Does Not Apply | Forms on the Program, Volunteer, and Support pages are hosted externally (Little Green Light and DonorSnap) and cannot be tested due to cross-domain restrictions. Recommend verifying the accessibility of these vendor platforms or including an accessibility statement noting reliance on third-party systems. | Sublinks under Program, Volunteer and Support web pages | ||
| 3.2.2-On-input | 5D | Changing field values/selections (e.g., entering data in a text field, changing a radio button section) does NOT initiate and unexpected change of context. | Pass | There are no unexpected changes of context | Yes | ||
| 3.3.1-Error-identification | 5F | The item in error is identified in text and sufficiently described to the user in text. | Pass | When submitting with a blank/invalid required field, inline error text is announced/visible | Yes | ||
| 3.3.3-Error-suggestion | 5G | Guidance (e.g., suggestion for corrected input) is provided about how to correct errors for form fields. | Pass | On invalid input, message includes corrective guidance | Yes | ||
| 3.3.4-Error-prevention | 5H | The web page allows the user to check, reverse, and/or confirm submission. | Fail | No review/confirmation step or undo before final submission for monetary donation | Support page donation form | No | x |
| 2.4.4-Link-purpose | 6A | The purpose of each link can be determined from any combination of the link text, accessible name, accessible description, and/or programmatically determined link context. | Fail | Repeated links like ‘See more details’ lack unique purpose or programmatic name; add specific text or aria-label. Home page social media links (Facebook and Instagram) do not provide accessible names or sufficient programmatic context for screen reader users. | Home page Upcoming Events | No | x |
| 1.1.1-Meaningful-image-name | 7A | The accessible name and accessible description for a meaningful image provides an equivalent description of the image. | Fail | The home page “Thank you to our sponsors” image has no accessible text identifying the sponsors. Alt text for “Support CDA when you shop” is “Amazon Smile,” which is not meaningful. The home page “Partners and Friends” logos also lack accessible text. | Home page | Yes | x |
| 1.1.1-Decorative-image | 7B | There is no accessible name and accessible description for a decorative image. | Pass | Decorative images do not have accessible names and descriptions | Yes | ||
| 1.1.1-Decorative-background-image | 7C | The background image is not the only means used to convey important information. | Pass | Important information is not reliant on background images | Yes | ||
| 1.1.1-Captcha-alternative | 7D | Alternative forms of CAPTCHA are provided. | Does Not Apply | ||||
| 1.4.5-Image-of-text | 7E | The image of text cannot be replaced by text or is customizable. | Pass | The only images of text are logos which cannot be replaced by text, therefore this does not apply | |||
| 2.2.1-Timing-adjustable | 8A | The user can turn off, adjust, or extend the time limit. | Does Not Apply | After testing the forms for reasonable time limits, I did not find a time constraint | |||
| 2.4.1-Bypass-function | 9A | A keyboard-accessible method is provided to bypass repetitive content. | Pass | A skip link is provided to bypass main navigation items | Yes | ||
| 3.2.3-Consistent- navigation | 9B | Each navigational element occurs in the same relative order with regard to other repeated components on each web page where it appears. | Pass | Navigational items appear on each page in the same relative order | Yes | ||
| 3.2.4-Consistent-identification | 9C | The accessible name and description is consistent for components that perform the same function. | Pass | Components that are repeated are named and described consistently | Yes | ||
| 2.4.6-Heading-purpose | 10A | Each heading describes the topic or purpose of its content. | Pass | Headings are describing the topic of the content | Yes | ||
| 1.3.1-Heading-determinable | 10B | Each programmatically determinable heading is a visual heading and each visual heading is programmatically determinable. | Fail | Non-sectional content (e.g., descriptive text and short phrases) is programmatically marked as headings. This overuse of heading tags creates excessive, inaccurate structure in the accessibility tree, making it difficult for screen reader users to navigate or understand true page organization. | Global but screenshot example comes from footer | Yes | x |
| 1.3.1-Heading-level | 10C | Programmatic heading levels logically match the visual heading presentation within the heading structure. | Fail | Heading levels skip or repeat non-hierarchically (e.g., H1 used for multiple section titles). | Global issue, Screenshot example comes from home page. | Yes | x |
| 1.3.1-List-type | 10D | All visually apparent lists are programmatically identified according to their type. | Fail | Footer navigation lists are not programmatically identified as lists. | Footer list | No | x |
| 3.1.1-Page-language-defined | 11A | The default human language of each web page can be programmatically determined. | Pass | The default human language is set to En | Yes | ||
| 3.1.2-Part-language-defined | 11B | The human language for any content segment that differs from the default human language of the page can be programmatically determined. | Does Not Apply | Yes | |||
| 2.4.2-Page-title-defined | 12A | A title element is defined for the web page. | Pass | Each page has a defined title. | Yes | ||
| 2.4.2-Page-title-purpose | 12B | The title element identifies the contents or purpose of the web page. | Pass | Page titles accurately identify the content and purpose of each web page. | Yes | ||
| 4.1.2-Frame-title | 12C | Each has a title attribute that describes its content. | Fail | The Volunteer page has two iframes—an embedded YouTube video and a DonorSnap form—both missing title attributes. The Support page also includes a DonorSnap iframe with no title. | Volunteer and support pagges | Yes | x |
| 4.1.2-iFrame-name | 12D | The combination of accessible name and description for each | Fail | There is no accessible description for either iframe on the Volunteer page or for the iframe on the Support page. | Volunteer and Support pages | Yes | |
| 1.4.1-Color-meaning | 13A | Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. | Pass | Color is not the only way to convey information | Yes | ||
| 1.3.3-Sensory-info | 13B | Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components, such as shape, color, size, visual location, orientation, or sound. | Pass | There are no instructions that are solely relying on sensory characteristics | Yes | ||
| 1.4.3-Contrast | 13C | The visual presentation of text and images of text have sufficient contrast. | Fail | Home page newsletter signup placeholder text fails 4.5:1 contrast. Rotating gallery text placed over images drops below 4.5:1 in multiple frames. Footer text also fails 4.5:1 contrast. | Home page | Yes | x |
| 1.3.1-Table-identification | 14A | Each data table has programmatic markup to identify it as a table. | Does Not Apply | ||||
| 1.3.1-Cell-header-association | 14B | All data cells are programmatically associated with relevant headers. | Does Not Apply | ||||
| 1.3.1-Layout-table-structure | 14C | The layout table DOES NOT designate the layout table using ARIA role= ‘table’ AND DOES NOT include table header structure and relationship elements and/or associated attributes. | Does Not Apply | ||||
| 1.3.2-Content-order-meaning-css-position | 15A | The reading order of the content (in context) is correct and the meaning of the content (in context) is preserved without CSS positioning. | Pass | The reading order remains consistent | Yes | ||
| 1.2.1-Audio-transcript-text | 16A | A text-based alternative is provided for audio-only content that provides an accurate and complete representation of the audio-only content. | Does Not Apply | ||||
| 1.2.1-Video- alternative-equivalent | 16B | The video-only content information is also available through an equivalent text or audio alternative. | Does Not Apply | ||||
| 1.2.2-Captions-equivalent | 17A | The synchronized media provides accurate captions for the audio content. | Pass | Video on Volunteer page includes closed captioning | Volunteer page | No | |
| 1.2.5-Audio-description-equivalent | 17B | The synchronized media provides an equivalent soundtrack (combination of narration and audio descriptions) for the video content. | Pass | Volunteer video contains interviews only; all relevant visual information is conveyed through dialogue. | |||
| 1.2.4-Captions-live-equivalent | 17C | The live synchronized media provides accurate captions for the audio content. | Does Not Apply | ||||
| 503.4-Caption-controls | 17D | The media player provides user controls for closed captions. | Pass | Volunteer video provides user controls for closed captioning | Volunteer page | No | |
| 503.4-Description-controls | 17E | The media player provides user controls for audio descriptions. | Does Not Apply | No audio description track provided or required; player does not include an audio description toggle. | No | ||
| 503.4.1-Caption-control | 17F | User controls for captions are provided at the same menu level as the user controls for volume or program selection. | Pass | User controls for captions are provided at the same menu level as the user controls for volume or program selection. | No | ||
| 503.4.2-Description-control | 17G | User controls for audio descriptions are provided at the same menu level as the user controls for program selection or volume. | Does Not Apply | No audio description track provided or required; player does not include an audio description toggle. | No | ||
| 1.4.4-Resize-text | 18A | There is a mechanism to resize, scale, or zoom in on the text to at least 200% of its original size without loss of content or functionality. | Fail | Embedded third-party form in iframe does not enlarge/reflow; content remains fixed. | Program, Support, and Volunteer pages | Yes | |
| 2.4.5-Multiple-ways | 19A | There are two or more ways to locate a web page within a set of web pages. | Pass | Main navigation, footer navigation provide at least two ways to locate a single web page | Yes |
Additional WCAG criteria
While the Trusted Tester v5.1.3 framework covers all WCAG 2.1 Level A and AA success criteria, it does not yet include the new WCAG 2.2 criteria added in October 2023. To ensure a more complete and forward-looking evaluation, I incorporated these additional WCAG 2.2 Level AA tests into this audit.
These criteria address areas that improve real-world usability for keyboard and touch users, such as target size, focus visibility, and help consistency. Including them provides a broader assessment that reflects the most current accessibility standards and user expectations.
| Additional WCAG 2.2 AA criteria | Test ID | Test condition | Result | Tester comment | Location | Global issue | Screenshot |
|---|---|---|---|---|---|---|---|
| 1.4.11 Non-text contrast | 21W | Verify that visual information used to indicate controls, states, and graphical objects has a contrast ratio of at least 3:1 against adjacent colors. | Fail | Home page buttons on rotating gallery do not have sufficient contrast against background images | Home page rotating gallery | No | x |
| 1.4.12 Text spacing | 22W | Apply user overrides (line height 1.5× etc.) → no clipping or overlap. | Pass | No clipping or overlaps occurred with 1.5x text spacing | Yes | ||
| 1.4.13 Content on hover or focus | 23W | Ensure pop-ups/tooltips can be dismissed (Esc), stay visible while hovered, don’t obscure trigger. | Does Not Apply | ||||
| 2.4.11 + 2.4.12 Focus not obscured | 24W | Confirm visible focus is never blocked by sticky headers or overlays. | Does Not Apply | ||||
| 2.4.13 Focus appearance | 25W | Focus indicator ≥ 3 : 1 contrast and ≥ 2 CSS px thick. | Pass | The focus indicator meets the 2px thickness requirement but is dotted, which reduces visibility. Recommend changing it to a solid line. | Yes | x | |
| 2.5.7 Dragging movements | 26W | Dragging actions (sliders, sortables) have click / keyboard alternatives. | Does Not Apply | ||||
| 2.5.8 Target size (minimum) | 27W | Interactive targets ≥ 24 × 24 CSS px or spaced to equivalent. | Fail | “See more details” link on the home page and all footer navigation links are less than 24px tall. | Home page and footer | Yes | x |
| 3.2.6 Consistent help | 28W | Help options (contact, FAQ, chat) appear consistently across pages. | Pass | Contact number and email appear in footer | Yes | ||
| 3.3.7 Redundant entry | 29W | Previously entered data is retained or auto-filled; no duplicate entry required. | Pass | Foms do not ask for redundant information | Yes | ||
| 3.3.8 Accessible authentication | 30W | Authentication does not rely on visual or memory tests; accessible alternatives exist. | Does Not Apply |
Legal and compliance criteria
In addition to WCAG-based testing, this audit includes a brief review of legal and compliance elements commonly expected on public-facing websites. These items—such as privacy policies, terms and conditions, cookie consent, accessibility statements, and copyright notices—do not fall under WCAG but are often required by law or best practice.
Including these checks helps ensure the website meets broader compliance and transparency standards that affect user trust and organizational accountability.
| Legal criteria | Test ID | Test condition | Result | Tester comment | Location | Global issue | Screenshot |
|---|---|---|---|---|---|---|---|
| Privacy policy presence | 31L | Clearly labeled “Privacy Policy” link in footer; policy loads and is current. | Pass | Link to Privacy Policy PDF appears in footer | |||
| Terms & conditions presence | 32L | Link present and legible with clear ownership and user rights defined. | Fail | Absent | No | ||
| Cookie policy / Consent banner | 33L | Cookie notice appears on first visit; users can accept, decline, or manage preferences. | Fail | Absent | No | ||
| Accessibility statement | 34L | “Accessibility” link exists with contact method and last-updated date. | Fail | Absent | No | ||
| Copyright notice | 35L | Footer contains © + current year + organization name. | Fail | Absent | No |
Usability criteria
Many usability factors—such as navigation consistency, form clarity, link purpose, and color contrast—are already addressed within the accessibility criteria earlier in this audit. This section highlights a few remaining items that further support ease of use and readability for all users.
Including these additional checks helps identify broader opportunities to enhance user experience beyond strict accessibility compliance.
| Additional usability criteria | Test ID | Test condition | Result | Tester comment | Location | Global issue | Screenshot |
|---|---|---|---|---|---|---|---|
| Plain-language readability | U36 | Pass | Content is easily understood | Yes | |||
| Mobile Responsiveness | U37 | Pass | Content reflowed properly in portrait and landscape orientations. | Yes |
Screenshots
The following screenshots provide visual references for selected failed tests. Each image is labeled with its corresponding Test ID from the audit tables to illustrate the specific issue identified. These examples help clarify how accessibility barriers appear in practice and support understanding of the related test results.
Test ID: 2B

Test ID: 5A

Test ID: 5A

Test ID: 5H

Test ID: 6A

Test ID: 6A

Test ID: 7A

Test ID: 7A

Test ID: 7A

Test ID: 10B

Test ID: 10C

Test ID: 10D


Test ID: 12C

Test ID: 12C

Test ID: 13C




Test ID: 21W

Test ID: 25W

Test ID: 27W

Client-focused auditing
This audit demonstrates the value of a structured, manual accessibility evaluation using the Trusted Tester v5.1.3 framework expanded with WCAG 2.2 AA and usability criteria. In a client setting, the approach can be adapted to meet specific goals—whether conducting a full Trusted Tester assessment using the official SCRT reporting tool available to registered testers for federal or internal documentation, or providing collaborative remediation guidance alongside designers and developers.
This flexible approach ensures accessibility is not only compliant but also integrated into every stage of design and development.