[a11y post-MP Support] MHV to VA.gov Secure Messaging

[underpaid1ntern]

Post-Midpoint/Pre-Staging Findings: a11y Mini-Swarm

Details can be found, along with images and recommendations in this Google Doc. Mark as done as you complete these items. Sketch Prototype link as of 3/30/2023.

• [x] Issue 1: Major (2): When navigating using the 'enter' key on any links within the single page application flow within secure messaging, focus is not managed. Screen readers users will not have a consistent navigation experience.

  • [x] Recommendation given via Slack and Comments in this ticket

• [X] Issue 2: Critical (1, LB): Folder input field, folder name does not have a label

  • [x] Additional Modal Discussions

• [X] Issue 3: Major (2): Visible focus wraps on an un-interactive element with an interactive element within it in sight. (Unable to recreate likely fixed by DST.)

• [X] Issue 4: Minor (4): tab-index="-1" is not removed after being applied or is not needed at all.

  • [ ] BUG TICKET NEEDS TO BE LOGGED @coforma-terry @SarahKay8 see 4/10/2023 in comments for this DST issue

• [X] Issue 5: Major (2): Upon clicking "save," focus remains on the save button and not the input with the issue. Alert and status messages aren't announced without receiving focus.

• [X] Issue 6: Major (2): Close button for notification is missed upon first tab when focus is sent to the error alert. Screen reader users may never know that the close button exists and keyboard users may think they cannot access it. Focus is not predictable / logical

• [x] Issue 7: Major (2): Upon closing the alert, focus is lost. Navigation mechanisms aren't consistent across pages. After the alert is closed, the focus should return to the thing that triggered the alert. In this case “Edit folder name”

• [x] Issue 8: Critical (1, LB) Aria label is an ID and not the actual visible label. Labels or instructions aren't provided when content requires user input. (Small tip: small tip: you don't need dashes between aria labels here! It makes them a little easier to type out.) The aria label is currently written like an ID with hyphens. Aria labels can be a single word or a phrase/sentence with spaces.

• [x] Issue 9: Search Button - It's similar. #8 is about the text input field for the search, this one is the search button that is next to the text input field. Critical (1, LB): Button is an ID and not the actual visible label. Labels or instructions aren't provided when content requires user input.

Midpoint Review Known Issues

Collaboration Cycle: Midpoint Review Ticket for MHV to Va.gov Secure Messaging

• [X] Issue A: Updating Keyboard/Tab order throughout the experience to match the designs
• [X] Issue B: Conversation Link Aria Identifier for List Components
• [X] Issue C: Attachments errors in inline format (Compose and Draft Message)
• [X] Issue D: Validate we are using the correct icons
• [X] Issue E: Accessibility Feedback - Multiple error response in form. An experimental pattern exists for error summary (created by Robin Garrison) - shared pattern with Joel Calumpong 3/23/2023.
• [x] Issue F: + Loading More Messages button/link issue: Brian made with the link/button issue: Inconsistent button/link guidance on the "Navigate a long list" pattern #1613 and relates to DST.
• [x] Issue G: "screen reader-only" h2s to help screen reader users parse a page
• [x] Issue H: Affordances and screen reader content for message threads

Design Review

Based on the development of the prototype, some of the following may or may not be applicable.

• [ ] Color and contrast checks
  • [ ] WCAG 2.1 AA
  • [ ] WCAG 2.1 AAA
  • [ ] Who Can Use
  • [ ] High Contrast Mode
• [ ] Keyboard navigation
  • [ ] Annotations for Tab order, reflow and reading order (if needed)
• [ ] Accessible Name Annotations
  • [ ] Alt attributes for images
  • [ ] Text alternative for complex images such as charts graphs maps etc.
• [ ] Language (ease of reading)
• [ ] HTML Tags
  • [ ] Page Title
  • [ ] Heading order
  • [ ] Annotations (if needed)
  • [ ] Semantic Consideration for paragraphs ordered lists numbering
  • [ ] Tables (heading rows)
