Front End: Full VBA regional subsection content

[xiongjaneg]

Description or Additional Context

Some services accordions are at a regional level. See Slack thread

Resources

• VBA Content Specs listed in #13096
• Sketch file

Acceptance Criteria

• [x] Confirm all needed data from the query are brought in.
• [x] The front end shown matches the design file to a reasonably accurate extent.
• [x] Any applicable unit or component testing is completed.
• [x] Any refinements to the front end have been stubbed out in tickets.
• [x] Requires design review
• [x] Requires accessibility review

Team

Please check the team(s) that will do this work.

• [ ] CMS Team
• [ ] Public Websites
• [X] Facilities
• [ ] User support
• [ ] Accelerated Publishing

[xiongjaneg]

@xiongjaneg create follow up ticket similar to Facility ticket. Edit: Done.

[swirtSJW]

To connect the facility query to get the service region, you need to include a reverse entity ref lookup on this field

[swirtSJW]

Here is the relationship diagram for all the connections to the VBA Facility content type. https://prod.cms.va.gov/admin/reports/content-model/entity-diagram/node/vba_facility?max_depth=2

Any connection that is an arrow pointing to the red dot, is a reverse entity reference. Any pointing away from the rest dot is an entity reference. The name on the connectors are the fields that make the conntection.

[swirtSJW]

Actually I need to follow up with @davidmpickett because I think my pointer to the vba_region_facility_list might be incorrect. I won't know for sure until I understand where this data lives on the comps.
Slack discussion

[xiongjaneg]

Screenshot from 16th minute

[swirtSJW]

Followup from 16th minute.

• Service location from Service region display (see screenshot above) should come after service locations that come from services.
• Service location is going to come from the service. There are two possible ways to get the service location. I will outline each of them in a few minutes.

[xiongjaneg]

Blocked in sprint 94 per Slack thread

[xiongjaneg]

Still blocked

• this subsection is one element of the part of the page
• needs page query
• data can be added to demo/integration branch that's part of this

[jilladams]

From 1:1 today, @maxx1128 noted he's gotten Jordan's review via a screencap video (Slack thread), plans to tag @laflannery for review in a Tugboat, and is feeling this may be ready to PR/demo next week.

@maxx1128 pls update if I misstated anything there.

[maxx1128]

@jilladams, this looks accurate to me 👍 My upcoming tugboat instance will also have the service region accordions updated to V3.

[maxx1128]

Update for end of Sprint 102: this ticket is blocked due to some expected merge conflicts with @eselkin's work on facility and regional services. Once that is set, the accessibility review is complete, and any other needed changes are made, this should be able to be completed in the next sprint.

[laflannery]

Headings:

• The first heading in each accordion right now is an h3 but should be an h4. I'm not sure if this is editor content that need to be fixed in a text editor or in the template: "Get help checking the status of your COE", "Vascular Surgery Regional Service Header", "Submit your application by mail", etc.
• The heading for "Can't find the service you're looking for?" there is an outstanding question on what level of heading this should be. @mmiddaugh brought this up in another ticket that I can't find and I would like to know her opinion on h2 or h3 here. The short version is that it should be an h2 in the hierarchy because "Other Services" might not always be present but should we be doing some sort of conditional so that it's at H3 in most cases UNLESS it shouldn't be and therefore won't show in the ToC for the majority of cases?

Phone numbers:

• Can we update the phone numbers within the template to use the aria-describedby variant of the telephone component

[laflannery]

@maxx1128 I have finished my accessibility review, I know you already started looking at/updating based on my comments. I added a note about the telephone numbers to my original comment. I also found the original conversation about the "Can't find the service you are looking for" heading. We don't have an answer quite yet but I did sync with Michelle and this is on her radar. I would hold on this for now until we get direction from her.

[laflannery]

@maxx1128 Final decision on that second header comment is that we have decided to leave "Can't find the service you are looking for" as an h2 - it is a sibling of the other service headings and we should treat it as such. If that means is has to be in the "On this page" component, that's ok

[jilladams]

https://dsva.slack.com/archives/C0FQSS30V/p1706639135108009

tests pass after making banner testing not dependent on the whole page rendering with old data that doesn't match with the way the new data renders.

A11y feedback implemented and available in Tugboat (fyi @laflannery ) for verification, which will happen over S103 boundary.

[laflannery]

@maxx1128 I just reviewed the tugboat again and the headings look good

Some comments on Phone numbers:

• Is the aria-describedby dynamic? Because I have now realized that the editor can set this as the label in the CMS so do we pull this from there so that when they set the label, it will pull as the aria-describedby?
• There are 2 other props that are available in the component sms and tty these should be used when appropriate as well. You have an example of each in your tugboat but are we able to have these set up so whenever the editor choose to add these it will be set correctly?
  • Veterans Pension SMS number
  • Veterans Pension TTY number
• I also noticed that it seemed like not all numbers were update with the aria-describedby attribute. Can you double check that this is set to appear for all numbers (main location, VA Hotline, all service accordions, etc.)

[maxx1128]

@laflannery Looking at these points again this morning:

1. aria-describedby is dynamic. If there's a custom label set in the CMS for a number, that's what's used in the screen reader text.
2. Whenever an editor adds an sms and tty number, they're used along with any other numbers with the same properties and styling. Is there anything specific or different that needs to be done with these types of numbers? In the CMS they have the same list of properties.
3. I double-checked and saw that I missed adding aria-describedby for when it's the facility's phone number. I will add that in now for the next tugboat release.

[laflannery]

@maxx1128 Answers below:

1. & 3. Excellent and Thank you!
2. These properties in the DS component trigger certain things to happen so that they will be displayed/read differently.
   • These differences are:
     • TTY actually puts TTY in front of the number so folks know that this is a TTY number and not just a regular phone number
     • SMS swaps the tel: in the href with sms: so that folks know that this is also not a phone number but rather it should be used as an SMS number
   • If I'm understanding correctly, you are saying that regardless of which TYPE of phone number ad editor selects in Drupal, there is currently nothing unique coming from the query so that we will not be able to differentiate these and therefore set SMS on type SMS and TTY on type TTY?

[maxx1128]

@laflannery That's correct, as things are right now, the SMS and TTY numbers render the same code as the other types. I'll look into getting these changes made for these specific types of numbers.

[laflannery]

@maxx1128 We might want to hold on that and ask @xiongjaneg because it might be out of scope and not MVP for this particular ticket

[maxx1128]

Changing the component based on these types of numbers is just an extra property. I'll try updating the tugboat, it may be an easy win.

[maxx1128]

@laflannery looks like it worked! The extra properties appear on sms and tty numbers but not the others, and they update the markup as expected for each.

[laflannery]

@maxx1128 Regional subsections look swell! :)

[jilladams]

Closing. This has been in prod for end of Sprint 103, verified in staging envs, and will require prod content for prod verification. We can cut new tickets for any danglers.