I’m pleased to announcer the launch of the forms patterns
https://www.digital.nsw.gov.au/design-system/patterns/forms
As always, any feedback gratefully received
Thanks
Mike
Love you work @mike.hall. Good clean, succinct and easy to consume inforamation.
I think including text input type attribute information might be a good resource to include here (type=“text/email/tel” etc.).
Thanks @Dee
At my previous role, we had the concept of ‘text input helpers’, which included this and other information.
The text input helpers specified the following for each text entry field:
- Which keyboard to show on mobiles
- Input restriction by type and length
- Value validation
- Value formatting
- Purpose markup
- Autocorrection
- Capitalisation
Point 5, the purpose markup handles the type.
This has been added to the backlog for the NSW Design System
Thanks
Mike
1 Like
Hi @mike.hall So glad to see this launched. However, I clicked on the link above to view it but the page doesn’t display. Let me know.
This elaboration is great. Ty, @mike.hall
For 2. Input restriction by type and length. Would it be visual length or actual character count length? We are currently looking at restricting the field length visually so user expects a postcode view is only 4 character long by looking at the length of the field.
Thanks for the great work! It is super helpful.
I have one question regarding the error message design. Why is the validation/error message placed below the input box? Our accessibility expert is concerned that the screen reader will read the entire input field before the error message. Was there a reason behind this design decision? Also, there is no error summary to help users navigate to the error fields quickly. One of the guides from User Notification | Web Accessibility Initiative (WAI) | W3C. When errors occur, it is helpful to list them at the top of the page, before the form.
Hi @mikegu ,
Again, I apologize for not replying sooner on this.
Inline error messages (below the input)
As long as ‘aria-invalid=“true”’ exists on the input and is followed by the error message, it should provide enough feedback to someone that may be using a screen reader.
Understanding the context is key, in terms of usability there’s a couple of best practices around displaying inline error messages:
Error summary
Understanding the context is key, WebAIM mentions that both ‘Summary errors on top’ and ‘Inline errors’ are equally as valid:
‘Each approach has pros and cons and might be optimal based on the content, layout, and complexity of the form.’
https://webaim.org/techniques/formvalidation/#error
Hopefully this helps, always open to any recommendations or suggestions for improvement.
1 Like
Hi @mikegu, there’s also a ‘Error message’ guidance document (see image below) from the NSW GEL Library which could be useful. We only have ‘In-line error messages’ available right now in NSW DS, however, we’ve added to evaluate other methods to our backlog.
Thank you very much for the detailed information on this form validation! It covers almost all the use cases we’re experiencing. I’ll share this with the team and get back to you if we have any additional questions or feedback.
1 Like