Forms can be made accessible using a combination of technology, design and text. A form which is properly built in the code, can be operated with the keyboard. An accessible form provides the visitors with a suggestion on how to solve an input error. It also allows the visitors who use assistive technology to complete the form correctly.

A form can consist of various form fields:

  • input fields
  • checkboxes
  • comboboxes
  • radiobuttons
  • etc.
  • Provide labels for input fields

    Labels are the most important element for an accessible form. Provide labels for all input fields or other form elements such as checkboxes, radio buttons, and comboboxes. A clear label describes exactly what needs to be entered in the field, is visible to all visitors and is located close to the input field.

    The label must be linked in the code to the input field. This way you also make the input field accessible to visitors who use assistive technology. The label is the name of the input field. A label also expands the clickable area from which an input field can be selected. This is useful to visitors with a motor impairment.

    Link labels in the code to an input field

    Labels are placed with the <​label> element. To link a <​label> element to a form element use a for/id link. To do so, give the <​label> element a for attribute and the corresponding form element an id attribute with the same value.

    It looks like this in the code:


    There are also ways to visually hide the labels. In that case, ask yourself carefully why you would want to do that. This way the input field will lose the larger clickable area and it may become less obvious to visitors. However, if the label is visually hidden, make sure that a label is still available for assistive technology. To achieve this, use the aria-label, aria-labelledby or a title attribute, which are not visible.

    It looks like this in the code:


    Note: Placeholder text should not be used as the only way to add a label to an input field.

    Group multiple sections of related input fields

    If a form has multiple sections of related input fields, then a <​fieldset> element is used to group them together. Give the <​fieldset> element a label by placing a <​legend> element inside the <​fieldset> element. Assistive technologies use the <​legend> element as if it were a part of the label of the elements in the <​fieldset>.

    The <​fieldset> element is especially relevant for grouping checkboxes and comboboxes, but can also be used to group other input fields.

    It looks like this in the code:


    Provide instructions for input fields

    Instructions give an extra hint for the input field. The instructions in a form should indicate whether there are required fields and possibly whether there is a required input format.

    Indicate that an input field is required

    You can indicate a mandatory input field in text or, for example, with an asterisk (*). Make sure this tag is placed inside the <​label> element.

    It looks like this in the code:


    If the instructions are not clearly named for each input field, it should be indicated in text before the first input field how the mandatory fields are indicated.

    It looks like this in the code:


    Mark the required fields in the code as well. Preferably use the aria-required attribute.

    Indicate if there is a required input format

    Also for required input formats, such as a postal code or an e-mail address, the instructions must describe what the requirements for the input are. This can be done directly in the <​label> element.

    It looks like this in the code:


    This can also be done with the aria-describedby attribute.

    It looks like this in the code:

  • Forms often require information that is also requested in many other forms. This applies to frequently requested data such as name, e-mail address and telephone number.

    The purpose of an input field can be defined in the code. This allows browsers to understand what data is being requested. A browser can then already (partly) automatically fill in the form itself. This is useful for all visitors, but it is even more important for visitors with a motor disability. Filling out a form can take them a lot of time.

    To do this, use the autocomplete attribute in the code, adding the input field’s purpose to the <​input> element.

    It looks like this in the code:


    The W3C has a list of 53 input purposes that should be used in the code. (

  • Forms should have an error check built in. The error check automatically analyses whether a required field has been left empty or whether an input field has been filled in incorrectly. If an error is found, the error message should be displayed in text. This text can be supplemented with other visual clues, such as a different colour or an icon.

    In the text of the error message, state the name of the field that was entered incorrectly and state exactly what the error is. Do not write:

    • This field is required.

    But instead write:

    • The field ‘Phone number’ cannot be empty.

    It can also be indicated in the code which field has been filled in incorrectly. To do this, use the aria-invalid attribute. In addition, the error message in the code should be linked to the corresponding input field. This prevents confusion for visitors using assistive technologies. An error message can be linked in a number of ways such as with an aria-describedby attribute.

    It looks like this in the code:


  • If an error has been found and suggestions for improvement are known, these suggestions must be communicated to the visitor. The suggestions can be used to better understand what exactly needs to be filled in.

    For many input fields it is known in which format they must be filled in. For example, in the Netherlands, a telephone number consists of 10 digits and a postal code consists of 4 digits and 2 letters. A good error message consists of the statement that the ‘phone number’ field has not been filled in correctly, and that a phone number consists of 10 digits.

    Do not write:

    • This field is not filled in correctly..

    But write:

    • ‘Date of birth’ is not entered correctly. Use the dd-mm-yyyy format.
    • The field ‘Phone number’ is not filled in correctly. A phone number consists of 10 digits.

    A few examples:

    • Date is written in dd-mm-yyyy format.
    • IBAN starts with 2 letters, 2 numbers, 4 letters.
    • Postal code consists of 4 digits and 2 letters.
    • Phone number consists of 10 digits.
    • URL starts with http:// or https://.

  • If by submitting a form an irreversible action that can have major consequences is taken, it should be possible to cancel, review or confirm the submission of the form.

    Visitors with a functional impairment often run a higher risk of making mistakes. People with dyslexia can flip letters and numbers around and people with motor disabilities can accidentally hit keys. In fact, all visitors benefit from the possibility of avoiding serious mistakes.

    For a form that involves a legal or financial transaction, you can use one of the following techniques:

    • After submitting the form, give the visitor a certain amount of time to change or cancel the submission.
    • Before the form is sent, show an overview of the entered data and offer the visitor the opportunity to change it.
    • Add a checkbox to the form that allows the visitor to indicate that they have checked the information and that it is correct before submitting the form.

    With a form that allows the visitor to change or delete data, such as profile data on a website, you can use one of the following techniques:

    • Provide the option to recover deleted data.
    • Request confirmation to proceed with the action of modifying or deleting.
    • Add a checkbox to the form that allows the visitor to indicate that they have checked the information and that it is correct before submitting the form.

    With a form that allows the visitor to answer questions from a test or an exam, you can use one of the following techniques:

    • Provide a possibility to review and correct the answers before they are submitted.
    • Request confirmation to continue submitting the answers.
  • Sometimes forms have to be completed within a certain time or a login session expires after a certain period of time. Such a time limit is not useful to visitors who need more time. For example, because they use the assistive technology or because they need more time to read the text due to a cognitive disability. Therefore, make sure that no time limit is used. If there really is no other way, give visitors the option to adjust the time limit. This can be done in one of the following ways:

    • Disable: Let visitors disable the time limit before it starts.
    • Adjust: Let visitors adjust the time limit to at least 10 times the time limit before it starts.
    • Extend: Warn visitors before the time expires and give them at least 20 seconds to extend the time limit. Have the visitor do this at least 10 times.

    Not all time limits require that they can be turned off, adjusted or extended. There are a few exceptions:

    • Real-time: When the time limit is part of a real-time event, such as auction bidding, and there is no alternative to the time limit.
    • Essential: If the time limit itself is essential, such as a test that must be completed in a certaina amount of time, and an extension would make it invalid.
    • More than 20 hours: If the time limit is more than 20 hours.
  • Changes to the content of a page are indicated by a status message. A status message adds new information to the page. For example, it provides the visitor with information about the results of an action, about the progress of a loading time or a warning about possible errors in a form. This information is important for everyone. It must therefore also be made available to a visitor who uses assistive technology.

    Assistive technology continuously synchronizes with the DOM and therefore notices the change, but the visitor who uses it is not informed about it. The aria-live attribute makes a live region out of a block. This information should be formatted in the code so that it gets the attention of the assistive technology in a way that does not unnecessarily interrupt the visitor.

    • The success or progress information is provided with an ARIA role="status" or an aria-live="polite".
    • For alerts, an ARIA role="alert" or an aria-live="assertive" are used.

    By default, the assistive technology will only read the changed text. If it is needed that the whole block is read, add aria-atomic="true".

    A visitor has no control over the spoken information. If a visitor (accidentally) touches a key, the announcement is interrupted and there is no way to listen to the information again.

  • Do not allow a major event to occur when a visitor fills in an input field, clicks a check box or radio button, or chooses a value from a drop-down list, unless the visitor has been informed beforehand. For many visitors, an unexpected event can be confusing. Visually impaired visitors may not be able to see the change. As a result, visitors who only navigate with the keyboard may have difficulty operating the website. Therefore, let the visitor click on a button to trigger the event.

    Major events are called context changes. The context changes are for example:

    • automatically submitting a form;
    • opening a browser window;
    • changing the focus to another part of the page.

    There should also be no change of context by changing the focus.


  • Principle 1. Perceivable
    • Guideline 1.3 Adaptable
      • 1.3.1 Info and Relationships
      • 1.3.5 Identify Input Purpose
  • Principle 2. Operable
    • Guideline 2.2 Enough Time
      • 2.2.1 Timing Adjustable
    • Guideline 2.4 Navigable
      • 2.4.6 Headings and Labels
  • Principle 3. Understandable
    • Guideline 3.2 Predictable
      • 3.2.1 On Focus
    • Guideline 3.3 Input Assistance
      • 3.3.1 Error Identification
      • 3.3.2 Labels or Instructions
      • 3.3.3 Error Suggestion
      • 3.3.4 Error Prevention (Legal, Financial, Data)
  • Principle 4. Robust
    • Guideline 4.1 Compatible
      • 4.1.3 Status Messages