Content author: MNIT Office of Accessibility

We perform quick high-level evaluations of websites or web applications for several reasons—for example, to confirm a product’s accessibility for a project manager or to help an agency gauge potential accessibility compliance issues. These evaluations are intended to:

• Quickly identify whether the site may present barriers for users with disabilities.
• Share findings in a clear, approachable way with those who may not be familiar with digital accessibility, like product managers or executives.

Note: A high-level evaluation is not a substitute for an accessibility audit. 

Completing the high-level evaluation document

Document everything you do during the evaluation, including the testing tools used, the accessibility standards assessed, and the specific locations where testing occurred (such as web page URLs, mobile app steps, or document names).

Format the final report of this review data for the intended audience (who you are reporting to). You want them to understand: 

• Whether the site is likely to present barriers for users with disabilities.
• What that means in terms of risk (exposure) and remediation (cost). 

Here is our high-level test reporting template. Note: We begin at a heading level 1, as it would be set in a Microsoft Word document.

• Download the /mnit/assets/High-Level%20Accessibility%20Testing%20Report%20of%20Findings%20TEMPLATE_tcm38-694319.docxHigh-level Accessibility Testing Report of Findings Word template

[Product/Software Name]: High-Level Accessibility Testing Cases – Report of Findings

This report outlines a quick accessibility audit (approximately 1-2 hours) of the [name of website, web pages, mobile app or software]. This is not an in-depth accessibility test or audit, or review of usability issues. This report outlines basic findings only.

Accessibility standards we test for:

• WCAG 2.1, Level AA
• Federal rule: Section 508

Testing tools used:

[Examples:

• Desktop:
• Browser (name) and Browser Zoom
• Keyboard
• Accessibility testing bookmarklet:
• Color Contrast tool: ]

Rating system for issues found

Use the following rating system to communicate impact of issues found:

• Barrier: Cannot accomplish tasks due to insurmountable showstoppers.
• Great challenges: Can accomplish task only with a high level of additional effort, training, and/or workarounds.
• Some challenges: Can accomplish task only with a moderate amount of additional effort, training, and/or workarounds.
• Pass: Can accomplish tasks with same or reasonable level of effort as other users.

Overall review note/summary of findings

Provide an overall review. Include what is working and meets standards, as well as any barriers that were discovered and which should be addressed first. 

Findings

Collect findings based on ratings.

Accessibility findings: Showstoppers (high priority failures to address)

The audit revealed accessibility issues which will cause barriers to specific users, including [list user types, like screen reader users, keyboard-only users, voice-to-text users]. Disabilities affected will be [list based off user types, like blind, low vision, color contrast, cognitive and mobility]. This means these users will not be able to complete specific tasks on your website/mobile application.

Test case: 

Overview: 

Challenge: 

WCAG and/or Section 508 failure(s):

Recommendation:

Testing tool(s):

• [list]

Steps to perform testing:

• [steps]

Accessibility findings: Great Challenges (medium priority partial failures to address)

In this audit, we have some test cases that cause great challenges for specific users [list] and disabilities affected include [list]. This means users should be able to complete tasks on your website/mobile application but with a high level of difficulty or inconvenience.

[Use the same test case list from Barriers, as appropriate].

Accessibility findings: Some Challenges (low priority partial failures to address)

In this audit, we have some test cases that cause some challenges for specific users [list] and disabilities affected include [list]. This means users should be able to complete tasks on your website/mobile application but with some difficulty or inconvenience.

[Use the same test case list from Barriers, as appropriate].

Test cases that Pass (examples for reference)

In this audit, we have examples of what is working well and should continue to be implemented in any future iterations of your website/mobile application.

[list].