search

department-of-veterans-affairs / va.gov-team

Public resources for building on and in support of VA.gov. Visit complete Knowledge Hub:
https://depo-platform-documentation.scrollhelp.site/index.html
284 stars 206 forks source link

[a11y support] VA Notify: 508 Audit Prep for VANotify Portal #97688

Open sara-amanda opened 1 day ago

sara-amanda commented 1 day ago

[!NOTE] HIGH-LEVEL OVERVIEW

  • Timeframe:
    • Audit likely to take place in 2025
  • Prep Work:
    • The prep-work for this 508 audit is taking place in the following ticket: #2501
    • Initial support: Provided by CAIA, to date, guidance on accessibility testing.
    • Additional guidance: Needed to help assist the team, in preparing for the audit. Review the preparation guide.
  • The official 508 Request Process includes, and is currently in progress, by the VA Notify Team:
    • Submit a 508 Audit Request to initiate an audit.
      • Ensure project/product testing results are included.
    • Self identify 508 accessibility defects to the 508 SME assigned to our product for tracking purposes and visibility.

Issue Description

We need to prepare for the upcoming 508 office review of the portal. This will require gathering use cases, permissions, and other relevant documentation. We also need to identify any additional items required for the review, and schedule a grooming session to ensure we are ready for the review.

Review the problem, value and existing measures being taken by the VA Notify Team > ### How do we know this is a problem? > > The 508 office review is a mandatory part of our compliance process, and the review requires specific documentation and understanding of the portal’s accessibility. > > ### Value > > Successfully preparing for the 508 office review will ensure that the portal is accessible, compliant, and ready for review, reducing the likelihood of delays or additional rounds of revisions. This will benefit both the Notify team, by providing clarity on required changes, and Notify users, by ensuring the portal meets accessibility standards. ## Existing Measures Being Taken > - UX ensures that all user interfaces are intuitive and accessible, conducting regular reviews for compliance with accessibility guidelines and testing for ease of use by individuals with diverse needs. > - QA when testing all new features and changes to functionality, performs a color contrast check, tab navigation check and screen reader check as part of QA > - ENG adheres to accessibility (a11y) standards ### To-do's/guidance from Martha: > "The VA 508 Office will do it via their official processes. They will need a test user/password and maybe a description of some key user flows through your app. Anything you have on hand for your existing accessibility processes or known defects would be good for them to know as well."

Known Issues

Jake Uhteg reached out via Slack to Sara Smith, and discussed the current accessibility testing, additional testing methods and additional accessibility advice. Jake then provided the known issues to Elissa.

  • Color contrast - We may need to change a couple of inactive buttons to active buttons and trigger error message. I have an open question out about how inactive tabs factor in, but nothing big on that front
  • Tab navigation - we’re good, one weird bug where top nav isn’t accessible if a service is selected. But overall, in a good spot.
  • Screen Reader - good-ish. Everything on the portal is read when using the built-in windows narrator. But the way that was accomplished caused some errors when doing the axe tools check. And I’m not doing it in true screen reader fashion because of Citirx limitations. I am still working with Sara and finding a proper tool other than narrator to go through this.
  • Zoom Testing - I wasn’t aware this was a required piece so I never tested for it. We’ll have to adjust our pages to accommodate for this and I’ll have to add it to my testing plan going forward

CAIA Feedback Provided

