Component Accessibility Status 🏖️

[jeanservaas]

Summary

REF carbon-design-system/carbon-platform#803
REF #11370

We want to give users immediate confidence that Carbon components have been vetted for accessibility out-of-the-box. Also, ideally the majority of these tests should be automated; right now they are not.

A crucial aspect of component completeness is knowing to what degree is each asset (e.g. component) accessible. After talking with Marc Johlic, we don't have to go to lengths for each asset to specify which WCAG rules they conform to (e.g. WCAG 2.1 AA.) Instead, a simpler accessibility testing status scale/process can be established:

1. Pass There are no violations when running the automated Equal Access Checker on default component state.

2. Pass There are no violations when running the automated Equal Access Checker on more complex component states and variants.

3. Pass There no violations when running automated keyboard navigation tests using Jess/Michaels' tabbing guidelines.

4. Pass No screenreader violations. (Manual process, leverage Ragu's expertise and time.)

---

- if any of these show a violation it's a Sev2 bug
- we're ensuring that all of these steps are a pass before each new release

---

Justification

We've had specific asks from leadership to offer more clarity and emphasis around the accessibility of Carbon out-of-the-box.

Tasks

Beta Give feedback

1. Component Accessibility Status: EAC Default state baseline audit/coverage #13746
   8 of 8
   adopter: strategic-product role: dev 🤖 type: a11y ♿ type: infrastructure 🤖 +4
   
2. Component Accessibility Status: Audit untested problematic complex states #13780
   3 of 3
   adopter: strategic-product role: dev 🤖 type: a11y ♿ type: infrastructure 🤖 +4
   
3. Component Accessibility Status: EAC Complex state coverage #13747
   34 of 34
   adopter: strategic-product planning: umbrella role: dev 🤖 type: a11y ♿ type: infrastructure 🤖 +5
4. Component Accessibility Status: JSON output #14480
   adopter: strategic-product role: dev 🤖 +2
   
5. Component Accessibility Status: Automated Keyboard Navigation Tests #13748
   2 of 2
   adopter: strategic-product planning: umbrella role: dev 🤖 type: a11y ♿ type: infrastructure 🤖 +5
6. Component Accessibility Status: design research and jams carbon-website#3520
   adopter: strategic-product role: design ✏️ type: a11y ♿ type: docs 📖 +4
   
7. Component Accessibility Status: Playback research and sketch ideations to dev #14695
   adopter: strategic-product role: design ✏️ type: a11y ♿ +3
   
8. Component Accessibility Status: design synthesis and playback rev1 #14484
   adopter: strategic-product role: design ✏️ type: a11y ♿ type: docs 📖 +4
   
9. Component Accessibility Status: Update all tests to use the proper naming convention for tags #14595
   46 of 46
   role: dev 🤖 +1
   
10. Component Accessibility Status: design synthesis and playback rev2 carbon-website#3518
    adopter: strategic-product role: design ✏️ type: a11y ♿ type: docs 📖 +4
    
11. Component Accessibility Status: design synthesis and playback rev3 #15212
    role: design ✏️ +1
    
12. Review and update the content for Accessibility and Accessibility status tabs #15326
    role: design ✏️ role: dev 🤖 status: content review ✍️ type: a11y ♿ +4
    
13. Component Accessibility Status: Final Design Deliverable #15279
    role: design ✏️ role: dev 🤖 type: enhancement 💡 +3
    
14. Component Accessibility Status: Table on Accessibility tab carbon-website#3848
    adopter: strategic-product proposal: accepted role: dev 🤖 type: enhancement 💡 +4
    
15. Component Accessibility Status: Overview page > Accessibility status tab carbon-website#3849
    adopter: strategic-product proposal: accepted role: dev 🤖 type: enhancement 💡 +4
    
16. Component Accessibility Status: Usage page > Accessibility Status variant switcher carbon-website#3847
    adopter: strategic-product proposal: accepted role: dev 🤖 type: enhancement 💡 +4
    
17. Component Accessibility Status: Usage page carbon-website#3850
    0 of 42
    adopter: strategic-product proposal: accepted role: dev 🤖 type: enhancement 💡 +4
    
18. Component Accessibility Status: Overview page > Accessiblity tab > All component Status carbon-website#3851
    adopter: strategic-product proposal: accepted role: dev 🤖 status: blocked 🙅‍♀️ type: enhancement 💡 +5
    
19. Component Accessibility Status: Enforce playwright tag naming convention #15370
    5 of 6
    proposal: accepted role: dev 🤖 type: a11y ♿ type: enhancement 💡 type: infrastructure 🤖 +5
    

[laurenmrice]

Links to reference:
Component page with status per component: https://next.carbondesignsystem.com/assets/components
Component status card: https://next.carbondesignsystem.com/libraries/carbon-react/latest/assets/accordion

Adobe Spectrum checklist: https://spectrum.adobe.com/page/checkbox/#Design-checklist
Gestalt simple status: https://gestalt.pinterest.systems/web/badge

[tay1orjones]

When thinking about how to surface the status of these 4 categories on the website, we may be able to generate a json file that could be consumed by the website to dynamically power the table (or however it's designed) on the website.

This could include:

• As part of a release in CI, generate the JSON report using playwright's JSON reporter. This file contains all the information about the tests, status, result, etc.
• Add this JSON file to the website, and build a component to pull in the file and generate the table or other design for these statuses.
  • This component could also use the github API to pull in the number of issues related to a given component and surface that alongside the status (if we want to)
• In the monorepo, the tests for each component could follow a naming convention to build this out, e.g. Button - default state, Button - complex state, Button - keyboard navigation. These names would be used by the component in the website to determine if the a11y statuses 1, 2, 3, 4 should be marked as ✅ or 🚫
• That same release action or CI workflow in the monorepo could open a PR on the website repo updating the JSON file with the newest version as part of the release, so this would automatically be kept up to date.
  • An alternate path here would be to host this file within the monorepo and then have the website pull it from there instead of the monorepo "pushing" the updated file to the website. This is probably a more clean option that could be updated on every PR merge to main instead of just per-release. Then as the website is redeployed when PRs merge the data would be kept up to date more.