Indicate required fields without label

[char-mainewang]

hey team, i have a question about how we can indicate if a field is required without using the label

the Actions destination UI has a section where customers can configure how they want to map a source property to a destination property, we currently use this 2 column UI (pic 1) to illustrate which/how fields are being mapped (this design validated well as it maps to our user’s mental model of data traveling from left to right vs using a vertical form to fill out). these fields don’t use labels and required fields are indicated with an asterisk to the right of the destination property name

as we migrate to paste, i’m curious to know how we can indicate if a field is required or not. i have some ideas (pic 2) but would appreciate some guidance from the paste team here 👀 (btw, most of the fields are optional which is why i didn’t include the option of using (optional))

[SiTaggart]

Hi @char-mainewang

Generally speaking we advise labels on input fields for accessibility and usability reasons. If tells a user what the field is and its purpose, it also gives us space to indicate required fields. We don't rely on placeholders either. There are very few exceptions to this rule. Detailed here https://paste.twilio.design/components/input#accessibility

Now, sometimes where we might have a collection of fields that are repeated, that might share a label, we might show one label above each column. Each input field is still labelled, it's just hidden. Usually when that happens we tend to see that a column is required information and so the required indicator can be placed in the label above the column, as they are all the same field type.

This might be slightly different here. To repeat what I think I understand:

We have an object which has a set of properties on the right, and we're mapping incoming data to that object shape. That object, for it to be valid, has a set of properties that are required to be filled by the incoming data

Is that a good summary?

[char-mainewang]

Yea, that's a good summary, i'd add that the object also has optional properties. So if the user doesn't enter anything in the corresponding field on the left, that property wouldn't show up in the destination.

[SiTaggart]

Have you considered just grouping the required and optional properties separately into sections?

With grouping like fields into Form Sections or Groups it allows you to mark then entire section as required in either a section heading or legend.

We'd still advise a visible legend for the section, so you can explain it with some words, but you can then apply your required indicator at the group level and not have to worry so much per field. You can play with Separators or containers and background colors to create the sections and distinction.

In summary, though, you need a visible label above each column of inputs, if not each field (preferred). You can play and explore grouping required and optional properties into groups or sections, applying a group or section label to each state "required" or apply the reqiured indicator to a meaningful section heading.

Hope that helps.

[char-mainewang]

this was super helpful! we are actually thinking about letting customers select optional fields as they need so maybe if they click on "Add mapping filed" we require them to fill it out or else they can delete it, this way we can utilize the labels and maintain accessibility :)

does something like this align with your recommendation?

[SiTaggart]

Yeah that certainly looks pretty aligned to what I was thinking.

Labels and obvious optional vs required fields. I like the idea of only showing the required fields up front, and adding optional fields afterwards

[simsemma]

hey @SiTaggart had a similar use case i wanted to get your opinion on:

i'm starting to take over some designs that were started last year using evergreen that have to do with alerting configuration. the original designs have a bunch of input fields without labels (attached), but i know paste doesn't recommend using an input without a label in a lot of scenarios.

i started thinking about two different versions of this - one without a label and one with a label (also attached).
question is: do we need to have labels with every input field? and if so, do we have any guidance on how to treat a UI set up like this one? i foresee that the configuration of these alerts could get more complex, so would be preferable to not need a label in each situation if we could provide an aria label or something instead

[ceyerkes]

Adding more context! @serifluous created this alternative for inline label-less inputs that I think make a lot of sense for the more complex, visual-picker-y examples that come up:

[SiTaggart]

Hi @simsemma

Technically, yes, every form field should have a visible label. It's not necessarily a Paste thing either, it's part of meeting the basic requirements for Level A WCAG conformance, covered in part, but not fully by Success criteria 1.3.1 Information and relationships

There is one except in there that I outlined above:

form fields may be positioned as groups that share text labels;

So you can omit labels where multiple fields share the same label, but there still has to a clear, visible label that describes the field.

The other part of that design, which also isn't necessarily a Paste thing, is that the original and label less versions try to construct an English sentence out of parts of text and inputs. This won't localize well, and should be avoided. We have a section on the docsite about this https://paste.twilio.design/components/input#labels-and-help-text

Hope that helps

[kevinbtu]

@SiTaggart Thanks for the clarification - sounds like from a Paste component perspective, we'll still need an option for the component to hide the label to satisfy the use case you mentioned of multiple form fields sharing the same label. We could certainly just delete or remove the label in those cases, but also might be nice to have it as a toggle-able option or variant in figma.

Also, more for my education since I'm not an accessibility expert, but I was looking through the W3 site on hiding labels and it seemed like that was an acceptable thing from an accessibility perspective if the label is provided in code for use cases where hiding a label is preferred?

[SiTaggart]

Right, so that's one part of some of the criteria used to understand if your application is accessible. That one in particular focuses on the "correct" association of the label to input to give it a machine-readable, accessible name. Code is one part of the solution.

There's a pretty broad collection of overlapping, but independent success criteria that cover different things. They are designed that way because disability is a spectrum on which many different people live on. Blind users have different needs to deaf users, who have different needs to low vision, who have different needs to cognitive disabilities, and you might have several, not just one disability. They can overlap.

This isn't going to be exhaustive as it's very broad, and the criteria are long. The simplest way is that for this particular case it starts with Labels or Instructions the TL;DR being you must provide clear instructions on what data to provide for each control, for all users. Then comes Info and Relationship which broadly covers the connection between instructions and controls. Lastly Name, role, value which covers correct functional naming on controls (machine-readable).

The problem is, just because you meet one, doesn't mean you meet the other. This is called out in Labels and Instructions:

It is possible for controls and inputs to have an appropriate accessible name or description (e.g. using aria-label="...") and therefore pass Success Criterion 4.1.2, but to still fail this Success Criterion (if the labels or instructions aren't presented to all users, not just those using assistive technologies).

Just because you've provided a hidden label correctly, you still fail on providing clear instructions on what an input must hold in regard to data because it's not visually labelled. This might be a failure for a sighted user with a cognitive disability, as an example.

Giving a toggle-able boolean to input in Figma might be something we could consider in the future, but because the use cases are so few it might be hard to prioritize, given the workaround. We really only feel comfortable with Search inputs being our exception as it's really the only one we feel comfortable arguing that its "fine". This is due in part to how common, and broadly used, it is as a pattern across the internet, but it's not a guarantee it'll pass an audit. Different auditors have different levels of tolerance for nuance.

Hope that helps clarify a little more. Our guidance and recommendations are designed to keep our applications as usable as possible, by as many people as we can.

[simsemma]

@SiTaggart this is super helpful - thanks for providing such a thorough explanation on this, really appreciate it!