Documenting accessibility — roles and responsibilities

[austinhernandez]

Background

As a product team we need to ensure that accessibility becomes an essential and integral part of design and development. 508-compliance is mandatory for launch. By starting projects with accessibility in mind and creating a process for documenting user interaction and accessibility requirements we can build more inclusive products and avoid costly, last minute accessibility fixes. By deciding early in the process which teams/roles are responsible for which part of inclusive design

It covers the following stories:

1. As a user, I need information to be inclusive to a wide variety of situations and needs as well as accessible for people with a wide variety of disabilities and/or preferences
2. As a team member, I need to know which accessibility considerations are determined by design and/or development
3. As a team we need to delineate the "responsibilities of accessibility" and the best ways to communicate needs
4. As a team we need to bring accessibility awareness earlier on in the project to create good guidelines in order to accommodate a wide array of human experiences
5. As a new team member, I need an onboarding tool

We'll know we're done when...

• [x] There is an agreed upon process between design and development (eg annotations? comments on figma? tickets? etc.)
• [x] There is a plan in place to do usability testing with people with a variety of disabilities

Example outcomes

• Designers communicate and document how interactions look and how they should work
• Designers document navigation, “hidden” interactions, and what assistive technologies should announce.
• Designers use a checklist such as WCAG for designers by Geri Reid to make considerations on colors, layouts, fonts, and contrast.
• User research participant recruiting includes accessibility user research with an organization such as SourceAmerica
• Define and document accessibility requirements at project level (eg Do we target AA or AAA? Is accessibility part of the "Definition of Done?")
• Developers show accessibility considerations in product demos
• Developers & Accessibility experts document the technical implementation. (eg correct markup, ARIA roles, landmarks, etc.)
• Testers and QA teams define and document accessibility test cases

Example of roles and responsibilities

Accessibility considerations that may need documenting

• Accessible color palette
  • AA or AAA?
• Interactions states and statuses
  • Button states
  • Form inputs
  • Error, Success, Information
  • What triggers the error (= error case)
  • What the exact message (copy) should be.
  • Focus order in form elements / Tabulation key order — Microsoft A11y Focus order for Figma
• What is the Correct HTML5 type?
• Is this field supposed to have autocomplete, autofill, etc. (attributes)?
• Legends and field grouping markup
• Default focused elements when page opens
• Interaction flow to document mouse and keyboard input — An example of keyboard navigation implementation with shortcuts documented
• Alternatives for complex gestures
• Image alternatives and assistive technologies (screen reader) announcements
• Add documentation for some ARIA states
• Announced content order
• Documenting links
• Extra content for assistive technologies
• HTML headings in the page
• Focus order at page level
• Zoom behavior
• Landmarks and more documentation with help from Developers & Accessibility Experts
  • Correct HTML semantic elements
  • ARIA Roles
  • ARIA states and properties
• Reduced motion and play/pause buttons
• User flow to document interaction between pages
• Screen flows
  • Transitions between pages. Especially in single page applications or mobile apps.
  • Alerts or messages that might appear and stay on top of the page even if users got to another one.
  • Multiple steps flow where you might have session lengths. But avoid limiting form sessions length if you can.
• Access to external documentation for captions, transcripts, etc.
  • Caption for videos. You can provide a link to the plain text transcript and / or a link to the .srt file
  • HTML/text resources for Audio transcripts (for podcasts for example)
  • A list of links/CTAs with the anchors. “Click here” links are horrible for accessibility AND for usability. You want to avoid that. Often content people (SEO, UX writers) will provide a whole list of such links with the actual URL, the anchor, the title, etc.

[petermarks-gsa]

Next step: @austinhernandez to do an accessibility workshop to talk about roles and responsibilities as a team. Look out for it on the FAC calendar!

I moved this to the backlog, but we want to bite off chucks of this to be done sprint by sprint.

[austinhernandez]

