Consider standardising on default id

[joelanman]

Consider standardising on making a default id from the components name if an id is not given.

Related component

Radios make a default id from the name, other components like textarea do not

Context

Training people in using the Prototype Kit, where it was confusing why some components need id and others do not

[querkmachine]

The components that use an id or idPrefix Nunjucks parameter, based on a quick dig. Components not listed don't accept either parameter.

Component	id or idPrefix	Required?	Default/fallback value
Accordion	id	✅ Yes	None
Button	id	No	None
Character Count	id	✅ Yes	None
Checkboxes (whole component)	idPrefix	✅ Yes	name parameter
Checkboxes (items)	item.id	No	idPrefix + loop.index concatenated
Date Input (whole component)	id	✅ Yes	None
Date Input (fields)	item.id	No	id + item.name concatenated
Details	id	No	None
Error Message	id	No	None
File Upload	id	✅ Yes	None
Hint	id	No	None
Inset Text	id	No	None
Radios (whole component)	idPrefix	✅ Yes	name parameter
Radios (items)	item.id	No	idPrefix + loop.index concatenated
Select	id	✅ Yes	None
Tabs (whole component)	id	No	None
Tabs (panels)	idPrefix	✅ Yes	None
Tabs (panels)	item.id	No	idPrefix + loop.index concatenated
Text Input	id	✅ Yes	None
Textarea	id	✅ Yes	None

We do have an awful lot of ids that are required and have no default or fallback.

In the case of the form control components, we could potentially follow the lead of Checkboxes and Radios and use the name parameter as a fallback. name will usually be present, as it's required for sending data during form submission.

For Accordion and Tabs, would it be simplest to just hardcode a fallback string like "accordion" or "tabs" for these components?

[joelanman]

great work! I'd suggest defaults from name for all the required ones

[joelanman]

if this is something we're interested in I'm happy to try a PR

[querkmachine]

@colinrotherham has brought up that name may not always be a valid value for an id. For example, in the Date Input, the fields may have names like dateOfBirth[day], dateOfBirth[month] and dateOfBirth[year]. These are not valid ids as square brackets aren't permitted in id values.

Similarly to this, there is no guarantee that a name be unique, as is required for ids, but the cases where this is most likely to happen (checkboxes and radio buttons) already have this accounted for within the Nunjucks templates.

[joelanman]

the default dateInput example takes a namePrefix which we could use the same way to make a default id, it then builds the default day month and year from that

[frankieroberto]

This just tripped me up slightly - I was confused why the label of a text input didn't focus the input on clicking it, which turned out to be because I'd forgotten to add an id using the Nunjucks macro.

I think I had wrongly assumed that the id would default to the name value, as that's what happens with radios and checkboxes.

[joelanman]

I think thats a good point - if missed it creates a significant accessibility problem, the label and input won't be associated for screen readers and other assistive tech