Accessibility on VA.gov

Last Updated: October 16, 2024

This page is meant to help researchers, designers, and developers working within OCTO understand how VA approaches accessibility. It’s also a useful evolving resource for new (and existing) VA accessibility specialists in order to understand the context of their work.

This page contains guidelines, not mandates. 

Following these steps will help ensure your team launches products that meet VA’s vision:

"That every disabled Veteran and caregiver has guaranteed access to equitable, easy to use, self-service tools without needing to request accommodations."

• VA’s vision

Our Mission

VA is here to serve American Veterans, and approximately 40% of of them have an identified disability.

Our mission is to empower product teams to collaborate with disabled Veterans and caregivers by enhancing the culture and tools used to co-create and maintain services that are accessible beyond compliance. 

Our vision is for every disabled Veteran and caregiver to have guaranteed access to equitable, easy to use, self-service tools without needing to request accommodations.

Strategy and Standards

• Learn more about our accessibility strategy.

• Find out what experience standards a VA.gov product needs to meet before it launches.

  • Our standards are informed by the Web Content Accessibility Guidelines (WCAG).

  • Components in the VA Design System document accessibility considerations.

• The accessibility defect severity rubric is our common language for determining the seriousness of an accessibility issue.

We aim to:

• Follow inclusive design best practices in all of our work.

• Do more than pass a Section 508 audit. While we need to meet the official federal government accessibility baseline, we focus on usability, not just compliance.

• “Shift left," integrating accessibility practices across research, design, and development disciplines, starting as early in the product cycle as possible.

Accessibility Resources by Discipline

All of us are responsible for the accessibility of our products. And every discipline has a role:

Resources for Researchers

The best way to ensure that a product is accessible is to test it with users of assistive technology. Designing for complex needs first - like aging Veterans above the age of 55 or Veterans with disabilities - means designing for the future of all Veterans who age or acquire disabilities later in life. (Learn about inclusive research practices.)

Get help

The CAIA team can support your inclusive research sessions by:

• Reviewing your research plan

• Conducting a pilot session with a CAIA accessibility specialist (recommended) before running your research sessions to mitigate any potential accessibility-related issues.

• Providing technical support during sessions with assistive technology (AT) users

• Observing sessions with AT users from an accessibility point of view and providing findings

• Put in an AT Research Support Ticket with CAIA to get started.

Recruiting participants

• Use the MVS sampling method to recruit participants that use assistive technology

• Include mobile participants, or have a separate study for mobile usability testing

• Read more about inclusive recruitment strategies

Preparing prototypes for assistive technology users

• Review types of assistive technologies and how to modify your prototypes

• Consider creating your prototype in CodePen for the most accurate results

Research sessions

• Read VA's guide to research with assistive technology users

• Follow the screen reader checklist

• Learn how to be respectful of participants with disabilities

Resources for Designers

Creating visual designs with accessibility in mind will go a long way in making your end product accessible to all Veterans.

Apply accessibility best practices

When designing an interface, follow these best practices:

• Provide sufficient contrast between foreground and background

• Don’t use color alone to convey information

• Ensure that interactive elements are easy to identify

• Provide clear and consistent navigation options

• Ensure that form elements include clearly associated labels

• Provide easily identifiable feedback

• Use headings and spacing to group related content

• Create designs for different viewport sizes

• Include image and media alternatives in your design

• Provide controls for content that starts automatically

Use VA Design System components

Don't re-create the wheel! The VA Design System (VADS) is here to help. VADS Components are well-documented and have been reviewed for accessibility issues. Whenever possible, default to using an existing component or pattern in your designs.

• VA Design System components Figma library

Designing a form? Use VA's common form pattern templates (Figma).

Use accessibility annotations

A lot can be lost in translation when handing off your designs to a developer. Use accessibility annotations to make your intentions clear. It's especially important to annotate information that is semantically important, but not obvious on visual inspection:

• Heading levels (H1, H2, etc.)

• Anything that's using non-default styling (for example, an H3 that's styled to look like an H2)

• Text that's only accessible via assistive technology - alt text, aria-labels (for example, an "Edit" link with the aria-label "Edit address")

• Focus management between pages or screens

• Reading order

• Tab/focus order (for interactive elements)

• Any elements requiring aria

• Alt text for images/icons

• Legend and fieldset, if you're creating a form

Annotation Kits

Use these kits to make your annotations:

• VA Annotations Figma library

Consider prototyping in CodePen

