Experimental design - Use page headings as input labels

[outerpress]

What

In a one-thing-per-page form, this pattern:

• Uses the page heading as the label for an input on the page.
• Removes (* Required) markers, instead calling out which questions are optional.

Purpose

Reduces noise and redundant labels on a form including:

• Input labels that repeat the heading, or explain how to use the input (for example, "Select an option" label on a radio button input)
• (* Required) markers that otherwise may appear on every input of every page.

Usage

This could be used on any/every page on a form that follows the one-thing-per-page design principles

Behavior

See this design file for variations in detail.

Examples

See above.

Accessibility

The input must recognize the page heading as the input's label. This Slack thread walks through some of the challenges there.

Guidance

This should only be considered when following one-thing-per-page design principles. Forms with many inputs on a page should look at other patterns.

See also best practices in this design file.

Research (optional)

None yet. The VA Online Scheduling team is in the early stages of discovery on this pattern.

Code (optional)

None yet. The VA Online Scheduling team is in the early stages of discovery on this pattern.

Next steps

You may present your work to the Design System Council at an upcoming meeting. If you do not or cannot attend the Design Council Meeting, you can opt to get an asynchronous approval.

Submit requests to join an upcoming Design System Council meeting in #platform-design-system.

During the meeting, the Design System Council Working Group will evaluate the request and make a decision.

If your request is approved, you can add your component or pattern to the system. If you have any questions on how to add your component or pattern to the system, please reach out to the Design System Team at #platform-design-system.

[caw310]

This was discussed in the 1/27 DSC meeting. Here are some items from meeting notes:

• Work with a11y folks on the right way to code this up.
• As soon as you get through testing and know what is working, let us know. DST would like to get pattern into DS.

[humancompanion-usds]

@outerpress - Can we get an update on this? Has research been done on this?

[outerpress]

@humancompanion-usds we have the work defined to use this pattern in our request flows but it hasn't made it out of the backlog yet.

[humancompanion-usds]

Define this use case as part of the Ask users for a single response pattern.

[humancompanion-usds]

@outerpress - We have finally published the Ask users for a single response pattern and we have One thing per page versions of 6 components. Does this give you what you need? If so, go ahead and close this. If not, let us know what should be added. Thanks.

[outerpress]

@humancompanion-usds First, this is SO HELPFUL! Thanks to you and your team for putting this together. We implemented the radio component on a couple of pages and it worked beautifully.

My only open q is about requiredness - when using this pattern is it better to:

• Indicate only which questions are required? (Our current pattern)
• Indicate only which questions are optional?
• Mark nothing and let error validation on nav do the communication?

Or maybe the answer depends on how many q's are required. (In the appts flow all but 1 or 2 are required). And maybe the answer is broader than this pattern.

Thanks again :)