• [ ] Size of clickable areas

As Time Allows

• [ ] Components follow VA design system guidance.
• [ ] Patterns follow VA design system guidance.

Original Ticket

Previous Ticket Name

ARIA-content help from MHV to VA.gov Secure Messaging

• Consolidated for pre-staging midpoint review.
• Additional findings are a response to the mini-swarm a11y findings on 3/29/2023.

What does your team need support for? Check all that apply.

• [ ] Launching one or more unauthenticated pages, online forms, apps, or tools on VA.gov
• [ ] Making revisions to one or more existing VA.gov pages
• [X] Something else

We have a few "MUST" accessibility feedback items from the collab cycle midpoint review that require ARIA labels, therefore, we need Content's support in defining the language to use. Needs include:

• "screen reader-only" h2s to help screen reader users parse a page
• Affordances and screen reader content for message threads
• screen reader content for conversation links (creating unique identifiers)
• Aria-live content for "load more messages" design pattern

Will this new product be released incrementally (for instance 25% of users initially)?

• [X] Yes
• [ ] No

There is a phased launch. Phase 0 will have a whitelisted set of users.

Note: If you checked yes, we'll reach out to discuss details about the content in the react widget.

When do you expect to launch your product to 100% of users?

TBD, but current estimate is Q2 2023.

Supporting artifacts

Please provide supporting artifacts as available.

• Link to product outline: https://github.com/department-of-veterans-affairs/va.gov-team/blob/master/products/health-care/digital-health-modernization/product/product-brief.md
• Link to or attach user flows: https://miro.com/app/board/uXjVPBT8RyI=/?moveToWidget=3458764545447678558&cot=14
• Link to prototype or mockups: -"screen reader-only" h2s: Conversation list block | Most-recent Msg block | Drafting reply block -Affordances and screen reader content for message threads: Green comment #4 -screen reader content for conversation links (creating unique identifiers): Blue comment #3.1 -Aria-live content for "load more messages" design pattern: Green comment #6
• Link to any epics/issues that may be helpful: Midpoint review accessibility feedback ticket

  Will this work be going through the Collaboration Cycle?

• [X] Yes
• [ ] No

When does this work need to be done?

• Estimated launch date: Phase 0 launch - Sometime between 3/22 - 4/4
• Estimated staging review date: Sometime between 3/22 - 4/4
• Content and IA work needed by: ASAP - sorry, I know that's not ideal, but we didn't understand it was a requirement for Content to supply ARIA labels, and we have development work that needs the approved aria-content in order to be completed.

Do you plan to bring this to an upcoming content office hours session?

• [ ] Yes, benefit content office hours (Thursdays, 3:00 p.m. to 3:45 p.m. ET)
• [ ] Yes, health content office hours (Thursdays, 11:00 a.m. to 11:30 a.m. ET)
• [ ] Yes, unauth office hours (Mondays, 11:00 a.m. to 11:30 a.m. ET)
• [X] No, but I'd like to schedule time to talk about this request
• [ ] No, let's work asynchronously and meet if needed

Note: If we think this work would benefit from a collaborative session with you, we may ask you to bring it to office hours or set up a separate time to meet.

About your team

• Team name:
• OCTO-DE product owner:
• Product manager: Marci McGuire (Health Modernization Product Spike Team) / Bryan Riley (MyHealtheVet team)
• Designer: Jessica Robertson, Joel Calumpong
• FE engineer: TBD
• Product/team Slack channel: #mhv-secure-messaging

Next steps

Once you’ve submitted this ticket, please post a link to this issue in the #sitewide-content-ia Slack channel and tag Randi Hecht.

If you also need engineering support from the Public Websites team, fill out their intake request form.

If you need a page/URL redirected, a URL changed or a vanity URL set up, please submit a Redirect, URL change, or vanity URL request

[sara-amanda]

