Note: Delete the description statements, complete each step. None are optional, but can be justified as to why they cannot be completed as written. Provide known gaps to testing that may raise the risk of merging to production.
Are you removing, renaming or moving a folder in this PR?
[x] No, I'm not changing any folders (skip to TeamSites and delete the rest of this section)
[ ] Yes, I'm removing, renaming or moving a folder
If the folder you changed contains a manifest.json, search for its entryName in the content-build registry.json (the entryName there will match).
If an entry for this folder exists in content-build and you are:
Deleting a folder:
First search vets-website for all instances of the entryName in your manifest.json and remove them in a separate PR. Look particularly for references in src/applications/static-pages/static-pages-entry.js and src/platform/forms/constants.js. If you do not do this, other applications will break!
Add the link to your merged vets-website PR here
Then, Delete the application entry in registry.json and merge that PR before this one
Add the link to your merged content-build PR here
Renaming or moving a folder: Update the entry in the registry.json, but do not merge it until your vets-website changes here are merged. The content-build PR must be merged immediately after your vets-website change is merged in to avoid CI errors with content-build (and Tugboat).
:warning: TeamSites :warning:
Examples of a TeamSite: https://va.gov/health and https://benefits.va.gov/benefits/. This scenario is also referred to as the "injected" header and footer. You can reach out in the #sitewide-public-websites Slack channel for questions.
Did you change site-wide styles, platform utilities or other infrastructure?
[ ] No
[ ] Yes, and I used the proxy-rewrite steps to test the injected header scenario
Summary
On our form (which depends on VA Forms Library contact info Array Data), we are hiding content that contains headers. This results in a broken document structure that skips heading levels, which is an accessibility issue.
To fix the problem, this change allows applications to customize heading levels directly in their form configuration
I work for the IIR team which owns the app "Welcome VA Setup Review Information Form", but which does not own the VA Forms Library.
Has the potential to affect other forms using the contact info list-loop, but the new arguments are optional such that without them the standard heading levels are used.
Acceptance criteria
Quality Assurance & Testing
[ ] I fixed|updated|added unit tests and integration tests for each feature (if applicable).
[x] No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs
[x] Browser console contains no warnings or errors.
[ ] Events are being sent to the appropriate logging solution
[ ] Feature/bug has a monitor built into Datadog or Grafana (if applicable)
Authentication
[ ] Did you login to a local build and verify all authenticated routes work as expected with a test user
Requested Feedback
(OPTIONAL) What should the reviewers know in addition to the above. Is there anything specific you wish the reviewer to assist with. Do you have any concerns with this PR, why?
Note: Delete the description statements, complete each step. None are optional, but can be justified as to why they cannot be completed as written. Provide known gaps to testing that may raise the risk of merging to production.
Are you removing, renaming or moving a folder in this PR?
If the folder you changed contains a
manifest.json, search for itsentryNamein the content-build registry.json (theentryNamethere will match).If an entry for this folder exists in content-build and you are:
Deleting a folder:
vets-websitefor all instances of theentryNamein yourmanifest.jsonand remove them in a separate PR. Look particularly for references insrc/applications/static-pages/static-pages-entry.jsandsrc/platform/forms/constants.js. If you do not do this, other applications will break!Renaming or moving a folder: Update the entry in the registry.json, but do not merge it until your vets-website changes here are merged. The content-build PR must be merged immediately after your vets-website change is merged in to avoid CI errors with content-build (and Tugboat).
:warning: TeamSites :warning:
Examples of a TeamSite: https://va.gov/health and https://benefits.va.gov/benefits/. This scenario is also referred to as the "injected" header and footer. You can reach out in the
#sitewide-public-websitesSlack channel for questions.Did you change site-wide styles, platform utilities or other infrastructure?
Summary
Related issue(s)
VA IIR issue 1230
Testing done
Screenshots
There's no visual change.
What areas of the site does it impact?
Has the potential to affect other forms using the contact info list-loop, but the new arguments are optional such that without them the standard heading levels are used.
Acceptance criteria
Quality Assurance & Testing
Error Handling
Authentication
Requested Feedback
(OPTIONAL) What should the reviewers know in addition to the above. Is there anything specific you wish the reviewer to assist with. Do you have any concerns with this PR, why?