The Australian Government coat of Arms

Communities of practice

Communities of practice

Form page


A generic form page. This is a work in progress and requires more accessibility features.


Nice and simple - good.


Thanks @guiseppe, you can view the work in progress here:

We just shipped an alpha for our templates that can be seen here:


Fantastic work on releasing new templates, I can foresee these being very useful. Congratulations to the team and the contributors :+1:

For the form template, It might be valuable to provide examples of how various validations are expected to be handled. Both inline validation, and server-side/page alerts.

UK’s Design System has excellent examples and docs for both, that don’t rely solely on colour (WCAG 1.4.1) which I would recommend as reference:

I’m also pretty sure @Alzbeta might have access to early GovAU concepts for form validation, or some of my old work-in-progress Sketch-files for how we might add icons for lower literacy ¯\_(ツ)_/¯

Good work so far!


Thanks @treb, we are going to plan the next six months and the form template and missing components will definitely be included.

I will touch base with @Alzbeta as well!


Hello - I’m working for a company that helps local Australian and U.S. government develop websites using our CMS and embed forms in their sites using our form builder. Curious how you determined the size of the components in the form template? (We’ve determined that our front-end form components will definitely need to be larger than our admin components in the editor, but not sure how far to push those in size.) Also, curious if you have plans for sections to reduce lengthy forms? We have a feature in our builder that allows a government content author to break up longer forms, but this also introduces the issue of where to place 2 additional buttons in relation to the “submit” button: “back” and “save”.


Hey @carrie,

Welcome to the forums, thanks for posting!

The current form template is an alpha, we are planning to re-release a full page template with inline errors, client validation, hint text, error summaries, form groups, fieldset styling etc.

How you determined the size of the components in the form template?

I assume you meant width of the text fields? I’d normally say the width/size should be indicative of the amount of text a user is meant to enter in the text field. For example a postcode field would have a smaller width than an address field. Text areas should be used for fields that require larger amounts of text.

Also, curious if you have plans for sections to reduce lengthy forms?

I’m not entirely sure what you mean here. Do you mean the number of form controls on a page? Can you please attach a screen shot of the feature you are using?


Hi @sukhraj.ghuman thanks for the reply.

Sizing -> text field makes sense, but I should have specified my curiosity about the dimensions of your checkboxes & radios. They’re fairly large from what I can see in the preview so wondered how you arrived at those sizes?

By sections, I was referring to paginated forms where a user completes a portion of the inputs and then continues to a subsequent section (or more) to continue filling out additional inputs (see my screenshot for an example of how we’ve introduced 2 more buttons for those additional form controls). What are your thoughts on paginating forms and the placement of those additional controls?


Hey @carrie.

We’ve actually added some rationale in our documentation site about the size of the control inputs. The main reason is to provide a larger hit/target areas for touchscreen devices or mobility impaired users. There is an added option to decrease the size of these.

In terms of breaking up the forms into paginated pages - we haven’t reached that stage yet. I believe Gov UK recommend one question per page, and they have very good reasons supporting this design pattern.

It’s hard for us to comment on full pages. I could say something about the design but then I could be completely wrong. It all comes down to what the usability testing reveals. Do you have any stats of form completion rates with this pattern?

One thing that popped out for me with the buttons was the ‘save’ button has stronger prominence than the ‘continue’ button. I would expect those two colours to be switched. Another was the required text next to the questions. I’d be curious to know the reasoning behind this, this could be consideration we have to make when making our full page form template. Why not leave out the required text and only mark optional form controls?

Anybody else have any thoughts/research behind multi-page forms vs single page forms?


I still think there’s good reason to indicate required fields, as text, within their visible labels. Because G131 and H90.
Remembering that labels (that describe the purpose of the input) should be presented to all users - not just those using AT. Thus should visible, and must be programmatically determined.

I understand the motivation to rather only indicate optional fields. Or rather build our forms to only ever ask the questions that are absolutely required… Presenting as few optional fields as possible. Ideally none.
But for the sake of error prevention, and not frustrating our users, I believe the familiar old ‘required’ indicator should remain for now.

Perhaps you could include text at the start of the form, something along the lines: “all fields are required unless otherwise indicated”. But that seems inelegant to me. An anti pattern.

And of course keep using the client-side form validation techniques that come with HTML5. Such as the required attribute. These are good. Despite how some AT announce unfilled required fields as ‘invalid’ when they first receive focus.


As for carrie’s screenshot above. I was thinking that if the ‘Water Meter Hire’ question is only meant as a Yes/No then present it as radio buttons.

I’m also a little unsure about the inconsistency with the possessive pronouns.
It’s talking about My progress, but then asking what type of bin you need.



The question of whether to indicate required fields is something our team spent some time time designing for and researching. We actively sought to reduce the number of fields to the absolute minimum, and only requested fields that were required. We determined that if there was an optional field, then we would label it as optional. There were none but we didn’t want to exclude the possibility that at some point one may have a use. In conjunction with one thing per page, users understood that all fields required input.

The UK team at GDS uses a Question Protocol to question why you’re asking users for a piece of information. Only add a question if you know:

  • that you need the information to deliver the service
  • why you need the information
  • what you’ll do with it
  • which users need to give you the information
  • how you’ll check the information is accurate
  • how to keep the information up to date and secure


Ah thanks for linking that documentation as well as the Gov UK reasoning.

As far as completion rates, I don’t have data on that at this moment, but it’s something we’ll be looking into as we’re re-designing most of our interface, including the front-end forms. I do know our government clients utilize separate pages frequently as more complex forms with logic to hide/reveal inputs can be lengthy. We’re also trying to determine the best way to communicate those best practices around how they should build forms, so the Gov UK documentation will be handy.

As far as color on the screenshot above - government clients can theme their forms, so hard for us to have control over the button color, but I see what you mean about the prominence of save. Perhaps it’s something where we can make “back” and “save” more link-styled buttons to mitigate the color issue around theming. Do you or anyone else have any other thoughts on how to handle hierarchy/prominence issues as a result of theming?

And required fields - this is another configuration our government clients can set for their form inputs. Without designing forms for them, I think we’ll need to keep the “required” tag for our form fields, but I wonder if we also introduce an “optional” tag as JaneC says the context of what to use could vary depending on the form.

Maintaining flexibility for client configuration while also trying to get them to use best practices is one of our biggest challenges :slight_smile: