Simple inline error message pattern

Posted on Sunday, 3 January 2016 by Steve Faulkner

Error messages can be problematic to convey consistently to all users across browsers and assistive technology (AT). Using simple HTML, with a little ARIA polyfil magic if you want to get fancy, you can robustly associate error messages with controls and ensure that users get the message every time.

The issue

  • You want to display a message to users in the case where they have not filled in a form field correctly.
    • You want the error to be announced by screen readers when the invalid field is focused.
    • You don’t wan’t any delay between the field getting focus and the error message being announced.
    • You want it to work in as many browser and AT combinations as is possible.

The really simple pattern

Add the error message as a child of the label element associated with an input.

It is really robust because the error message, when added, becomes part of the accessible name for the control:

Non-error state of input type=text:

accessible name: “pootish”

Error state of input type=text:

accessible name: “pootish ERROR – fill it in sucker!”

See the Pen ZQLeev by steve faulkner (@stevef) on CodePen.

A pretty simple pattern

This pattern is almost as robust as the previous, except that it relies on some ARIA magic to polyfil the lack of implementation support for multiple labels. While browsers support the activation behaviour for multiple labels (you can click on any label associated with a control via for/id). Only Firefox currently exposes the correct accessible name.
Using a separate label for the error message provides more flexibility in (CSS) decoration and positioning of the message. It results in the same accessible names for the non-error and error states as the really simple pattern.

See the Pen rxLERr by steve faulkner (@stevef) on CodePen.

Bugs filed

As mentioned above, browsers mostly don’t implement the deriving of an accessible name from multiple label elements, so have filed some bugs, so in the future the use of aria-labelledby, in this case, will not be needed.


About Steve Faulkner

Steve is the Technical Director at TPG. He joined The Paciello Group in 2006 and was previously a Senior Web Accessibility Consultant at vision australia. He is the creator and lead developer of the Web Accessibility Toolbar accessibility testing tool. Steve is a member of several groups, including the W3C Web Platforms Working Group and the W3C ARIA Working Group. He is an editor of several specifications at the W3C including HTML 5.1, ARIA in HTML, Notes on Using ARIA in HTML and HTML5: Techniques for providing useful text alternatives. He also develops and maintains HTML5accessibility.


  1. Hi Šime,
    no, that’s just my crappy coding, fixed, now on input.
    Note: the JavaScript and CSS is for demo purposes only, I am not and probably never will be good at these 🙂

  2. Hi Neil, the ‘really simple’ pattern is the most robust as it does not require any ARIA, it makes use of label element behaviour that has been implemented in browsers since I was young (i.e. a long time). The second demo does make use of ARIA, but it confines its usage to aria-labelledby with multiple id references which has better support in legacy (i.e. older IE) than aria-describedby with multiple id references. The other thing to note is that in certain AT (i.e. VoiceOver) there is a delay before aria-describedby content is announced, this is viewed by some as problematic, as a result a whole new ARIA property has been proposed: aria-errormessage. Related github issue discussion.

Comments for this post are closed.