Accessability defects on SRS forms - #725
micolgiannelli2 wants to merge 11 commits into
Conversation
| fees: FeesModel | undefined; | ||
| name: string | undefined; | ||
| feedbackLink: string | undefined; | ||
| serviceName: string | undefined; |
There was a problem hiding this comment.
for another example of this functionality view feedbackLink: string | undefined; which is correctly passed in to the view model and gets picked out by the layout here and elswere
| } | ||
|
|
||
| // Helper functions | ||
| const resolvedUrl = (url: string) => { |
There was a problem hiding this comment.
This is form specific overrides in framework functionality.
Re-using cookie statements, probably needs to be designed as a framework feature/functionality.
Something like a form level privacyUrlOverride or so.
There was a problem hiding this comment.
yes so if you see below this was previously resolved with an if/else condition on line 57, I agree this could a wider improvement but I would say moving it here is still an solid improvement to what is currently in the paltform
There was a problem hiding this comment.
I am able to put this in as a service enhancment next week as solutions such as kls which duplicates its pages 4 times (one per form) are not clean
| { | ||
| text: "View cookies", | ||
| href: "/help/cookies" | ||
| href: "cookies" |
There was a problem hiding this comment.
So, its not because if there is no {base-service-ulr}/cookies the the router defaults to /help/cookies
however, if a page does have its own version of cookies set up this should definitely not lead to the default version of cookies


Description
Context
(1) Added service name to be passed through in the summary view model so the layout correctly picks the service name
(2) Included small helper function to allow users to share the same cookie and privacy page across diffrent forms
-> previously one had a singular views folder per form, close contact forms had gone arround this by introducing and if statment that was introducing bugs because it was not picking up newly applied logic
-> I made this more generic and made sure this logic happens at the start
(3) From changes to include autocomplete and small content changes
Tickets
Type of change
What is the type of change you are making?
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?
Testing
Automated tests
Have you added automated tests?
Manual tests
Have you manually tested your changes?
Have you attached an example form JSON or snippet for the reviewer in this PR?
Steps to test
Documentation
Have you updated the documentation?
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?