Brainstorm with the team about documentation on this Mural: https://app.mural.co/t/gsa6/m/gsa6/1650474235148/d244da85899b0469d94591cfeb0fcccbbc4edf21?sender=austinhernandez5199

Notes for the meeting here: https://docs.google.com/document/d/1af7W0Dh_AqeRTBmVKISP794pojBRwk66jzgU3UfJluc/edit

Need to come up with an action plan, but there was a lot to unpack in terms of responsibilities. Big call outs are

• Coming up with a process for manual usability testing
• Usability testing and protocols specifically for people with varying disabilities
• Deciding what can be automated
• Leveraging the existing accessibility checklist
• Having the check be part of "done"

[austinhernandez]

As a group, we decided that everyone is responsibility for:

• Creating inclusive and accessible products that meet a wide-range of human experiences
• Raising accessibility concerns early and often
• Using the USWDS components where ever possible to minimize custom accessibility solutions
• Doing their part of the accessibility checklist
• Bringing in an accessibility expert if needed through #g-accessibility Slack channel if subject matter expertise does not exist on the team
• Improving and expanding their knowledge of accessibility in their role/discipline/practice
• Using browser defaults and user customizations (eg zoom, color inversion, text size) unless otherwise noted by usability testing
• Breaking up or adding tickets to include your role's accessibility sections

As a group, we decided Design is responsible for:

UX research

• Deciding which things do we need to be manually vs automatically tested
• Writing scenarios for manual testing, (eg the one for Forest Service)
• Writing research plans and protocols for users with disabilities
• Doing participant recruiting with groups such as SourceAmerica to work with users with disabilities
• Understanding what needs to be imposed by a browser (eg zoom, color inversion, text size, language) and what controls users expect

Product / Visual Design

• Creating an accessible color palette
• Documenting when something deviates from the expected behavior of a USWDS component
• Following logical H1-H6 heading level order
• Designing language controls
• Suggesting when alt text is or isn't necessary for icons and decorative design elements
• Suggesting announced content order, focus order, and default focused elements at the page and component levels

Content

• Writing in plain language
• Advocating for and considering multilingual support
• Creating alt text, labels for links (anchor + target), and error text in forms
• Deciding when alt text is or isn't necessary for icons and decorative design elements
• Deciding on heading levels for text
• Suggesting announced content order, focus order, and default focused elements at the page and component levels

As a group, we decided non-designers is responsible for:

Front-end / Dev

• Ensuring browser controls (eg zoom, color inversion, text size) work with the interface
• Implementing automated CI check: Ax Core, HTML code sniffer, lighthouse (including accessibility audit)
• Listening to the experience with a screen reader to ensure information presented in order
• Navigating the page with tabs to ensure tasks can be completed

Accessibility expert

• Using subject matter expertise to advise on improvements to interfaces and interactions

PM

• Adding accessibility definitions of done into tickets
• Advocating for additional work done up front, instead of in final sprints or after release
• Updating onboarding materials

[austinhernandez]

@MelissaBraxton to add to wiki for process documentation @petermarks-gsa consider where this goes for onboarding and acceptance criteria (#234)

[austinhernandez]

Acceptance criteria examples for design ticket

• [ ] All text has a contrast ratio of 4.5:1 with the background
• [ ] Interaction are documented if they deviate from USWDS components
• [ ] The needs of someone navigating the site with the use of a screenreader or keyboard has been considered and documented
• [ ] There is an option for multilingual support
• [ ] There is supporting documentation for alt text, labels for links (anchor + target), error text in forms, and what assistive technologies should announce (if applicable)

For a stories about research:

• [ ] User research participant recruiting includes work with users with disabilities
• [ ] Writing research plans and protocols for users with disabilities

[jadudm]

I don't want to lose this. I'm putting it in the post-MVP milestone so that it remains on the board/radar. We have incorporated a number of things from this ticket, but I want to come back to it in a systematic way.

[jadudm]

Marking for revisitation and closing.