@RLHecht I tagged myself and @laurwill on this ticket, based on conversations today with Joel Calumpong, Colton Bunney and and Oleksii Morgun in Slack. I also added the tag for sitewide accessibility.

[sara-amanda]

mhv-secure-messaging thread

SM Smaller Inquiries

Inquiry made about the +5 counter capabilities to read out if there is less than 5 messages are available to load. Discussing text/aria label can be customized to read if there are less than 5 messages.

SM Capabilities

Both link and aria-label can be customized. In fact, we are receiving all thread messages in one call, so we don't need to query backend for that info. This doesn't affect performance. This should be an unsophisticated change on our end.

SM Accessibility and Content

Feedback requested on this item as well as the above ticket request, prior to implementing.

cc: @SarahKay8

[sara-amanda]

ARIA ISSUE FOR MORE MESSAGES

@underpaid1ntern We found Alex’s ticket #23559 - we double checked to see if it is working as expected; it does not appear to be. This was reviewed with @briandeconinck. It appears to be blocked by the ticket Brian made with the link/button issue: Inconsistent button/link guidance on the "Navigate a long list" pattern #1613 and relates to DST.

Recommendation

After discussion this further with @briandeconinck, please follow the design system guidance as best you can and any problem that conflicts with the design system guidance is considered outside the scope for what designers can fix.

It might still get flagged as an issue, or a launch blocker at staging; however, if it is not something you have control over it is something that will get passed along for fixing.

[sara-amanda]

Closing this ARIA-content help ticket, since it relates to an item beyond the scope of the project, as commented above on 3/17/2023.

[underpaid1ntern]

Hi @sara-amanda , noted this ticket was closed. Can you please help me understand the content help deliverable for this ticket and reason for closing it? I'm afraid there may be a misunderstanding about what the request was seeking. I had marked the desire to schedule a meeting because I felt the issues would benefit from a conversation. I may have missed documentation outlining if I needed to then follow up on Slack with someone?

In the original request I linked screens with specific comments highlighted which helped identify where the content needs are. For example, this line...

-"screen reader-only" h2s: Conversation list block | Most-recent Msg block | Drafting reply block

...details the screens and areas where we were looking for assistance for content concerning screen reader sections. In the past, we'd normally receive comments directly on sketch screens which provided the content feedback needed. As of this comment, there are no comments on the screens that seem to map back to the content needs of this ticket.

Also, we sometimes receive word docs for the content handoff. Please let me know your thoughts.

I'm worried that without specific guidance, our aria labels will not be content style guide compliant. Thank you!

[sara-amanda]

Status of ARIA-Related Ticket Items

@underpaid1ntern - No worries, I can reopen this ticket if you feel it is not completed. Here is an update below. Let me know if you have any questions, and if you would like to keep this open, or close it, relating to the ARIA labels. Should you need to contact my CAIA content colleagues, they have been splitting tickets out based on IA, Accessibility and Content needs, we can get you a content-specific ticket, if one is needed, just let me know. We are refining the new CAIA process, so my apologies for any disjointed, bumpy steps along the way. I have included some resources relating to ARIA labels and content as well.

Original Ticket Items to Address 🎟️

We have a few "MUST" accessibility feedback items from the collab cycle midpoint review that require ARIA labels, therefore, we need Content's support in defining the language to use. Needs include:

• "screen reader-only" h2s to help screen reader users parse a page
• Affordances and screen reader content for message threads
• screen reader content for conversation links (creating unique identifiers)
• Aria-live content for "load more messages" design pattern

"screen reader-only" h2s to help screen reader users parse a page :accessibility: 🖥️

My apologies, it appeared this was being handled based on this comment in the MP review ticket, pasting below for reference, along with full recommendation for heading approach:

_BR - above items in progress and will schedule meeting with Accessibility contact. Story created in MHV backlog to update keyboard tabbing/navigation_

• Midpoint Review - Accessibility Feedback - VFS MHV Secure Messaging, MHV Secure Messaging, Secure Messaging #51913