Review the feedback provided to Jake > ### Avoiding Inactive Buttons > When buttons are inactive, some users– particularly those with cognitive disabilities- may not know how to activate them. Disabled buttons don’t explain what’s wrong. They communicate that something is off, but very often that is not enough information. As a result, users are left wondering what’s actually missing, and consequently are locked out entirely. For example, if someone were to type in a short acronym like “VA” to search and the button doesn’t become accessible, they may think the search field is broken. > In addition, disabled buttons can be unintentionally read out and accessed by mobile screen readers using touch controls. Source: https://design.va.gov/components/button/#do-not-disable-form-elements > ### What to do instead > While it is technically possible, we strongly discourage disabling buttons. Here are recommendations on how to handle specific interactions: > - Lack of required fields. When a user attempts to submit a form without entering all required form fields: > - Announce the error and shift focus to the first unfilled required form field. > - Properly indicate required form elements (the right thing will happen for you when you use the required property on form fields in the Design System). > - No longer valid options. If certain options in a form are no longer valid then there are two options: > - Replace the form elements that can no longer be changed with text representing the current value instead of the current value within a disabled input. > - Hide the form elements that are no longer valid. **Source**: https://design.va.gov/components/button/#what-to-do-instead ### Axe Scans > Automated scans Pass with exceptions - Axe testing shows a false positive on color contrast for the default variation > Axe is capable of finding many [WCAG](https://www.w3.org/WAI/standards-guidelines/wcag/) and accessibility best practice violations. > In general, a product that is passing all of its axe tests should also pass all of the WAVE tests, and any issues flagged by WAVE should get a closer look. > Install the [WAVE browser extension for Chrome, Firefox or Edge](https://wave.webaim.org/extension/). > If engineers are using VSCode, they should use the [axe linter](https://marketplace.visualstudio.com/items?itemName=deque-systems.vscode-axe-linter). **Sources:** - https://depo-platform-documentation.scrollhelp.site/collaboration-cycle/prepare-for-an-accessibility-staging-review#axe - https://depo-platform-documentation.scrollhelp.site/developer-docs/end-to-end-testing-with-cypress - https://depo-platform-documentation.scrollhelp.site/developer-docs/accessibility-testing-helper-functions - https://design.va.gov/about/accessibility/accessibility-testing-for-design-system-components#testing-principles - https://marketplace.visualstudio.com/items?itemName=deque-systems.vscode-axe-linter > ### Additional Automated Testing Options > Although automated testing tools may only pick up on 20-30% of accessibility issues, they can be easy to use, provide immediate feedback, and help to find glaring accessibility issues. These tools are typically used when content is available in a live, coded environment that is viewable in a web browser. > > #### Browser Extensions > The benefit of tools that integrate into browsers is that they give you the capability of testing directly in a browser. > > - [Axe DevTools](https://www.deque.com/axe/devtools/) - an accessibility testing toolkit developed by Deque, that integrates with your browser of choice, to scan entire pages or individual components. This is typically a highly preferred automated tool across the board. > - Additional tools - while we rely on axe DevTools for most automated testing, here are some additional tools to consider: > - [ArcToolkit](https://www.tpgi.com/) - a set of accessibility tools that aids developers in identifying accessibility problems and features for WCAG 2, EN 301 549, and Section 508 > - [WAVE](https://wave.webaim.org/) - a web accessibility evaluation tool developed by [WebAIM.org](http://webaim.org/). It provides visual feedback about the accessibility of your web content > - [IBM Equal Access Accessibility Checker](https://www.ibm.com/able/) - an open-source tool for web developers and auditors that utilizes IBM's accessibility rule engine, which detects accessibility issues for web pages and web applications. > - [Accessibility insights for web](https://accessibilityinsights.io/docs/web/overview/) - a tool, similar to Axe and WAVE, that evaluates a page's semantic elements and styling > ### Manual Testing Tools > - Manually interacting with content can help to fill in the gaps missed by automated testing. Included below is a good grouping of several different tools, so feel free to experiment with different combinations in your testing. > - Color and Contrast > - Zoom/Magnification > - Architecture and Semantics > - Screen Readers > - For details on the items above, see the link below. ... **Source**: [Tools we use (CAIA Accessibility)](https://github.com/department-of-veterans-affairs/va.gov-team/blob/master/teams/CAIA/accessibility/tools-we-use.md#tools-we-use) ### Zoom > - Zoom Testing - This is another piece that I have never tested before. The preparing page mentions 400%, but a lot of the [information](https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html) I’ve found only talks about 200%. I was wondering if you know which requirement would be better to follow, and just some tips if this is something you’ve encountered before. - **:star: Yes, I would do the following all three :slightly_smiling_face: 200%, 300%, and 400% zoom (Browser width: 1280px)** - All page elements must be readable and usable at 200%, 300%, and 400% zoom. That means: - No functionality has been hidden or removed from the page. (Example: a button that is visible on desktop but hidden on a mobile device will likely be hidden at high zoom.) - Nothing overlaps. (Example: text getting covered up by other elements.) - No horizontal scrolling. (Exceptions: data tables, charts, and images.) - **Steps to test** - Set browser width to 1280px ... **See on this page below:** [https://depo-platform-documentation.scrollhelp.site/collaboration-cycle/prepare-for-an-accessibility-staging-review#Prepareforanac[…]w-Stepstotest.2](https://depo-platform-documentation.scrollhelp.site/collaboration-cycle/prepare-for-an-accessibility-staging-review#Prepareforanaccessibilitystagingreview-Stepstotest.2)

