patch: Align with GDS and Accessibility requirements

[kitttang]

Note

This template is designed to help both contributors and maintainers. It is a checklist to ensure all necessary
information is provided, and prompts contributors on any contribution guidelines they have missed.

Do not remove sections.
They are important for the review process and help maintainers ensure quality and good documentation across the
project.

Some checkboxes will not apply to every change, so feel free to leave them unchecked if they are not relevant.

Description

Context

Changes

• Changing "Fix the following issues" to "There is a problem" to match GDS: https://design-system.service.gov.uk/components/error-summary/
• Changing file error type to capital letters too match GDS: https://design-system.service.gov.uk/components/file-upload/
• Removing duplicates of file types in the error message if there are any like (problem in ukhsa collab version, for example using "application/x-research-info-systems": "ris",
  "text/ris": "ris" would list ris twice)
• Changing "Your file was successfully selected" from an <h2> to <p>. Level A requirement: https://ukhsa.atlassian.net/browse/KLSKAB-2114
• Prevent "Skip to main content" from carrying over to the next page. Level A requirement: https://ukhsa.atlassian.net/browse/KLSKAB-2112

Type of change

What is the type of change you are making?

• Chore or documentation (non-breaking change that does not add functionality)
• ADR (Architectural Decision Record, non-breaking change that documents or proposes a decision)
• Refactor (non-breaking change that improves code quality)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

PR title

PR titles should be prefixed with the type of change you are making, based on the README.md#versioning.
This is so that when performing a squash merge, the PR title is automatically used as the commit message.

Have you updated the PR title to match the type of change you are making?

• Yes
• No, I need help or guidance

Testing

Automated tests

Have you added automated tests?

• Yes, unit or integration tests
• Yes, end-to-end (cypress) tests
• No, tests are not required for this change
• No, I need help or guidance
• No (explain why tests are not required or can't be added at this time)

Manual tests

Have you manually tested your changes?

• Yes
• No, manual tests are not required or sufficiently covered by automated tests

Have you attached an example form JSON or snippet for the reviewer in this PR?

• Yes
• No, any existing form can be used
• No, it is not required or not applicable

Steps to test

1. Upload a file of the wrong type
2. Should display the list of acceptable file types but in caps

Documentation

Have you updated the documentation?

• Yes, I have updated ./docs for this change since additional explanation or steps to use/configure the feature is required
• Yes, I have added or updated an ADR for this change since it is large, complex, or has significant architectural implications
• Yes, I have added inline comments for hard-to-understand areas
• No, I am not sure if documentation is required
• No, documentation is not required for this change

Discussion

Warning

Large or complex changes may require discussion with the maintainers before they can be merged. If it has not yet been discussed, it may delay the review process

Have you discussed this change with the maintainers?

• Yes, I have discussed this change with the maintainers on slack, email or via GitHub issues
• Yes, this change is an ADR to help kick-off discussion
• No, this change is small and does not require discussion
• No, I am not sure if one is required

[jenbutongit]

Thanks for addressing a11y issues. Please could you address the failing unit test now (due to file type capitalisation)

[jenbutongit]

why is this block necessary?

[kitttang]

This bit is for a Level A Focus Order issue:

Activating the ‘Skip to main content’ link on the previous service page takes the user to the beginning of the main content section. As the user navigates through the service, the #main-content fragment is carried forward in the URL. Because of this, screen reader and keyboard-only users may find themselves automatically positioned within the main content on the next page. This prepositioning can be disorienting, as users typically expect to start at the top of a new page, not in the middle of the content.

Solution

Solution: Screen reader and keyboard-only users must not be automatically positioned in the middle of the service page content. To prevent this, ensure that the #main-content URL fragment is not carried forward to the next service page