Summary

Added accessibility tests pages to the accordion, button, and link pages.

Related issue

Closes #2103

Preview link

Accessibility test page

• Accordion - accessibility test page
• Button - accessibility test page
• Link - accessibility test page

Component pages

• Accordion - main component page
• Button - main component page
• Link - main component page

Related resources

• Component critical testing checklist (Google sheets 🔒)

Notes

• Additional notes

  • [11/15 meeting notes](https://docs.google.com/document/d/1WBDzoA-wGnF79RGN59Ly2hJtjgKZviWQLnUjGfqNlKQ/edit) (Google doc 🔒)

  An list of updates made to each section by title:

  • What USWDS has done to ensure the current version of the accordion is accessible
  - Moved to general accessibility testing page (not yet built)
  • Best practices for integrating accessibility into the accordion component
  - Moved to general accordion page (including all references to aria)
  • Consider your audience
  - Simplified these to only include items that specifically affect accordion accessibility concerns - All others can be moved to the general accordion page
  • What USWDS is unable to test
  - Moved to general accessibility testing page (not yet built)
  • How you should test
  - Renamed to "How to check if your implementation is accessible" - Combined with "Definition of done" section at the bottom - Reconfigured formatting to match other docs pages
  • How to perform manual testing of the accordion component
  - Added dummy intro text
  • Checklists
  - Added icons to show current status of each item - Added tags in case we wanted to identify which WCAG level or rule applies to each item (Optional) - Organized items into subcategories (Categories are currently notional) - Added notional text about who uses each type of AT/why a tester should care.
  • Related WCAG criteria
  - Added to an accordion below each applicable section - Simplified rule language to be easier to read. This is just notional - if we want to move this direction it would benefit from a plain language rewrite
  • Expected keyboard interaction
  - Created a table for expected behavior of individual keystrokes. - Added this to the accordion panel

Testing and review

Accessibility team

1. Confirm the test checklist summaries and data are accurate.
2. Confirm that the content in the "how to test" accordions is accurate and makes sense.

Content team

1. Confirm the copy on the checklist page meets copywriting standards.
2. Confirm that the new accessibility test status section on the main component page meets copywriting standards.

Developers

1. Confirm that the checklist.md files meet standards
2. Confirm that the updated subnav on the main component pages meets standards
3. Confirm that the data structure in the yml files is intuitive and follows standards
4. Check that prototype correctly counts the number of items for each test status.
   • Change the number of tests in accordion.yml. Change the values of test_status in a selection of data items. Confirm the table updates to reflect the new numbers.
5. Confirm that the content in the "how to test" accordions is accurate and makes sense.
6. Confirm that the feedback buttons point to the appropriate location
7. Confirm that the logic in the html templates meets standards (HOLD - work still in progress)
8. Confirm the file structure meets standards
9. Confirm the Sass styles meet standards (HOLD - cleaning up now)
10. Confirm that you can create a new checklist page with the required data (Note: README file is not finished).

Additional tests

Here are the things I checked:

• Main component pages have the following elements:
  • Compliance tag
    • Confirm correct status
  • Blue alert in accessibility section
    • Confirm link works
    • Confirm text reflects correct component
    • Confirm it does not exist on other pages
  • Accessibility test status section
    • Confirm the numbers are accurate
    • Confirm the link works
    • Confirm it does not exist on other pages
  • Changelog
    • Confirm data
  • Check styles in the following browsers:
    • Safari
    • Chrome
    • Firefox
    • iOS Safari
• Accessibility tests pages have the following elements:
  • Compliance tag
    • Confirm correct status
  • Accessibility status section
    • Confirm the stated numbers are accurate
  • Intro grid
    • Confirm correct component is referenced in header
  • Jump links
    • Confirm it shows only the categories for AT types tested on that component
    • Confirm the links work
    • Confirm jump link order matches checklist order (general, zoom, keyboard, screen reader)
    • Confirm that the AT section headers are visible after click (checking that scroll-margin-top works)
  • “How to” instructions for each AT type (Note: “General” should not have “how to”/intro text)
    • Confirm the description references the correct AT type
    • Confirm the instructions are accurate and make sense
  • All tests are included in the checklist
    • Confirm the test data
      • Summary
      • Summary additional
      • Status text (only for “passed with exceptions”, “failed” or “conditional”)
        • Confirm statement is accurate and makes sense
      • Github issue link (only for “passed with exceptions” or“failed” )
        • Confirm it points to the correct issue
      • WCAG criterion number and description
      • WCAG level
      • Test status
      • Version tested
      • Note - did not include row 48 from the button tests since there were no results
  • Feedback buttons
    • Confirm links go to the expected location
  • Changelog
    • Confirm data
  • Confirm styles in the following browsers
    • Chrome
    • Safari
    • Firefox
    • iOS Safari