You'll eventually test with users of assistive technology (AT). In general, AT works best with coded prototypes. Before research begins, you should consider creating your prototype in CodePen for the most accurate research results.

Resources for Developers

Following accessibility best practices and VA's guidelines will result in more accessible products for all Veterans.

Apply accessibility best practices

• Associate a label with every form control

• Include alternative text for images

• Identify page language and language changes

• Use mark-up to convey meaning and structure

• Help users avoid and correct mistakes

• Reflect the reading order in the code order

• Write code that adapts to the user’s technology

• Provide meaning for non-standard interactive elements

• Ensure that all interactive elements are keyboard accessible

Use VA Design System components

Don't re-create the wheel! If you're looking for a specific component, turn to the VA Design System before you create something new.

• Components: Components are interactive and non-interactive UI elements that can be grouped together or presented individually.

• Patterns: Patterns are solutions and researched best practices for solving user-focused tasks and recurring user interface design problems, like multi-part web forms and progressive disclosure.

• Templates: Templates, or page layouts, compose components within a single page. A layout can contain multiple variations of a component depending on the context.

• Foundational elements: These include colors, breakpoints, icons, typography, spacing units, and utility classes.

Test as you develop your product

Review the accessibility section of VA Platform for information about TestRail, end-to-end testing with Cypress, screen reader testing, and more.

Resources for Product Managers

Product managers at VA play a key role in “shifting left” - putting accessibility at the heart of the entire product lifecycle. 

Onboard team members

• Ensure that all new team members go through accessibility onboarding

Organize your sprints and meetings

• Invite accessibility specialists to relevant meetings, from the beginning of the project

• Prioritize and advocate for accessibility reviews, audits, and testing

• Help the team meet accessibility requirements as part of the Collaboration Cycle

Write accessibility-minded tickets

• Work accessibility into team and scrum ceremonies, e.g., add accessibility into acceptance criteria

• Pull accessibility defects into sprints when necessary (learn about the defect severity rubric and how to write accessibility defect tickets)

Get support for your team

• Reach out to the CAIA team for any needed accessibility-related support

Get Help from Accessibility Specialists

There are two routes to access support from accessibility specialists:

1. During the Collaboration Cycle, from the Governance team

2. At any point in your product's lifecycle, from CAIA and other accessibility specialists

Route 1: Collaboration Cycle support from Governance

Teams creating new features or products are required to go through the Collaboration Cycle, which includes accessibility reviews. Teams iterating on existing features or products are encouraged to get feedback through the Cycle as well.

The Collaboration Cycle is managed by the Governance team.

Collaboration Cycle

The Collaboration Cycle, managed by the Platform Governance team, is where teams who are building products/features on VA.gov get feedback and guidance on their product/feature to ensure it meets VA.gov experience standards for design, content, information architecture, quality assurance, accessibility, and research.

Teams engage with the Collaboration Cycle throughout their product’s/feature’s lifecycle via three separate touchpoint meetings (Design Intent, Midpoint Review and Staging).

Learn how the Collaboration Cycle works, and contact the Governance team with your questions.

Route 2: General accessibility support from CAIA

Teams at any point in the product/feature lifecycle can get general accessibility support from the Sitewide Content, Accessibility, and Information Architecture (CAIA) team. They can also reach out to specialists on Slack.

⚠️Note: Any ticket(s) given, on either route, will drive your team towards a more accessible product.

CAIA

The Sitewide Content, Accessibility, and Information Architecture (CAIA) team is here support your accessibility needs, no matter how far along you are in the product/feature lifecycle.

You can reach out to CAIA whether you're in the Collaboration Cycle or not.

How CAIA can help

• Evaluate your product at any stage - from wireframe to developed code - and provide feedback and recommendations

• Provide screen reader tech support and accessibility-focused observations during user research sessions with users of assistive technology

• Answer general questions about accessibility best practices

Check out the menu of offerings that CAIA provides

Get started with CAIA 🎫

• To start working with CAIA, submit a CAIA ticket

• Contact the team on Slack via #sitewide-content-accessibility-ia.

Other ways to contact accessibility specialists

• Embedded accessibility specialists: Several product teams have embedded accessibility specialists.

  • If you're on one of those teams, reach out to your specialist for help and advice.

  • If your team does not have a dedicated accessibility specialist, please submit a ticket with CAIA for support.

• Slack: VA accessibility specialists are available on Slack, the #accessibility-help channel.

  • No worries if you don't know what exactly you need.

  • Ask your question, and a specialist will help you as soon as possible.

