Accessibility Feedback - Design intent eBenefits - CH31 Orientation Content

[joshkimux]

Feedback

• Must = the feedback must be applied
• Should = the feedback is best practice
• Consider = suggestions/enhancements

https://staging.va.gov/careers-employment/vocational-rehabilitation/apply/introduction

Must

1 .Content being added or removed from the page must announce a change to assistive devices defect-level-1 ❗️

Screen reader users will not know when content is being added or removed from the page unless it is explicitly announced. This is important for this page in particular since results are provided in dynamic grey boxes that are added and removed from the page.

• Use aria-live to announce new regions that screen reader users should be aware of while making choices in the wizard
• Fix bug related to orientation widget appearing but not disappearing upon certain wizard selections (to avoid screen reader users from accidentally using the orientation widget even when they don't need to)

2. Important unfocusable text in forms must be announced defect-level-1 ❗️

Most screen reader users will skip over text within forms that are not focusable e.g. p, span, strong. This means that important content provided within the grey boxes may be completely missed which can lead to unwanted behavior. In this particular context, it means that some screen reader users may completely skip over most sections of content within the orientation widget.

• Use aria-describedby to programmatically connect links within the grey boxes to their proceeding descriptions. For example, should a user tab onto "Apply online now with VA Form 28-1900," they should also hear, "Based on your answers, you probably qualify for VR&E benefits. Before you apply, please go through the VR&E orientation below. If you already know you want to apply for VR&E, you can go directly to the online application without going through the orientation below. "
• For a proper fix, I recommend using one thing per page so that results can be announced separately on their own page and the orientation can be completed on its own separate set of pages.

3. Visual groupings must be clear to screen reader users defect-level-1 ❗️

It is currently programmatically unclear when the wizard ends and the orientation wizard begins. Screen reader users may skip over the h2 if they use the tab key to continue moving through the page as if it is a form.

• If no major changes can be made, a quick fix to this may be to add a role="group" to the orientation widget along with an aria-labelledby that points to the h2 Veteran Readiness and Employment orientation. The h2 "Veteran Readiness... orientation" should remain persistent across all of the orientation pages to act as a group label and create a logical heading order. The former h2s in each page (e.g. "VR&E basic benefit information" on the second page) should be demoted to h3s. Adding content that indicates progress and tying it to the h3 using aria-describedby may help with understanding progression. This will make it more clear to screen reader users that each of these pages' information belong specifically to the orientation widget.
• Reference ARIA17: Using grouping roles to identify related form controls

4. Navigation elements must be consistent within VA.gov defect-level-1 ❗️

Currently, the orientation widget uses the "back" and "continue" buttons present in the form system. This may prompt screen reader users familiar with using VA forms online to expect that there are fields to be completed instead of just plain text and videos. This may result in them relying on the tab key to navigate, thereby missing all important information within the widget's pages.

In order to solve this, the team should use an alternative method of navigation that is not identical to the form system as it is not a form. For example "Continue Reading" instead of just "Continue" may make it more clear that fields are not being saved, and that they are expected to be parsing through text content.

5. The browser history MUST be updated if users expect to be able to use the browser "back" button defect-level-1 ❗️

Users may become frustrated if they lose their progress in the orientation widget should they use the browser back button to go back one step as opposed to the previous button in the widget.

Alternatively, making this more explicit by as a carousel or slideshow (e.g. using aria-roledescription="carousel") along with previous slide and next slide buttons could also do the trick.

e.g.

Note on "must" recommendations

A11y specialists strongly recommend that the VR&E orientation widget should be placed on its own single page separate from the wizard itself as it would elegantly solve 3 out of the 4 launch blockers listed above. The recommendations we have provided earlier are to be noted as short term solutions in order to meet launch deadlines and basic compliance.

Should

Buttons should not be styled as links and links should not be styled as buttons defect-level-3

"Apply for Veteran Readiness and Employment" at the end of the VR&E orientation flow is a primary green button which is inconsistent with its link form in the grey box above the VR&E orientation.

Consider

• In a future iteration, discuss with the stakeholders the possibility of moving their content around.
• Josh has comments below that should help describe some of these issues, we should reach out to him to review these, if needed.

Acceptance Criteria

• Address "Must" items mentioned above, or note as platform requirement to complete:
  • [x] 1. Content being added or removed from the page must announce a change to assistive devices
  • [x] Request assistance from platform
  • [x] 2. Important unfocusable text in forms must be announced
  • [x] Request assistance from platform
  • [x] 3. Visual groupings must be clear to screen reader users
  • [x] Request assistance from platform
  • [x] 4. Navigation elements must be consistent within VA.gov
  • [x] Request assistance from platform
  • [ ] 5. The browser history MUST be updated if users expect to be able to use the browser "back" button
  • [ ] Request assistance from platform
• [x] A PR has been requested for merging

[jason-gcio]

For number 4, there is probably a multi-step approach: adjust the name of the button, but also look again at tab focus to be placed on the H2 after progression.

[jason-gcio]

Number 1 may need to be done at the platform level as it is out of our scope.

[joshkimux]

For number 4, there is probably a multi-step approach: adjust the name of the button, but also look again at tab focus to be placed on the H2 after progression.

Correct! Adjust the names and actually set tab focus to the new h3s as the h2 "VR&E Orientation" will be consistent throughout.

[joshkimux]

@jason-gcio , added another launch blocker which may be easier to describe over a call sometime. I'll need to do a little bit more research on this to see if there's an easier short term fix.

[joshkimux]

@jason-gcio

Here's an example of how this might look like post the following changes:

• Add role="group" to the wizard and wrap orientation in a section with aria-labelledby pointing to their respective headers. This will help screen reader users understand that these are two separate sections on the page. View below video from :37 to :40. Edit: will need to play with this more as it seems like there is already a section here, making this an article and attaching role="article" seems to do the trick in adding it to the landmarks list in the rotor.
• Use aria-describedby to announce important unfocusable text in the form. From :16 to :22 and from :24 to :28.
• Change copy of "Start VR&E Orientation" to "Start VR&E Orientation Slideshow" so it is more clear as to how this widget will operate.

https://user-images.githubusercontent.com/14154792/112011056-43dfd180-8afe-11eb-997e-670489f00183.mov

As for each of the slides specifically:

• Change language of buttons to "Next slide" and "Previous slide" to make it more clear to users that this is not a form
• Keep the "VR&E Orientation" h2 persistent on all pages as it labels the orientation widget and provides important context to screen reader users
• Bump down the slide titles to h3s and send focus to them upon clicking "next" and "previous" slide buttons
• Add "slide x of y" that is linked to the h3 using aria-describedby

https://user-images.githubusercontent.com/14154792/112014542-61626a80-8b01-11eb-84f2-3219a98f0e2f.mov

[micahchiang]

@joshkimux @jason-gcio - I've created a draft PR here to incorporate as many of the a11y fixes suggested in this ticket as possible. Hoping to use that PR as a place to gain an extra pair of eyes from @joshkimux for feedback and collaboration as the work progresses.

[micahchiang]

Addressed point number 2 in this commit

[micahchiang]

Added step counter, updated button text, and added persistent H2 in this commit

[micahchiang]

Went with the recommendation to add aria-roledescription="carousel" as opposed to fiddling with the browser back button. Effort there doesn't seem feasible right now, but possibly moreso if we end up exploring a separate page for the orientation at some point.

[joshkimux]

@micahchiang Thank you :D Fingers crossed a separate page will happen in the near future as it's the most accessible option

[joshkimux]

Confirmed that Micah has successfully completed the acceptance criteria! Well done 🥳 🥇

[jason-gcio]

@noahgelman - per our conversation about #5, we are going to try a few solutions (page injection first, then maybe a new dedicated Drupal page, conversations with platform support, etc). We recognize the importance of this and want to make sure we keep sight of it. It was noted that we might be in production when the ultimate solution is implemented. Thanks again for your help with all this!