# Split date and phone fields with no name for each box
Source: https://easeweb.dev/learn/split-fields
Topics: Forms > Phone numbers and dates split into several boxes name every box (WCAG 1.3.1, 3.3.2, 4.1.2)
The fix: Give every part its own name, and tie the set's label to all of them. Either put the parts in a fieldset with the set's label as its legend and a visible label on each part, or keep the layout, group the parts with role="group" and aria-labelledby, and name each part with aria-label.
Test with: keyboard, screen reader, zoom
References: https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html https://www.w3.org/WAI/WCAG22/Techniques/failures/F86 https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA17 https://design-system.service.gov.uk/components/date-input/ https://designsystem.digital.gov/components/memorable-date/
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
## What happens
An online shop's sign-up form asks for a date of birth. It is drawn as one row: three dropdowns side by side, Day, Month and Year, with a slash between each, under the label "Date of birth". Each dropdown opens on a prompt ("Day", "Month", "Year") until something is chosen. Someone picks 12, 05 and 1990, and the row reads "12 / 05 / 1990". The prompts are gone: nothing on screen now says which box is the day and which is the month, and in a country that writes the month first, "12 / 05" reads as 5 December. A screen reader user who presses Tab hears "Date of birth, combo box, 12", then "combo box, 05", then "combo box, 1990". The second and third boxes have no name at all: a screen reader has none to read, and a voice control user has none to say.
## Why it fails
The label is a real `label` with `for="dob-day"`, so it names the first dropdown and nothing else. A label names one field; it can't name three. The month and year dropdowns are left with no accessible name, and a select's first option, "Month", is its value, not its name: it is read only until something else is chosen. That fails 4.1.2, which needs every control to have a name; W3C's failure F86 describes exactly this, a field asked for in parts whose later parts have none.
It fails 1.3.1 as well. On screen the three boxes are plainly one answer, and their order and the slashes say which part each one is. None of that is in the code: no group holds the three, so the words "Date of birth" never reach the second and third, and nothing but position says this box is the month.
And it fails 3.3.2, which needs labels or instructions people can use while they fill in the form. The prompt option is the only thing that says "Month", and it disappears as soon as a month is chosen, as a placeholder does once something is typed. From then on, the set has a label but its parts have none, and the layout is all that is left to tell 12 from 05. W3C's Understanding page for 3.3.2 makes the same point about a phone number in three boxes: the punctuation is not enough to label the fields, and one "Phone number" label can't label all three.
## Who is affected
The failure shows once the form is filled in, which is when people check it. Someone who goes back to correct a date, or reviews the form before sending it, meets three numbers and has to remember, or guess, the order they chose them in.
## What automation and AI miss
axe's `select-name` rule and ANDI find the two dropdowns with no name, and axe's `label` rule finds the same mistake in a phone number split into text boxes. What they can't tell is whether the set's label reaches the parts. Give every dropdown an `aria-label` and the scanners go quiet, even if nothing ties "Date of birth" to them, or if the names are heard only by screen readers. A quick fix can do worse: `aria-label="Date of birth"` on all three dropdowns silences the scanners too, and a screen reader then hears "Date of birth" three times and still doesn't know which box is the month. EaseWeb's audit sends a set of named parts with no group around it, or with names only screen readers get, to a person as a lead (`ew:split-field-manual-check`), because whether each part can be told apart, by ear and by eye, is something a person has to check.
## Before: one label above three dropdowns
```html
/
/
```
The first dropdown is named "Date of birth". The rest is where it fails:
- The month and year dropdowns have no name, so a screen reader reads only "combo box" and the value.
- Nothing groups the three, so "Date of birth" is never read with the month or the year.
- The words Day, Month and Year are only the first options, and they disappear once a value is chosen.
## After: a fieldset with a label on each box
```html
```
1. Make the row a `fieldset`, so the three dropdowns are one group.
2. Make "Date of birth" its `legend`, the group's name. A screen reader says it as focus enters the group, roughly "Date of birth, grouping, Day, combo box, 12".
3. Give each dropdown an `id` and a visible `label` of its own: Day, Month and Year. They stay on screen once values are chosen, and voice control users can say "click Month".
4. Drop the slashes: the labels now say what they said.
This fixes the Before and passes 1.3.1, 3.3.2 and 4.1.2. It is the pattern the GOV.UK date input and the US Web Design System's memorable date use, with a label above each part.
## After: names on the boxes, keeping the look
```html
Date of birth
/
/
```
1. Turn the `label` into a `span` with an `id`, so it no longer names the first dropdown alone.
2. Give the row `role="group"` and point its `aria-labelledby` at that `id`. A screen reader then says "Date of birth" as focus enters the row.
3. Give each dropdown an `aria-label`: Day, Month and Year. Every box now has a name, read with its value.
This fixes 4.1.2 and 1.3.1 for screen reader users, with the same row on screen. It is the shape of W3C's technique ARIA17, and of the phone number example on the Understanding page for 3.3.2, which gives each box a hidden name where the design has no room for visible ones. But the names are heard, not seen, and that page also warns that a name only assistive technology gets can pass 4.1.2 and still fail 3.3.2: once all three hold numbers, the screen says no more than the Before did, so 3.3.2 passes only where the layout makes each part obvious, and a voice control user has no word on screen to say. Use it for a row you can't redesign yet, and move to visible labels when you can.
## Which option to use
Both give every box a name and tie "Date of birth" to all three. Use the fieldset with a label on each box: it is the only one that also tells sighted people which box is which once the form is filled in, and it does that with plain HTML and nothing hidden. The hidden names are a stopgap for a design that can't change this release.
## Implementation decisions
**The order is not a label.** Day, month, year is the order in much of the world, month first in the United States, year first in Japan. With a label on each box, any order works; without one, the order is a guess. Put the parts in the order your readers expect, and keep the labels anyway.
**The first option is not a name.** A prompt such as "Day" or "Choose day" can stay as the empty first option, but it is the select's value, read only until a value is chosen. Frameworks fill it in this way: Django's `SelectDateWidget` takes these prompts through `empty_label` when the date is not required. The name has to come from a label.
**Framework helpers leave the parts unnamed.** Rails' `date_select` renders three selects with ids ending `_1i`, `_2i` and `_3i`, so a label written for the attribute names none of them. In Django's default `as_div()` layout, the three selects of a `SelectDateWidget` sit in a fieldset with the field's label as the legend, with no label on each select; the `as_p()`, `as_table()` and `as_ul()` layouts tie the label to the first select alone. In both, add a label to each part yourself, or render the parts from your own component.
**Phone numbers and postcodes are better as one field.** A phone number split into area code, prefix and line number needs a name on every box just as a date does, but the better fix is not to split it: one field takes a number however it is typed or pasted. The US Web Design System says not to split a phone number into separate fields, and GOV.UK asks services to let people enter it in whatever format is familiar to them. A field that formats its value as it is typed has problems of its own, covered in [input masks that change a typed or pasted number](/learn/input-masks). A card expiry in two dropdowns needs a "Month" and a "Year" label inside a fieldset whose legend is "Expiry date".
**Let the browser fill it in.** For a date of birth, put `autocomplete="bday-day"`, `"bday-month"` and `"bday-year"` on the three parts, so a browser can fill in what it has saved. That is its own criterion, covered in [form fields that block or break autofill](/learn/autocomplete).
**Leave focus where it is.** Don't move focus to the next box as soon as one is filled in; GOV.UK's date input pattern says never to. It surprises people who go back to correct a part. Boxes that move focus on by themselves are covered in [code boxes where a keyboard can't correct a wrong digit](/learn/code-box-keys).
**Errors point at the part.** When one part is wrong, say which in the message ("Enter a month from 1 to 12") and mark that part, as [form errors that don't say how to fix them](/learn/accessible-form-errors) describes. A date people pick from a calendar is a different control, covered in [date pickers that can't be typed in or used by keyboard](/learn/date-picker).
## Verify the fix
1. In the browser's accessibility tree, check every part has its own name (Day, Month, Year), and sits in a group named "Date of birth".
2. With a screen reader, Tab into the set from above and with Shift + Tab from below, and check "Date of birth" is read with the first part you land on, and each part's name with its value.
3. Choose a value in every part, then look at the row and check the screen still says which box is the day, the month and the year.
4. At 200% zoom and at a phone's width, check each label stays beside its box and the boxes don't overlap.
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after the shared date component changes.
## Limits
This is a starting pattern, not a guarantee for every application. A screen reader reads a group's name as focus enters the group, so coming back with Shift + Tab from below, it is read with the year rather than the day, and some screen readers may repeat it on every part. The guide covers dates asked for in parts; a value split into one box per character, such as a one-time code, is covered in [one-time code boxes that won't take a pasted code](/learn/one-time-codes). Radio buttons and checkboxes under one question are covered in [radio buttons and checkboxes without a group name](/learn/field-groups). Test the complete form with your target assistive technology.
---
Get this guide in your coding agent: MCP https://easeweb.dev/mcp (setup at https://easeweb.dev/services/developers)