• Office Hours: You can also reach CAIA by attending their weekly office hours.

  • As of 12/21/2023 Office Hours are on Tuesdays at 4 PM Eastern.

  • Join via Zoom - Requires login credentials

How Accessibility Specialists Provide Feedback

Accessibility specialists may engage with you in Slack, leave comments on your Figma mockups, write up their findings, or create formal GitHub issue tickets.

Feedback from the CAIA team

Receiving Feedback

Depending on the VFS team's needs, the content, accessibility, and information architecture CAIA workstreams will work together to review products.

CAIA can adjust to your needs. Depending on the product and team in question, CAIA may opt to provide feedback in the team's Slack channel, or as comments in a mockup.

For more detailed, thorough reviews, CAIA accessibility specialists will write up their findings and add them to GitHub. They'll share a link to the findings with the team via Slack and any related GitHub issue tickets.

• Product reviews include existing and potential accessibility issues, and proposed solutions. In general, this is what CAIA looks for and what tools CAIA uses to audit a product.

• User research findings include accessibility issues found during testing, participant quotes, and research synthesis from the CAIA team.

Feedback Examples:

• Design review deliverable

• Midpoint review deliverable

• User research findings

Collaboration Cycle Design Intent and Midpoint Review Tickets

The Governance team will provide suggestions for how to develop an accessible product based on your user flows, wireframes, and mockups.

Accessibility specialists will document their feedback on the VFS-provided artifacts following the Must, Should, and Consider Framework. They may also provide additional notes that don’t comment on the artifacts themselves but are important for implementation (eg. engineering/coding notes).

Collaboration Cycle Staging Review Tickets

During a Collaboration Cycle Staging Review, accessibility specialists will review your product. If they find any accessibility issues, they’ll write a ticket for each issue that outlines:

• The issue (often with screenshots or video examples)

• A proposed solution

• The VA experience standard related to the issue

• The defect severity level

Learn more about Staging Review Issue tickets.

Creating Tickets

If you’re reviewing your product for accessibility issues, you can write your own tickets to keep track of your findings and close them upon completion.

Learn how to write good accessibility tickets. And here are tickets for common accessibility issues to help you get started.

Ensure that your work is Section 508 compliant

The VA Section 508 Office validates compliance with federal law mandating accessible information and communication technology.

• Product teams working on authenticated pages and applications are required to submit a VA Section 508 Office Audit Request. We prefer that you submit your request before launch, if possible. But you may still launch before you receive the audit.

• The Section 508 Office can also review your non-HTML documents (PDF, DOCX) for accessibility issues.

  • Learn when and how to create accessible non-HTML documents.

Request support from the VA Section 508 office.

Improve your skills

Accessibility Champs

Accessibility Champions is a grassroots, volunteer-led educational program. Anyone working at the VA, with access to the OCTO Slack channel, can become an accessibility champion through this curriculum!

Start your Accessibility Champs journey.

VA Trauma Community

The VA trauma community is a grassroots, volunteer led multi-disciplinary community focused on maturing our approach to trauma from facilitating research to caring for practitioners. 

Learn more about the Trauma Community.

Accessibility Overview

• 18F’s accessibility guide

• Accessibility roles in government

Technical Considerations

Note: All of the following links are PowerPoint files. When you click them, your computer will download the PowerPoint:

• Buttons and Links and Action Links (pptx)

• Focus Management (pptx)

• Headings (pptx)

• Live Regions (pptx)

• Links (pptx)

Cognitive issues

• Cognitive considerations

Assistive technology

• Tips for usability testing with people with disabilities

• Getting started with keyboard navigation and screen readers

• Testing with assistive technology users

• Designing for people with Traumatic Brain Injuries

Page Content Sources

This page is a Work in Progress (WIP). The goal of this page is to provide a well-organized clearinghouse of information about VA's accessibility practices. Our mission - to point VFS teams to the information, tools, and people they need to make VA.gov accessible, beyond compliance.

Content Source

• This document was created from the following GitHub page.

• The structure and content of this page is based on:

  • CAIA's modeling exercise - Requires Airtable login credentials

About the Audit

• This page was created as a result of a content audit of accessibility documentation found across multiple environments.

• It was then analyzed and aggregated to reflect current accessibility practices.

Help and feedback

• Suggest content changes to this page.

• Submit new Platform Website content.

• Get help from the Platform Support Team in Slack.

• Submit a feature idea to the Platform.