Required Fields Marked Only With a Star

A star and a guess

Most forms mark required fields with an asterisk beside the label, often small and red. Somewhere near the top, in pale type, a line explains what the star means.

Visitors with good eyesight and a mouse mostly work it out. Others do not.

A screen reader may announce "star", or nothing at all, depending on the software and how the star was added.

Someone who cannot tell red from other colours sees a speck. Someone zoomed in on a phone may never see the explanation.

They find out which fields were required when the form rejects them.

Who misses the star

• Screen reader users, whose software may skip punctuation or a star added by the stylesheet.
• People with low vision, zoomed in so far that the explanation is off screen.
• People with colour blindness, when red alone separates required from optional.
• Keyboard users, who tab from field to field past the text between.
• Anyone on a phone, where a tiny star beside a label is easy to overlook.

The fourth surprises owners. The explanation at the top belongs to no field, so a person moving through with the Tab key, or a screen reader in forms mode, goes straight past it.

What the standard asks

WCAG 2.0, the accessibility guideline most organisations work to, asks for labels or instructions wherever a form needs input. That is success criterion 3.3.2, Labels or Instructions.

It also asks that anything shown visually, such as which fields are required, is present in the code as well (1.3.1, Info and Relationships), and that colour is never the only way information is shown (1.4.1).

A star that is only visual, often only red, and explained in a sentence keyboard users skip, misses all three.

None of this needs a redesign. It needs a few words in the labels and an attribute in the code.

Words in the label

The simplest fix is the word itself: "Phone (required)". It is read aloud, it does not depend on colour, and it grows with the rest of the text when someone zooms.

If most fields are required, mark the few that are not: "Company name (optional)". Fewer marks, same information.

A star can stay for people who expect one, provided the word is there too and the star is explained just before the first field, not at the top of the page.

Use the same wording on every form on the site, so the pattern only has to be learned once.

Marking it in the code

Each required field should also carry the required attribute in its HTML. Screen readers announce the field as required when the visitor reaches it.

Most current browsers will also stop a form being sent with a required field empty, and show a short message at that field.

Where a form handles its own checking, the aria-required attribute does the announcing without the browser's behaviour.

The label must also be connected to its field in the code, or a screen reader may never read the word required alongside the field. Check both at once.

A worked example

An independently owned ice rink rented ice to hockey teams, figure skating clubs and birthday parties through a request form on its website.

The form had eighteen fields. Eleven carried a small red star, and the explanation sat at the top in pale grey, above a banner photograph.

A parent who uses a screen reader tried to book a party. Her software said nothing at the stars, so she filled in what seemed relevant and pressed send.

The page reloaded with "Please complete all required fields" at the top, no sign of which ones, and every answer cleared. She phoned the rink and told them so.

The repair took an afternoon. Each required label gained the word "(required)" and the matching attribute in the code. Errors now appeared beside the field they concerned, and the form kept whatever had been typed.

Four fields nobody at the rink ever read were removed altogether.

Error messages that point somewhere

Clear marking prevents most errors. The rest need messages that help.

Name the field and the problem, in text, next to the field: "Enter a phone number", not just a red outline. WCAG 2.0 asks for errors to be identified and described in text (3.3.1, Error Identification).

A short summary at the top helps too, with each item linking to its field, so a screen reader user hears what went wrong as soon as the page reloads.

And never clear what was typed. Re-entering eighteen fields is where many people give up.

Ask for less

Every required field is a reason to stop. Before marking anything, ask whether the business needs it before the first conversation.

A request form usually needs a name, one way to reply, and what the request is. The rest can be asked on the phone.

Useful but optional fields can stay, clearly marked. Fewer fields also means fewer labels to get right and fewer errors to explain.

Testing the form

Tab through the form from top to bottom without touching the mouse. At each field, can you tell from what is right there whether it is required?

Listen to a few fields with a screen reader. Windows includes Narrator, and Macs and iPhones include VoiceOver.

Submit the form empty, then with one field missing, and read what comes back.

Print the form in black and white. Anything that relied on red has now disappeared.

The counter-case

A form with one or two fields, all required, needs less. A sentence before it saying both are needed may do, with the attribute still in the code.

A search box or a newsletter sign-up with a single email field needs no marking at all.

And labels can be fixed long before a full accessibility review. This is among the cheapest improvements a site can make.

For any form that mixes required and optional fields: words in the labels, the attribute in the code, and errors that name the field.

What to do

1. Find every form across the site.
2. Remove fields you can ask about later.
3. Write required or optional into each label.
4. Add the required attribute to each required field.
5. Explain any star just before the first field.
6. Name the field in every error message.
7. Tab through each form without a mouse.

Step three is where most of the benefit lies, because a word in a label works for everyone at once: it is read aloud, it survives zooming, and it does not depend on colour.

Text that a screen reader can announce is also the point of image descriptions on a gallery page.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.