Let name fields accept names as people write them, with accents, apostrophes, hyphens and spaces. If a format is genuinely needed, say so before the field, and make every error message one a screen reader announces.

Please enter a valid name

A customer types her name into a booking form, presses send, and is told to enter a valid name. Her name is Hélène.

The form accepts plain letters from A to Z and nothing else. It turns away René, O'Brien, Anne-Marie and de la Cruz, and if it also insists on three letters, Ng and Li.

Most people in that position try again without the accent or the apostrophe. That gets them through, and puts a misspelled name on everything that follows.

Some give up. And a customer using a screen reader may not hear the error at all.

Names a strict form turns away

The second deserves a closer look, because some forms block apostrophes on purpose rather than by oversight.

Why forms do it

Many strict name fields come from a template or a form tool with a letters-only setting, switched on to keep out spam or copied from an example that assumed English names.

The apostrophe is sometimes blocked deliberately. In a badly written database query, an apostrophe can break the query, so the developer bans the character instead of fixing the query.

That hides a weakness rather than removing it. A properly written form treats any name as plain data, and an apostrophe does nothing to it.

Minimum lengths come from the same instinct: a guess that anything under three letters must be junk.

What the customer is told

An error on a name field tells the customer that their own name is wrong. For most people that is a small irritation; for some it is a familiar one, and it says the business was not expecting them.

In Canada, accented names are everyday names. A form that cannot take them was built for a narrower country than the one its customers live in.

The misspelled version then travels. It appears in the confirmation email, on the invoice, on the certificate or the name badge, wherever the record is used.

When the error is silent

Many forms show their error in red text at the top of the page, or beside the field, and do nothing else. A sighted customer sees it. A screen reader user often does not.

The screen reader carries on from wherever the user was. Nothing announces that the form failed, and the user may assume it was sent.

WCAG 2.0, the standard accessibility work is normally measured against, asks a form to name each error and describe it in words, and to explain any required format before input.

A message the screen reader never reaches falls short of that in practice.

A worked example

A party planner for children's birthdays runs themed parties in clients' homes and rented halls, and takes bookings through a form on her website.

The form asks for the birthday child's name, which goes on the banner, the place cards and the cake topper she orders.

Its name fields accepted plain letters only, a setting switched on in the form tool to keep out spam.

Parents of a Zoé and a Chloé typed the names without accents to get past the error, and the banners were printed that way.

A father who uses a screen reader tried three times. The error appeared in red above the form, his screen reader never read it out, and he assumed the booking had gone through.

He phoned two weeks later to ask why nobody had confirmed.

The fields now accept any name. A line above the child's name asks for it exactly as it should appear on the banner, accents and all, and errors appear beside their field, in words, with the cursor moved there.

The confirmation email repeats the child's name, so a parent can spot a mistake before anything is printed.

Accept names as people write them

A name field should accept letters from any language, apostrophes, hyphens, spaces and full stops. Trim stray spaces at either end and leave the rest alone.

Set the minimum at one character and the maximum generously. Do not change the capitals, since MacDonald, van der Berg and McKay are all correct as typed.

Ask whether you need first and last names separately at all. A single full-name field fits more people, and an optional field for what they like to be called handles the rest.

Then make sure the site stores and sends names correctly, or the accents the form now accepts will arrive as odd symbols.

If a format really is required

Sometimes it is. A name printed on a certificate, a ticket or a cake has to be exactly right, and some older systems downstream accept only plain letters.

Say so before the field, in the label, with an example. "Exactly as it should be printed" is an instruction; an error after the fact is a rejection.

Where an older system genuinely cannot take accents, convert the name behind the scenes for that system, and keep the customer's own spelling everywhere else.

Errors everyone can hear

Put each error beside its field, in plain words that say what to do, and tie it to that field behind the scenes, so a screen reader reads the message along with the field.

Move the cursor to the first field that needs attention, keep everything else the customer typed, and never rely on colour alone.

Then try it with a screen reader. VoiceOver comes with every iPhone and Mac, and Windows has free screen readers too.

The counter-case

Some fields have real limits set elsewhere. A payment processor may restrict the cardholder name field, and a label printer or an old accounting system may choke on accents.

Those limits belong to that one field or that one system. They do not justify rejecting names on a contact or booking form.

Accept names as people write them, explain any format before asking for it, and make every error audible.

The check

  1. List every form that asks for a name.
  2. Try Hélène, O'Brien and Anne-Marie in each.
  3. Try de la Cruz and Ng as surnames.
  4. Remove letters-only rules and minimum lengths.
  5. Put format instructions before the field.
  6. Test the errors with a screen reader.
  7. Check the confirmation email keeps the accents.

Step six finds the failure nobody on staff has seen. A form can look perfectly helpful on screen and still leave a screen reader user believing a booking went through.

Accents that turn into odd symbols once they are saved are covered in strange characters where apostrophes should be.

Frequently asked questions

Why do some forms reject accented names?

Usually a letters-only setting from a template or form tool, switched on to stop spam. It assumes every name uses the plain English alphabet, which many Canadian names do not.

Is blocking apostrophes a security measure?

Sometimes it is meant as one, because an apostrophe can break a badly written database query. The proper fix is the query, which should treat any name as plain data.

What should a name field accept?

Letters from any language, apostrophes, hyphens, spaces and full stops, with a minimum of one character and a generous maximum. Leave the capitals exactly as typed.

How do screen reader users miss form errors?

When the message only appears visually, in red at the top of the form, and is never announced. Tie each message to its field and move the cursor there.

What if we need a particular format?

Say so in the label before the field, with an example, rather than in an error afterwards. Then show the name back before anything is printed or sent.

How do I test our forms?

Enter real names such as Hélène, O'Brien, Anne-Marie, de la Cruz and Ng into every form, then check the confirmation email and the stored record.

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.

Forms turning away real names?

Send us the address of your booking or contact form. We will test it with real names and a screen reader.

Start a Conversation