⭐ However, if it is not, just let me know the link to what BR created, and I can take a look. 🙌

Overview of Next Steps

• Users need a way to jump around your page with visible (or hidden) headings.
• To accomplish this we need those added. Aria for the hidden items.
• Brian suggests a good exercise to come up with them. If you need assistance, let me know. Happy to help.

  Here are some resources as well:

• An accessible name serves two primary purposes for users of assistive technologies, such as screen readers:1. Convey the purpose or intent of the element.2. Distinguish the element from other elements on the page.
• Providing Accessible Names and Descriptions
• ARIA Landmarks Example
• Examples by Properties and States

Looking at your Miro Board

• On your Inbox page (as an example) your H1 is your "Inbox"
• Based on this, the H2 would be something along the lines of: Filter Messages in your [h1] like you have there currently (i.e. Filter messages in your Inbox; Filter messages in your drafts) etc.
• The next H2 you have on there would be the messages/conversations section, think jumping around the page section to section for a user with screen reader or other AT. So, how would you refer to that section? Right now you have: Conversations in your [h1] (i.e. Conversations in your inbox). You could also try: [h1] Conversations, so it would read: Inbox Conversations, Draft Conversations, and Sent Conversations? Messages in this Conversation [Number Goes Here]
• For the "Showing 1-10 of 20 conversations" you might consider making that an H3, along with "Show messages in this order" as an H3, using your aria labels.That would make these headings visible to AT for navigational purposes.
• In the messages themselves "attachments" can be a visually hidden header as well.

Note: This is all assuming the [h1] is the page's h1 it is pulling in.

MP Ticket Guidance re: Headings

Here is the detail from Brian's MP Review Ticket, below that goes into detail how you should approach these.

Many screen reader users navigate by pulling up a list of headings and then jumping directly to the heading that describes the section they want to go to. (Example: I want to go straight to my most recent messages in the inbox, and skip over the search entirely.) There are not very many headings in certain screens of your prototype or in what Matt has proposed, which means screen reader users may need to do a lot of manual exploration to find what they're looking for. This can be resolved with visible headings on the page, or by adding headings that are visually hidden but still exposed to screen reader users. Either way, there needs to be a more robust heading structure to facilitate navigation.

I can help with this too (or any other a11y specialist), but here's a good self-assessment you can do: Find a friend who hasn't seen the prototypes and describe it to them without showing it to them. Don't describe in terms of layout ("On the left..."), but in terms of relationships ("In that section, there's also..."). Then have that person make a structured outline (think high school English class, outlining an essay) that matches how you've described the prototypes and the relationships between items on the page. Work with them to clean up the outline, which will then tell you what your big sections and subsections should be. Then give each section/subsection a heading.

Once you have your outline/heading structure determined, do a tabletop exercise with someone -- again, without showing them the prototype. Ask them to complete a task, and have them tell you which heading they would jump to if they wanted to complete the task. Adjust the heading structure based on how they do with the exercise. BR - above items in progress and will schedule meeting with Accessibility contact. Story created in MHV backlog to update keyboard tabbing/navigation

Affordances and screen reader content for message threads 🧵

There was a meeting held on March 24, with Brian, Ryan, Mark and Colton, and they discussed approach and this solution and Ryan is working on it.

Here are my 3/24 notes: 📝

• Accordion component you can specify the heading level assuming H3, you can also tell it to open/close. Pull up the list of headings. Can count through messages and go back six messages, don’t need any extra structure.
• Keep month as the whole word.
• Timezone can be dropped or abbreviated.
• It is important to make sure you are setting up the user for a good match for the first couple of words it is saying.
• Attachments (visually hidden header) - use CSS to hide it from all users, except screen reader users.

Since then, in the March 29 meeting during the round-robin updates for the MHV Weekly Design Review there was another update, so this appears to be moving forward and addressed as well.

Here are my 3/29 notes: 📝

