Forms pattern launched

Patterns
1

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

2

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.).

3

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:

  1. Which keyboard to show on mobiles
  2. Input restriction by type and length
  3. Value validation
  4. Value formatting
  5. Purpose markup
  6. Autocorrection
  7. 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
4

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.

5

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.

6

I think this might be it @tnafoo

1 Like
7

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.

8

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
9

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.

Error messages - SNSW GEL 1
Error messages - SNSW GEL 11726×12748 735 KB

10

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
11

Hi @mike.hall Thanks so much for the form patterns!

What’s your stance on using different lengths for input boxes? An accessibility expert has recommended that we use varying input lengths to signal to users how much information they’re expected to provide. For instance, a shorter field might indicate that only a brief response is required, while a longer field can suggest that more detailed information is expected.

2 Likes