A11y documentation audit: Review Buttons component documentation

[k80bowman]

Description

We want to audit our accessibility documentation on design.va.gov to make sure that it is up-to-date with current accessibility guidelines.

For this ticket, we need to review the accessibility guidelines for the Buttons component on design.va.gov and provide any updates that need to be made to the existing documentation as a comment on this ticket.

Details

Just for reference, here are some useful links: Platform accessibility standards VFS Team accessibility responsibilities VA.gov experience standards VSP WCAG 2.1 Presentations: VSP WCAG2.1 Foundational Testing Redux VSP WCAG2.1 New Success Criteria

Acceptance Criteria

• [ ] Review accessibility guidelines on the following pages of design.va.gov:
  • [ ] https://design.va.gov/components/buttons#accessibility-considerations
• [ ] Make sure accessibility guidelines match the performance of the component in Storybook
• [ ] Add notes on any necessary updates as a comment on this ticket
• [ ] Ping Katy, Carol, and Natalie for review

[CourtneyChambers77]

The button component to help users carry out an action like starting an application or saving their information. When using the element, always specify a type. Buttons should display a visible focus state when users tab to them. Default button for the main call to action on a page. Avoid using

or tags to create buttons. Screen readers don’t automatically know either is a usable button. button for the main call to action on a page. Avoid using multiple default buttons on a single page. Having more than one main call to action reduces their impact and makes it harder for users to know what to do next. When letting users carry out an action like this, it’s a good idea to include an additional step which asks them to confirm it. Start buttons do not submit form data, so they use a link tag rather than a button tag. When pages have too many calls to action make it hard for users to know what to do next. Before adding lots of secondary buttons, try to simplify the page or break the content down across multiple pages. Include more contextual information in the button label for screen readers. You can use an aria label to specify form numbers or program names in the buttons for greater context. Warning buttons are designed to make users think carefully before they use them. They only work if used very sparingly. Use a button group when two or more buttons are placed together. Any links within a button group will automatically align with the buttons. It is important to use Action links for calls to actions that link to another page rather than buttons, because screen readers always say “link” before links, and “button” before buttons. Button and link confusion can be very frustrating for assistive technology users. A user with a screen reader may pull up a list of links and may not find a specific link because it turns out that it has actually been designated as a button in the markup. Using buttons and links intentionally results in a more inclusive experience for assistive technology users. Make sure to read both button and action link guidance to determine what is needed for a page. A button’s tap target size should be at least 48 x 48 px, with at least 8 px separating tappable elements.