Skip to main content

Inputs (<input>, <select>, <datalist>, <option>, <optgroup>, <ul>)

When To Use

  • Use inputs within a form to allow the user to input information.

Rules

  • Every input element needs an associated label. 1
  • Labeling should be done explicitly whenever possible. This means using the for attribute of a <label> to associate it to it‘s <input> via its input-id. See examples. 1
  • If explicit labeling is not possible, use implicit labeling, by nesting the <input> inside the <label> element. This approach is not always supported by assistive technologies. But you can make this solution more reliable by adding the "for" attribute to the label. See examples. 1
  • If the input has a visible explanation or should include one for assistive technologies**, use aria-describedby to link the explanation. This is very useful, since assistive technologies like screen readers enter "forms mode", which will only read out form elements. This is why text that is not associated with an input could be missed. You can also link descriptions by linking multiple ids like this: aria-describedby="id1 id2". 10 11
  • Make sure to label required or optional fields. This is not needed if the form is very simple, a learned pattern (like a login form) and only consists of either required or optional fields. When using an abrivation like an asterisk (*) it is benifitial to add a short explanation at the beginning of the form. 13
  • Mark required fields with the required or aria-required attributes. 13
  • Even if a visible label is not needed, make sure to still have a programmatic label. This can be achieved through a visually hidden <label> element, through the aria-label or aria-labelledby attributes.
    • But beware that visible labels are basically always are necessary to make the form understandable to all users including users with cognitive disabilities.
    • One example of an input that does not necessary need a visible label would be a search field with a search button next to it. 1
  • When using non-text content like an icon that is needed to understand the input or its state, make sure to comply with the minimum contrast rules as discussed in the Image article.
  • Make sure not to misuse placeholder text as a replacement for labels, because these are not broadly accessible. Don‘t put relevant information only in the placeholder text, without at least a hidden but accessible label with the same information. 1
    • Placeholder text often has not sufficient contrast. If possible try to meet the minimum contrast of 4.5:1. 1
  • If you are implementing a custom design for inputs like radio buttons or checkboxes, make sure that the actual input element has still a clickable area like described in hiding elements
  • If a button is created via the <input> element, then its accessible name is created by its value. See examples. 1
  • You can improve the usability and make the purpose of <input> elements of type="text" by adding the autocomplete attribute to it. For a list of possible values see the linked source. 12
  • Build a Better Mobile Input is a great resource to quickly create a fitting input elements.
  • When using the image button (<input type="image">), the text label should be specified within the alt attribute. 1
  • See the following table for a comparison between different selectable input implementations, to be able to decide when to use which. 1
  • The <option> and <optgroup> elements can be disabled with the disabled attribute.
InputNr of selectable ItemsOptions natively
browser-rendered 		Static
(permanently shown)		Text inputJavaScript
necessary		Notes
<input type="checkbox"> 2Zero, one or multiple itemsNoYesNoNonone
<input type="radio"> 3Zero, or one itemNoYesNoNonone
<select> 4, <option> 6
and <optgroup> 5		Zero or one itemYesNoNoNoUse <option> for the selectable choices.
Use <optgroup> to group these choices if needed.
<input list="datalist-id">,
<datalist> 7 and <option> 6		Zero, or one itemYesNoYesNonone
<input role="combobox"> 8Zero, or one itemNoNoYesYesSee Aria Roles Combobox for usage info.
<ul role="listbox"> 9Zero, one or multiple itemsNoYesNoYesUse <select> element, or a group of <radio> <checkbox> instead,
because there is a lot of keyboard interactivity needed
to manage when using a listbox.
See Aria Roles Listbox for usage info.

Examples

Explicitly label an input. 1

<label for="firstname">First name:</label>
<input type="text" name="firstname" id="firstname">

Implicity label an input. 1

<label>
  First name:
  <input type="text" name="firstname">
</label>

Accessible name for an input button. 1

<input type="submit" value="Submit">
<input type="button" value="Cancel">

Live Search Results/Type Ahead

  • When implementing a search with live search results, there are multiple patterns you can use. Whichever pattern you implement, make sure to thoroughly test it.
  • One common pattern is to use the draft ARIA 1.2 combobox pattern, as shown below: 17 14 15 18
  • You should also ensure that your search results and the required information are properly announced. See Scott O'Hara's proposal: 16
    • Live Regions: Only communicate plain text. Use alternatives if semantic or detailed accessibility information is needed. 16
    • Avoid Interruptions: Refrain from constant updates as users type, such as announcing result counts, which can disrupt the experience. 16
    • Typing Speeds: Support users who type slowly due to disabilities or those who quickly finish typing and miss announcements. Live regions may not reliably serve both groups. 16
    • No Results: Use an assertive live region to notify users immediately when no results are found, saving unnecessary effort. 16
    • Implementation: Populate an existing empty live region with messages for robust compatibility, rather than dynamically injecting it. 16
<label for="tag_combo">Tag</label>
<input type="text" id="tag_combo"
  role="combobox" aria-autocomplete="list"
  aria-haspopup="listbox" aria-expanded="true"
  aria-controls="popup_listbox" aria-activedescendant="selected_option">
<ul role="listbox" id="popup_listbox">
   <li role="option">Zebra</li>
   <li role="option" id="selected_option">Zoom</li>
</ul>

Sources 

  1. W3C ARIA: Labeling Controls by W3C WAI Tutorial Contributors is licensed under W3C Document License
  2. MDN: <input type="checkbox"> by Mozilla contributors is licensed under CC-BY-SA 2.5
  3. MDN: <input type="radio"> by Mozilla contributors is licensed under CC-BY-SA 2.5
  4. MDN: <select>: The HTML Select element by Mozilla contributors is licensed under CC-BY-SA 2.5
  5. MDN: <optgroup>: The Option Group element by Mozilla contributors is licensed under CC-BY-SA 2.5
  6. MDN: <option>: The HTML Option element by Mozilla contributors is licensed under CC-BY-SA 2.5
  7. MDN: <datalist>: The HTML Data List element by Mozilla contributors is licensed under CC-BY-SA 2.5
  8. MDN: ARIA: combobox role by Mozilla contributors is licensed under CC-BY-SA 2.5
  9. MDN: ARIA: listbox role by Mozilla contributors is licensed under CC-BY-SA 2.5
  10. TPGi: Describing aria-describedby by Scott O‘Hara © TPGi – a Vispero™ Company
  11. W3C ARIA: Form Instructions by W3C WAI Tutorial Contributors is licensed under W3C Document License
  12. HTML Spec: 4.10.18.7 Autofill is licensed under Creative Commons Attribution 4.0 International License
  13. TPGi: Doing what’s required: Indicating mandatory fields in an accessible way by David Swallow © TPGi – a Vispero™ Company
  14. Accessible site search with combobox suggestions by Darren Lee Make Things Accessible (v2.0)
  15. <select> your poison by Sarah Higley
  16. Considering dynamic search results and content by Scott Ohara Scott O'Hara
  17. Accessible Rich Internet Applications (WAI-ARIA) 1.2 by Participants active in the ARIA WG World Wide Web Consortium. W3C®
  18. Editable Combobox With Both List and Inline Autocomplete Example by W3C ARIA Task Forces is licensed under W3C Document License
Created at: 19.04.2023, Last updated at: 22.11.2024