About Accessibility Reviews

The Stanford Office of Digital Accessibility will conduct a review of a requested product and determine whether it is mostly accessible, will limit access, or presents a barrier for an individual with a disability.

We provide an overall summary with user impacts plus the full list of the accessibility issues and recommendations in spreadsheet format.

Next Steps for Recipients

At a minimum, all Blocker, Critical, and Serious accessibility issues are expected to be resolved or have a timeline for resolution.

If the product/application is not already in production, these must be resolved before production release.
If the product/application is already in production, these must be prioritized for resolution as soon as possible.

The Office of Digital Accessibility team is available to answer questions and provide guidance regarding the issues documented in the spreadsheet. We offer a weekly Accessibility office hour on Tuesdays, at 11am-12pm (PST), or we can arrange another time to meet.

Evaluation Scope

We determine a representative sample of pages/components from the product rather than testing every page. When reporting issues, only a limited number of each violation are noted. Developers should take the information provided in the report and apply it across all pages of the website or application.

Evaluation Methodology

Assessments are based on the Web Content Accessibility Guidelines 2.2, Level A and AA standards and functional evaluation, which involves:

Reviewing a limited set of product pages/functionality to find the most important issues that need fixing
Emphasizing functional accessibility for an individual using assistive technology instead of full WCAG conformance

Our testing methodology includes the use of automated tools and manual testing techniques, which include, but are not necessarily limited to:

Automated scan with Axe DevTools and other plugins and tools
Use of the keyboard alone for navigation and interaction
Evaluation of color contrast and usage of color
Browser zoom to see how the product supports low vision users (for mobile apps we use platform-level text size)
Content review to assess semantic structure such as headings, lists, and tables
Video/audio review for captions, audio description, and transcripts
Session/timeout functionality
Identifying flashing content or animation
Navigation and interaction with a screen reader (JAWS and/or NVDA on Windows, VoiceOver on Mac and iOS, and TalkBack on Android - depending on the application being tested)
Ad-hoc code inspection in the browser developer tools for web-based products

Impact Rankings for Issues

The spreadsheet of issues includes impact rankings. These impact levels indicate the extent by which an issue impacts an individual when attempting to engage and interact with the website to accomplish a task. At a minimum, all Blocker, Critical, and Serious accessibility issues are expected to be resolved or have a timeline for resolution before implementation.

Blocker: issues that have very significant obstacles for people with disabilities. Users who depend on assistive technology are prevented from using the core content. Blocker impact issues should be addressed with the utmost priority as they prevent key experiences on core functionality from being completed.
Critical: issues that have significant obstacles for people with disabilities. Users who depend on assistive technology can get frustrated while trying to access the content. This results in the issue preventing the website from being used successfully.
Serious: issues that result in some barriers for individuals with disabilities but would not prevent them from accessing fundamental elements or content. Serious impact issues are those issues where users with disabilities encounter some obstacles as a result of this problem, but it does not prevent them from accessing fundamental components or content.
Moderate: issues that result in lesser impact on users than serious issues. While your end-user may appreciate a fix or patch, it won't necessarily impact their ability to use or interact with the website.
Minor: issues that are like bugs that are difficult to replicate or occur intermittently, or are enhancements to improve accessibility that do not map directly to WCAG standards. You can consider fixing these issues if you find a low-risk solution.

An issue that is ranked lower in severity does not mean that it can be ignored. All issues listed in the report will require the attention of the product owner to resolve. The product owner should weigh the severity of an issue with other factors in order to decide on the priority for fixing an issue. Such factors may include the number of pages to correct, frequency of occurrence on a single page, alignment with the purpose of the website, or timeline to remediate.

Accessibility Options, Documentation and Limitations

Assessment findings may be influenced by any of the following, when applicable and when we are made aware of these details:

If there are specific settings that must be enabled for accessibility functionality
If an alternate access solution exists that temporarily alleviates the existing accessibility issues
If there are only specific parts of the website/application that are not accessible and those can be removed from use while being repaired