Accessible Forms, Form Validation, and CAPTCHAs

On the web, forms are constantly being used to collect information from users: signing up for something, buying something, asking a question, or contacting someone. Since forms are so commonly used, it is imperative to make forms accessible for all users.

Best Practices

These best practices have used substantial information from the US design standards guide.

Form Layout

  • A set of input fields within a form should be grouped by fieldset elements if they are related.
  • Do not use auto-advance in your form. (This is terrible for people with disabilities – don’t do it)!
  • Do not rearrange the order of the form, or inputs, with CSS. (This can cause extreme confusion for screen readers, and their users).
  • Ideally, present only one or two inputs per line for users with limited vision who have trouble scanning the screen horizontally.
  • Ensure that your color/contrast ratios and typography are accessible.
  • Each fieldset should have a legend element (directly under the first fieldset tag) that describes the grouping.
  • These practices give screen readers and users of assistive technology more information about the form, allowing them to better fill it out.
  • Every input element in a form should have a related label. You can either have a hybrid label, which is recommended for accessibility, or an explicit label.
    • Hybrid labels: These are labels which surround their associated input.
    • Explicit labels: These are labels which precede or are adjacent to their corresponding input.
  • Your form submission button should have type="submit" and have, like all buttons, a clear, actionable title. Do not use auto-submission after the user has filled out the last input.
    • Example: “Send Message”, “Submit Message”, “Subscribe”

Form Inputs

This information applies to all sorts of valid inputs: text inputs, textarea elements, telephone numbers, address entry, select elements, checkboxes, radio buttons, and date inputs (we have specifics on some of these types of inputs below).

  • All form inputs should have a related, unique label that either wraps it, or precedes it. The label for attribute should match its input’s id element, regardless of whether it wraps the element or not.
  • Try to give all inputs a type='' attribute (types include email, tel, text, submit, etc.). When supported by a browser, they improve the experience of all users.
  • If the input is required, put “Required” or “(required)” within a span in the label. Consider not using “*” to indicate required inputs as it is often not read by screen readers.
    • Example: <label for="name">First Name <span>(required)</span></label>
    • Also, within the input, include an HTML5 required='' attribute so that you can use JavaScript form validation. (If you use both the HTML5 required and aria-required attributes in the input element, a screen reader will end up reading “required” twice, which is a bit annoying).
    • Also, for required inputs, you can include regular expression pattern information, or even max-length of characters in the input attributes, which many screen readers can understand.
  • Do not use placeholder text. Placeholder text poses a variety of accessibility issues (including possible problems with color/contrast, users thinking the form input is already filled out, and placeholder text replacing a form label).
    • Give all the information about what is required to fill out the input in the form label, not the placeholder.
  • If you have required inputs, use JavaScript to visually and physically align validation messages with labels for certain input fields (that way, a screen reader will read out the error while reading over the label).

Inputs requiring numbers

  • Try not to break numbers into distinct inputs (such as phone numbers, Social Security Numbers, or credit card numbers).
    • The US Design Standards advise: “For example, use one input for [each] phone number, not three (not one for area code, one for local code, and one for number). Each field needs to be labeled for a screen reader and the labels for fields broken into segments are often not meaningful.”

Checkboxes, Radio Buttons

  • All related checkboxes should be surrounded by unordered list and a fieldset with a legend tag. The same goes for a set of related radio buttons. However, for a single checkbox, or single radio button, do use a fieldset and legend.
  • Since the only label associated with a checkbox or radio button is the option itself – e.g. ‘Yes,’ ‘No,’ ‘Banana,’ it is important to associate the option with a legend id (the legend could be: ‘Would you like to be on our mailing list?’). Place an aria-labelledby='{id of legend element}' on the label or the unordered list surrounding a set of related checkboxes/radio buttons. Also, place an aria role='radiogroup' or role='group' on the surrounding element as well. View our code snippets below for further details.

Select inputs

  • Selects are by far the most cognitively and technically challenging input. Consider using another input, such as a checkbox or radio button instead.

Date input

  • The US Design Standards states that for an input which required a month, day, and year, “Three text fields are the easiest way for users to enter most dates.”

Code Snippets

Below we have supplied the code for a variety of accessible form inputs. There are many ways to use jQuery/JavaScript to make your forms accessible, and through testing and research, we have found our own unique solution below.

Our solution takes advantage of the jQuery .validity.valid, and applying an aria-live='assertive' attribute to the first new error message on the form. (The error message must be dynamically added for this aria-live message to be read). Also, we have found that if there are multiple aria-live regions, a screen reader will only read the last one on the page, so there should really only be one aria-live region ever on a page.

See the Pen
WAH Accessible forms article
by Alex Volkov (@vol4ikman)
on CodePen.


CAPTCHA forms are implemented to stop spammers and bots from submitting forms, but in doing so, they also deny some human users access.

CAPTCHAs are not blind-friendly, and are difficult for users with learning disabilities like dyslexia.

Consider an alternative method:

  • Logic questions: Use a question rather than an image or audio. A sample CAPTCHA question might be, “Which animal is larger, a mouse or a horse?” or “What state is Philadelphia located in?” You can also ask math questions, such as, “What is one plus three?” For high-volume sites, rotate questions, as hackers can develop algorithms to predict questions and answers or hire users to answer CAPTCHA questions. However, user with cognitive disabilities may still have trouble with this approach.
  • Moderators: For services with relatively light traffic, you can manually approve access or postings.
  • Spam detection: You could use natural language filters to detect spam messages, or watch for activity coming from similar IP addresses. Most major blogging or content management software contains spam filtering capabilities, or can be fitted with a plug-in for this functionality. Many of these filters can automatically delete messages that reach a certain spam threshold, and mark questionable messages for manual moderation.
  • Phone, text, or email verification: Email verification, where you acknowledge receipt of an email, is a common authentication technique that can be very accessible. Another way is telephone or SMS authentication.