SPIKE: Define long-term solution for setting Accordion header levels

[wesrowe]

Description

We need to pull in multiple perspectives (FE eng, accessibility, BE eng) to determine a sustainable, governable way to ensure that accordion headers are set correctly in the hierarchy of the template they appear in.

High-level requirements of the solution:

• Is not stored in the CMS, as header level is a presentation-level characteristic, per channel
• Does not require a manual step for Editors creating new accordions (e.g., adding entity numbers to a list, etc)
• ...?

Acceptance Criteria

• [x] Follow-up ticket(s) written

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

[laflannery]

Some resources for you:

• Heading export Nate is working on (as it is in progress it could change/not be available)
• Example pages with different violations:
  • https://www.va.gov/alaska-health-care/programs/covid-19-vaccines/index.html (H2 > H4)
  • https://www.va.gov/alaska-health-care/medical-records-office/index.html (H2 > H4)
  • https://www.va.gov/albany-health-care/work-with-us/index.html (so much happening, The accordions should be H2;s since they do come after the main H1)
  • https://www.va.gov/albany-health-care/programs/covid-19-vaccines/index.html (Should be H2s, there is also an incorrect H4 within the content above)
  • https://www.va.gov/albany-health-care/research/index.html
  • https://www.va.gov/erie-health-care/dav-vans-transportation-for-veterans/ (One of the pages I just updated that I knew would be incorrect but had know way to change it)

[laflannery]

Talking with Josh and investigating the proposed solution, I wanted to document that what has been proposed will not impact FE accordions that have been created in Drupal using the Q&A group or Q&A section content blocks

[jtmst]

Spike Findings

The main takeaway for this spike is that we should be able to accomplish much more accurate accordion headers by creating a plugin that modifies the dom after the html files are built in content build. Examples of this being done are in src/site/stages/build/plugins/modify-dom, and the most similar example the developer that works on this could reference would be in src/site/stages/build/plugins/modify-dom/add-id-to-subheadings.js.

Methodology

The plugin we create is going to run alongside the other plugins in src/site/stages/build/plugins/modify-dom/index.js where each html file is stored individually to have these modifications run against them. We are going to need to create logic that finds va-accordion components with the data-template attributes we are targeting (eg collapsible_panel) and works backwards to find the closest previous div with a data-template of paragraph/wysiwyg that contains a header. We can reassign the accordion header levels based on that header.

Potential Issues

• It is still possible for editors to create incorrect header levels on their own eg https://www.va.gov/albany-health-care/programs/covid-19-vaccines/index.html. On this page there is an incorrect H4 header inserted that would result in our accordion header being an H5.
• This approach will help assign levels to accordion components within some data-templates but may require some additional work to accommodate others.
• Some benchmarking and evaluation will need to be done to ensure this doesn't too negatively impact build times

Dev Considerations

• Testing this won't be fun as it this logic will run at the end of content-build's build.
• Benchmarking of build times before and after will be required to make ensure we aren't adding a significant amount of build time
• Testing will need to be extensive, checking that accordions used in a variety of templates are accurate and that no currently correct header levels are changed