UCD - waiting to hear back about the new thread design needs concerning the accordion component - launch blocker. Working with Jonathan Nelson for preferences SM; Triage moving into a technical feasibility meeting (admin portal and basic barebones tech feasibility for naming structure); Mass move design - presenting the lo-fi concept shortly.

⭐ Current Sketch file from 3/30/2023

Screen reader content for conversation links (creating unique identifiers) 💻 :accessibility:

To my knowledge, this item is being addressed, with the item above. If that is incorrect, please let me know and we can look into this item further.

Aria-live content for "load more messages" design pattern ➕ 📩

• We found Alex’s ticket #23559 - we double checked to see if it is working as expected; it does not appear to be. This was reviewed with Brian.
• It appears to be blocked by the ticket Brian made with the link/button issue: Inconsistent button/link guidance on the "Navigate a long list" pattern #1613 and relates to DST.🛑

Recommendation for "Load More Messages" ✉️

• After discussion this further with Brian, please follow the design system guidance as best you can and any problem that conflicts with the design system guidance is considered outside the scope for what designers can fix.
• It might still get flagged as an issue, or a launch blocker at staging; however, if it is not something you have control over it is something that will get passed along for fixing.

[oleksii-morgun]

Hi @sara-amanda could you please provide more specifics as to "load more messages" issues you see. We tested this with our SQA team on both platforms, and it was meeting the criteria. Unless we don't fully understand the requirement

[sara-amanda]

Hi @oleksii-morgun-va - yes, happy to. We are concerned that the current implementation won't read out on different screen reader/browser combinations, can you provide us with a URL to test this? We are going off of the code in your ticket 23559 and the Miro. If we can have a staging link and steps to replicate, we can dive in a little deeper.

[oleksii-morgun]

@sara-amanda this code is currently in staging. the url is /my-health/secure-messages/thread/:messageId messageId would vary depending on which user you are logging in with, you wold need to retrieve a message thread that contains more than 6 messages

[sara-amanda]

RE: Loading More Messages

Screen Readers

• Looking at the code in GitHub on Ticket #23559 aria-label on an empty div might not get announced<div role="alert" class="sr-only">X more messages are loaded.</div> is probably a better pattern here.
• It hasrole="alert"you should probably use the aria-live="polite".
• But we would still like to confirm that with an actual page to test in Stage. I see you sent the link. Thank you! I will take look.

Content for Loading More Messages

Language can likely be modified.

• "X more messages are loaded" is probably sufficient too for screen reader users to know what to do next, and specific instructions to tab don't make sense in a mobile context.

cc: @briandeconinck @joshkimux (edited)

[sara-amanda]

CAIA Note

@coforma-terry @SarahKay8 I am currently working with @oleksii-morgun-va and @mdewey on the additional a11y findings, related to this ticket and others that were identified.

Ticket Update

I am going to relabel this ticket to cover the a11y issues for Secure Messaging, as a whole. We are using the Google Doc shared from the a11y review session, which includes a11y feedback and next steps.

OOO

I will be out of the office 4/11; returning 4/19, so I wanted to update you both on this ticket for coverage. Thanks!

[sara-amanda]

Ticket Updates

@oleksii-morgun-va @mdewey @SarahKay8 @coforma-terry I updated the ticket body with issues 1-9 from our mini-swarm Google Doc, linking to the Google Doc, in each issue, as well as the Midpoint items A-H, linking to those in the document as well as providing a link to the MP ticket.If you would like to check these boxes off as you make your way through them.

[sara-amanda]

CAIA Ticket Updates

• Issue 3 resolved
• Issue 6 resolved
• Issue 4 - marked done as it is a non-MHV Issue: The tabindex="-1" is a minor issue that looks like it can only be solved by the design system, and is really more code centered. Not a priority for the MHV team. @jeana-adhoc is going to connect with Jared or Robin this week (week of 4/10/2023), to see how they might suggest we address this, so removing from the list and marking it as done.