About the Team

Supporting Artifacts

Review the supporting artifacts - [VA Notify Section 508 Audit Preparation Guide](https://github.com/department-of-veterans-affairs/notification-portal/issues/2501#issuecomment-2494380545) in [GitHub 2501 ](https://github.com/department-of-veterans-affairs/notification-portal/issues/2501) - **508 Toolset and Documentation** - Access the tools used by the audit team, their versions, and instructions for obtaining them at the - [VA 508 Office Tools SharePoint page](https://dvagov.sharepoint.com/sites/vasection508/SitePages/Audit-Tools.aspx). - **Staging Review Preparation** - Guidance on preparing for a staging review can be found in the [Accessibility Staging Review Documentation](https://depo-platform-documentation.scrollhelp.site/collaboration-cycle/prepare-for-an-accessibility-staging-review). - **Developer References** - [Section 508 Official Website](http://www.section508.gov/) - [United States Access Board](http://www.access-board.gov/) - [WebAIM Accessibility Guidelines](http://webaim.org/) - [W3C WCAG 2.1 Quick Reference](https://www.w3.org/WAI/WCAG21/quickref/) 
### a11y Tasks
- [x] **Collaborate**  with VA Notify (Elissa and Jake) via Slack
- [x] **a11y Support** - feedback on accessibility testing
- [x] **Document** - initial feedback provided and noted in this ticket
- [ ] **Review** - Discuss with Elissa next steps and assistance needed to help prepare the team for the 508 audit. @EvanAtCoforma 
- [ ] **Review** - [VA Notify Section 508 Audit Preparation Guide](https://github.com/department-of-veterans-affairs/notification-portal/issues/2501#issuecomment-2494380545) @EvanAtCoforma 
### Acceptance Criteria
- [x] Assigned by Martha to assist the team 11/19/2024
- [x] Prioritization received from Martha 11/22/2024
- [x] Support provided by CAIA, to date, guidance on accessibility testing.
- [ ] Additional guidance needed to help assist the team, in preparing for the audit by reviewing and providing feedback on the [VA Notify Section 508 Audit Preparation Guide](https://github.com/department-of-veterans-affairs/notification-portal/issues/2501#issuecomment-2494380545) 
## Ticket Updates (CAIA Internal)
- [ ] _Connect to an `Epic` or `Intake` (what body of work is this a part of?)_
- [x] _Label with `Originator/Team` (product team or stakeholder requesting support)_
- [x] _Label date in the `Open Date` field_
- [x] _Label with `Estimate` (level of effort expected for this ticket)_
- [x] _Add `Assignee(s)` name(s) to ticket_ (include Naomi)
- [ ] _Add `Assignee(s) name(s) to each task` they will complete via handle tag (if known)_
- [x] _Select a `Priority Level`_
- [x] _Update date in `Last Checked` field_
- [ ] _Label with `Actual` (level of effort it took to complete this ticket)_
- [ ] _Update date in_ `Closed Date`
### Related Tickets
- [ ] [UX: Prepare for 508 Office Review of VANotify Portal #2501](https://github.com/department-of-veterans-affairs/notification-portal/issues/2501)
artsymartha68 commented 1 day ago

No rush on this at all. And since this is not Veteran-facing, it takes a lower priority.

sara-amanda commented 1 day ago

Timeframe

cc: @NaomiPMC