Skip to content

Accessibility

Jump to bottom
Meckila edited this page May 20, 2021 · 11 revisions

Building an accessible Caseflow

Introduction

All government websites are required by Section 508 of the Rehabilitation Act to be accessible to people with disabilities. In our case, we are required to conform to the WCAG 2.0 AA standards.

This document is intended to be a minimal overview of Caseflow's approach to accessibility that links to (but doesn't replicate) existing resources, documentation, and learning.

WCAG 2.0 AA standard

The Web Content Accessibility Guidelines (WCAG, pronounced Wuh-kag) from the W3C outline the minimum standard websites should follow in order to ensure baseline accessibility. Conforming to these standards does not ensure that your website is fully accessible, or that it's easily used by people with disabilities. However, it creates a concrete framework for ensuring compliance.

We are required by Section 508 to follow version 2.0 (although there are more recent versions) at the AA level.

Accessibility defects severity scale

Severity Description
Critical This issue results in severe barriers for users with disabilities, either because content is blocked or functionality is inoperable. It causes global issues across the project because people with disabilities are unable to use it. This violation must be resolved before content/functionality can be considered fully compliant. Remediation should be a top priority.
High This issue results in significant barriers for individuals with disabilities. Some important content/functionality is not accessible. Users of Assistive Technology may not be able to access all content and/or functionality. Remediation should be a priority.
Medium This issue results in some barriers for individuals with disabilities but will not prevent them from accessing fundamental elements or content. This violation must be resolved before content/functionality can be considered fully compliant.
Low This issue causes minimal impact for users with disabilities. This may be a technical violation of the law but doesn’t make the content inaccessible. This content/functionality should be remediated in order to be considered fully compliant, but remediation can be given a low priority.

Automated and manual testing

Automated accessibility testing can catch up to 40 percent of problems on websites. See resources below:

In order to catch most errors, Caseflow team members need to perform two quick manual tests:

  1. Keyboard testing
  2. Screenreader testing

Manual Testing with Screenreaders

Although there are many screenreaders in existence, we are concerned mainly with two on Caseflow - JAWS and VoiceOver. JAWS is predominantly utilized on GFEs and is used to conduct 508 compliance audits. VoiceOver is the default screenreader for MacOS and therefore what the majority of developers on the project will utilize while developing. Below are links to guides detailing the keyboard commands for each:

Resources and support

  • VA's Section 508 Office resources
  • WCAG 2.0 AA documentation
  • WebAIM
  • JAWS testing support: If you have questions for how a component will be read in JAWS and you need help conducting the test yourself, you can submit a ServiceNow support ticket. Note – you cannot request training on JAWS through this process, but you'll be able to have JAWS experts walk you through using JAWS on your component. A good example of a request would be, "I’m trying to navigate this table in Caseflow with JAWS and I need help."

Learning

Inclusive design

General accessibility

React accessibility

JAWS

Additional a11y Resources

Clone this wiki locally