All of the above will be updated in the working Google Doc as well.

cc: @coforma-terry @SarahKay8 @oleksii-morgun-va @mdewey

[oleksii-morgun]

• Issue 2 - resolved

• Issue 5 - resolved

  Pull Request

[oleksii-morgun]

Issue 7 - resolved here https://github.com/department-of-veterans-affairs/vets-website/pull/23885

Issue A was addressed here https://github.com/department-of-veterans-affairs/vets-website/pull/23661

Issue C was addressed here https://github.com/department-of-veterans-affairs/vets-website/pull/23804

Issue D per this task we validated we are only using icons supported by the Design System throughout the experience

[sara-amanda]

CAIA Ticket Updates

Issue 1: Inquiry

Vic Saleem 4/21/2023 via Slack

Could you please offer additional guidance on how our team should handle Issue 1 from the Midpoint Review doc.? In keeping with the recommended standards, our team has found a way to ensure that when a user clicks a navigation link from the left-nav, the screenreader’s focus should then revert to the H1 tag.

However, the ‘Skip to Content’ section notification which takes precedent at the top of the page after screen renders.

Should we have the screenreader focus on to the ‘Skip to Content’ section first ? Or solely on the H1 tag? 

Issue 1: CAIA Recommendation

Hi Vic, it is my understanding that the change would need to be clearly announced, if the focus is set to the <h1>.

After the page is loaded (and after the intermediate announcements while the page is loading), an announcement should be made for the <h1>heading.

Experience Standards:

• Category 11 Issue 12
• Assistive tech and device support
• Functionality, a11y
• Severity: LB
• Standard (the expected behavior): An option for skipping to primary content is included.
• WCAG 2.4.1 (Bypass Blocks - Level A)

  "A mechanism is available to bypass blocks of content that are repeated on multiple Web pages."

• This does not necessarily require that a skip link be present.
• Beginning the main content with an <h1> or using a <main> region would be a sufficient "mechanism".
• However because neither of these techniques are highly useful for sighted keyboard users absent a screen reader or specialized software, a skip to main content link is strongly recommended for optimal accessibility on pages with repeated navigation.

Reference Items: Related Ticket & Slack

• Take a look at this ticket where it shows you the optional steps to be thorough and confirm h1 is announced on every page.
• Slack thread feedback re: h1

[sara-amanda]

CAIA Update

Issues Resolving this Week

4/26/2023: Alex is set to close more issues. The last few are about to get through testing and merged.

Outstanding Issues

4/27/2023: As of 9 a.m. Thursday, the following 9 issues need attention in this ticket; however, some are being resolved this week, per @oleksii-morgun-va, so this list will be significantly reduced after those items are merged.

Issues Linked in this Ticket

Remaining Mini-Swarm Issues

• Issue 1
• Issue 8
• Issue 9

  Remaining Midpoint Issues

• Issue A
• Issue B
• Issue C
• Issue F
• Issue G
• Issue H

Accessibility Assistance

• [x] @AngelaFowler82 is joining MHV to assist with the accessibility work.
• [x] Adding Angela to this ticket.
• [x] Angela is joining MHV to assist with the accessibility work. Initial meeting 4/26/2023 to discuss the project.
• [ ] Angela is going to take a look at it starting the week of May 1, 2023, to allow time to close the remaining items @coforma-terry .
• [ ] @SarahKay8 and myself @sara-amanda are also available to assist here and assisting with other MHV projects.

[oleksii-morgun]

Issue A was addressed here department-of-veterans-affairs/vets-website#23661

Issue C was addressed here department-of-veterans-affairs/vets-website#23804

Issue D per this task we validated we are only using icons supported by the Design System throughout the experience

Per comment above, Issues A, C, D were addressed. Please confirm if Issue B is still relevant as we are migrating away from the custom component to a design system accordion

[sara-amanda]

CAIA Update

4/27/2023 1:23 p.m. EST

