All themes contact forms A11y updates

[StephDriver]

The contact us form is the only part of the front end which requires user input. It does not currently comply with WCAG 3.3 Input Assistance., among other areas of WCAG.

Non-exhaustive list of issues found so far:

• Material
  • invalid entries identified by colour change (see WCAG 1.3.3)
  • errors are not described to the user in text.
• Clean
  • Invalid entries are not reported to the user (try entering random text in the email field, it doesn't react). They are reported to the screen reader user, but only if they navigate back having left the item. They are reported on landing, not on exiting.
  • the bracketed email address to evade scraping is awkward when read aloud by screen reader - consider how to handle that. without putting the email address into the HTML.
• OLH
  • Page starts with an H4 not an H1
  • Contact form then starts with an H3
  • Invalid entries are not reported to the user (try entering random text in the email field, it doesn't react)
  • Required fields are marked by * which gets read out as 'star' - this should either be marked as decorative and the field marked-up as required, or it should be described.
  • Send message button changes colour on hover, but no non-colour indicator of this.

Note: the Clean contact form works well with voiceover, but doesn't indicate required fields visually (does tell the screen reader!).

[StephDriver]

the bracketed email address to evade scraping is awkward when read aloud by screen reader - consider how to handle that. without putting the email address into the HTML.

This is user content.

[StephDriver]

Need to fix Clean theme, others fix if easy, if not create new issue for later.

i.e. fix: Clean Invalid entries are not reported to the user (try entering random text in the email field, it doesn't react). They are reported to the screen reader user, but only if they navigate back having left the item. They are reported on landing, not on exiting.

[StephDriver]

Following discussion I am retesting these and reviewing the changes required.

Material

• invalid entries identified by colour change is permitted as long as they are also identified in text. But what happens here is that if more than one field has an error, only the first is identified with text, the second remains a changed colour, but no text or other indication of error. ( to reproduce, go to link above, enter an invalid email address and leave subject blank, complete the captcha and click to send).
• errors are not described to the user in text. - the first error is described in a tool-tip like popup, but this goes away if one navigates away from that field, and returning to it does not bring it back, nor does any explanation show for other invalid fields.

could this be solved by putting the error fixing messages into a sibling of the input, and using something like input:invalid ~ .error-fix in the css to show/hide the error fixing messages?

[StephDriver]

this may be useful: https://design-system.service.gov.uk/patterns/validation/