Incorrect heading levels on accordions on translated pages

[laflannery]

Description

The <va-accordion> component has the ability to set heading level so that the title of the accordion follows logical heading order within the page structure. The majority of these throughout the site were recently updated based on a CMS audit of where these were located #10486

A couple translated pages seemed to have been missed in the original audit and therefore still have incorrect heading levels:

• The English PACT act page has correct H3s for the accordions but Spanish and Tagalog have H4s
• The English Covid FAQs page has correct H3s for the accordions but Spanish and Tagalog have H4s

Is there a way to determine why there pages were missed and to be sure no other pages were missed from the audit?

Acceptance Criteria

• [ ] Determine if other pages may have been missed from the audit
• [ ] Update heading levels for necessary pages
• [ ] Review with accessibility lead

CMS Team

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

• [ ] Program
• [ ] Platform CMS Team
• [ ] Sitewide Crew
• [ ] ⭐️ Sitewide CMS
• [x] ⭐️ Public Websites
• [ ] ⭐️ Facilities
• [ ] ⭐️ User support

[wesrowe]

@laflannery, what further action is needed to close this epic? Do you want to do some independent verification?

[laflannery]

@wesrowe This is a new issue, after the accordion heading levels were resolved (last sprint I think?) I came across a couple pages where there were still some errors. (See comment here for possible clarification)

Let me know if that helps answer your question about where this issue came from

[wesrowe]

Sorry @laflannery, I mistook this for the defect that started it all (lesson learned again: don't read while talking)

[laflannery]

@jtmst After looking at the conversations you've been having in slack I looked at some other pages and it seems that anything using an accordion group/item still has an H4 heading. Sometimes this is the correct heading, just by nature of the page set up, but often it is not.

Examples of some correct instances:

• English COVID FAQ page:
• About VA Disability Ratings

Examples of incorrect instances:

• This new revision that is currently in draft (it came up in a question in cms-support)
• • English COVID FAQ page I realize I said above this entire page was correct and I apologize for not looking closely enough before:

I wanted to make sure it was clear this wasn't just an issue with translated content

[jtmst]

WIP following conversation around whether or not this should be addressed via passed header levels from cms, or by using existing entity IDs. Current plan is to continue implementation by using known entity IDs for non compliant accordions

[jilladams]

Should we re-point this given the new info / new sprint?

[laflannery]

@jilladams I reviewed the above example pages I had previously identified in this situation and I have a few updates:

• The English COVID FAQ page
  • There is one section that is incorrect here - these accordions should be H3s:
• The Spanish COVID FAQ page and the Tagalog COVID FAQ page
  • All accordions are H4s, this is only correct when the heading immediately above is an H3:
  • Correct:
  • Incorrect: (accordions should be H3)
• About Disability Ratings
  • This is incorrect, the accordions are H3s but they should be H4s are they are under a H3 heading.
  • Also, note that this page was previously correct, see my comment and screenshot from before
• The PACT act page, in all 3 languages, and the preview page I noted are all correct now

NOTE: I just want to reiterate again that these were examples I found, not an extensive list. I am unaware of what is causing this change in header levels so I do not know if I should try and find a list or track down more instances of where these might be used - if that would be helpful let me know.

[jilladams]

Reopening to investigate further.

[jilladams]

Meeting with Laura, Josh, Ryan, Wes & Me:

• We implemented exceptions by hand based on entity ID, in content-build. BUT: There are more exceptions with this issue than we realized, and this approach isn't extensible or going to work.
• Extent of the issue:
  • Laura is tracking ~700 header issues identified by a scan
  • ~75% of those are in VAMC pages, where header levels are entered in rich text editors.
  • The remainder are in, e.g., benefit detail pages, etc.
  • The way accordions are created can be either: QA Section (with header as hard-coded h2), or as Rich Text header followed by an Accordion Group (which doesn't have its own header field). You can see both happening on the English COVID FAQ page (drupal node). In this case, the editor has decided within CMS some heading levels.
• A front-end fix is limited because:
  • Any given accordion header isn't aware of other content on the page to know its own contextual / semantic header level. We haven't figured out a clever way to pass that in.
  • Also, because Editors can create content with incorrect headers in a variety of ways and fields (e.g. QA Section, Accordion group, etc)
• Possible backend fix: Header level could get passed in by the CMS. If we go that route, these instances will need to be edited in the CMS to pass in the explicit level.
  • Leave the FE defaults as fall back, but if the CMS has a header level, pass that in instead. (That CMS logic is new work.)
  • However: this requires Editors to be the ones to correctly decide which level to set.
• Priority: Holistic fix preferred. Laura is reluctant to implement ad hoc fixes that aren't comprehensive, as that may exacerbate the last-known 800 error and increase the count. For now:
  • Laura to raise this as a preferred 508 priority for Q1 2023
  • Laura is trying to investigate the Drupal side pre-save option to flag this for editors
  • And: we need to do this at a time where we can manage CM with VAMC editors.

Work to consider, tbd if we go this route:

• Drupal: add new field to CMS to allow editors to enter heading level as a new field
• Content-build: 1 line change to GraphQL query
• Content-build: update the template
• Content-build: remove the content we added here previously with explicit entity IDs
• Change management: Editor training re: how to set the heading level correctly

[jilladams]

Wes and I talked to @davidconlon about this in sync briefly today. Dave's take:

• Tackle product by product
• Start with something like Resources & Support and/or Benefit Hubs, where the editor audience is small
• Ideally: CMS should be taking structured content and passing to the front-end, without embedded html like heading levels
• Future: front-end needs to be able to handle heading levels bc some of this content will be COPE-ified and be molecular for sharing in other contexts.

He agreed: this is a thing to prioritize for future quarters, may require a working meeting (later, maybe Q1) with Laura / Beth / Danielle to understand how we're solving in content structure / what we're solving for, to back into the fix.

[laflannery]

@jilladams and @wesrowe I was going through my a11y issues to clean them up and I'm closing this as all examples on this page are now resolved now that the plugin is on prod