We are down to six issues, with the potential to reduce down to 5. See below. : )

Remaining Mini-Swarm Issues

• Issue 1 - should be resolved with this comment.
• Issue 8
• Issue 9

Remaining Midpoint Issues

• Issue F
• Issue G
• Issue H

Re: Issue B

@oleksii-morgun-va: RE: "Please confirm if Issue B is still relevant as we are migrating away from the custom component to a design system accordion."

Thank you for the ticket updates!

Yes, if you are using a design system component for Issue B, I think you should be ok, so long as the additional considerations, for when you use the recommended component, are taken into consideration. However, you may have already done this step, since these were provided by @briandeconinck.

• The existing accordion component has an unambiguous string of text that's associated with the action of opening/closing the content.
• Even if you also show some kind of message preview, there needs to be a clear control with visible text associated with each message when it's collapsed and when it's expanded.
• Just a note for coding that the "Load more messages" action is going to need some kind of aria-live element for announcing the new content added to the page.

cc: @AngelaFowler82 @SarahKay8 @coforma-terry

[sara-amanda]

The accessibility testing artifact #57585 was created by @bryan-riley-va in preparation for the staging review. Should our assistance be needed, I went ahead and tagged us all in it and added it to the CAIA tags. Feel free to review the comments in the ticket itself.

cc: @AngelaFowler82 @SarahKay8 @coforma-terry @briandeconinck

[underpaid1ntern]

Remaining Midpoint Issues

• Issue F
• Issue G
• Issue H

Hi @sara-amanda , Just noting that these issues are closed for us now:

Issue F: should be resolved

Issue G: Team has implemented this advice to our pages

Issue H: Resolved by moving to accordion - and using aria guidance received via slack

Thanks for everyone's help!

[sara-amanda]

CAIA Update

Outstanding Issues

4/28/2023: As of 3 p.m. Friday, the following three issues are listed as open in this ticket. Once marked as done, we can close out this ticket. Thank you, everyone, for your help!

Issues Linked in this Ticket

Remaining Mini-Swarm Issues

• Issue 1 - should be resolved with this comment
• Issue 8
• Issue 9

cc: @coforma-terry @AngelaFowler82 @SarahKay8 @oleksii-morgun-va @underpaid1ntern

[sara-amanda]

Hi, @RLHecht this will likely be closing soon, so it is on your radar to move to validate status.

[AngelaFowler82]

What test users can I use to validate these fixes once murged?

[oleksii-morgun]

What test users can I use to validate these fixes once murged?

@AngelaFowler82 you can try with vets.gov.user+41@gmail.com

[oleksii-morgun]

Issue # 1 resolved with the following PR https://github.com/department-of-veterans-affairs/vets-website/pull/24017

[AngelaFowler82]

Hello all, I'm attempting to verify the fixes on staging, and when I try to access "compose message" or "inbox" I get a network error. Has everything murged?

[oleksii-morgun]

Hello all, I'm attempting to verify the fixes on staging, and when I try to access "compose message" or "inbox" I get a network error. Has everything murged?

@AngelaFowler82 The link you are attempting above is for a lower testing environment of MyHealtheVet website which is an old experience of SM and is only accessible on VA VPN. For the scope of testing this migration project, you can access Secure Messaging on staging environment at https://staging.va.gov/my-health/secure-messages/. I mentioned on slack channel that at this moment, API services are down, although you should be able to log in, you will experience technical issues until resolved by MHV Platform

[AngelaFowler82]

Ok, thank you. I'll hold off until those issues are resolved.

[sara-amanda]

Bug Ticket

Following up on: Issue 4: Minor (4): tab-index="-1" is not removed after being applied or is not needed at all.

Issue 4: non-MHV Issue

• Thetabindex="-1" is a minor issue that looks like it can only be solved by the design system, and is really more code centered.
• Not a priority for the MHV team. @jeana-adhoc is going to connect with Jared or Robin, as time allows, to see how they might suggest we address this.
• Information taken from 4/10/2023 notes.

Bug Ticket Needed?

Bug Ticket Template for this DST issue.

Update 5/8/2023

Per @jeana-adhoc - Looking in storybook it does seem that this is how the component is built. You open a modal, and tabindex=-1/focus is assigned to the close button, and not the h1/modal title

cc: @AngelaFowler82 @joshkimux @jeana-adhoc @oleksii-morgun-va

[AngelaFowler82]

Looks like the API is having issues again. I was however able to take a look at the application and have a few preliminary findings. Focus is managed far more consistently, generally landing on the h1 when the user clicks a link. The only exception I saw is when they clidk on "Messages" in the menu. In that case focus dropps to "sent messages." There are a number of links in the folders list which aren't labeled properly. There is a button consistently located at the bottom of pages which JAWS identifies as "unlabeled 0." Perhaps we can circle up for a quick screen reader demo and I'll show you what I'm referring too?

In the message folders, Filter Messages is an h3, it should be an h2.

I was able to confirm that when sending a message, the focus issue associated with the Save Draft option is fixed, focus moves to the h1.

When I generate an error message when sending, focus is placed on Close, however when I close the alert focus is still lost. Today is pretty booked, but I'd be happy to meet at your convenience this week.

[oleksii-morgun]

Issue 8 and Issue 9: were resolved as a part of the following Pull Request

[oleksii-morgun]

Per our conversation with @AngelaFowler82 on May 10, we were able to determine the following:

There are a number of links in the folders list which aren't labeled properly.

This turned out to be that folders themselves were named in a weird pattern, someone previously tested long names in "unconventional" format like "TEST123TEST123TEST123" etc. We established this is not a labeling issue, does not affect accessibility.

There is a button consistently located at the bottom of pages which JAWS identifies as "unlabeled 0."

We determined that this was on a component which does not have aria-labels and removes inner text when a user is on a narrow screen. This needs to be filed as a bug with DST as this is a site-wide impat. On SM end, we are adding an aria-label to resolve.

In the message folders, Filter Messages is an h3, it should be an h2.

We need to make the changes as per this comment, as some heading levels are skipped. We will do another sweep across entire application

When I generate an error message when sending, focus is placed on Close, however when I close the alert focus is still lost.

We confirmed this is an issue, Angela provided feedback on preserving the focus

Will update here as these fixes are deployed to staging.

[sara-amanda]

Thank you @AngelaFowler82 @oleksii-morgun-va @underpaid1ntern @RLHecht / @coforma-terry - waiting on fixes to deploy in staging (see above).

[oleksii-morgun]

@AngelaFowler82 We have implemented changes for heading to be in a proper level sequence and maintaining a focus position after closing error alerts or modal on "Compose Message" or "Reply message" views. These have been deployed to staging

https://github.com/department-of-veterans-affairs/vets-website/pull/24234

[AngelaFowler82]

Hey guys, you may simply not have merged this yet, but on the new message page "start a new message" is an h1, as it should be, but the next heading is an h3 "new message." That should be an h2. Other than that, everything looks pretty good from a screen reader user's perspective.

[sara-amanda]

CAIA Note

• Closing as staging review is set for tomorrow, June 1, 2023 at 1:30 p.m. for Secure Messaging.
• Should CAIA or a11y help be needed, we can open up a new post-staging ticket. (cc: @coforma-terry @RLHecht )
• Staging Review for [VFS MHV Secure Messaging, MHV Secure Messaging, Secure Messaging] #51115

[RLHecht]

Thanks, Sara. Closing!

[oleksii-morgun]

Hey guys, you may simply not have merged this yet, but on the new message page "start a new message" is an h1, as it should be, but the next heading is an h3 "new message." That should be an h2. Other than that, everything looks pretty good from a screen reader user's perspective.

Logged to be addressed here https://jira.devops.va.gov/browse/MHV-45263

[sara-amanda]

@briandeconinck ^