Form field has accessible name

  • Rule Typeatomic
  • Rule ID: e086e5
  • Last modified: Aug 21, 2019
  • Accessibility Requirements Mapping
    • 4.1.2 Name, Role, Value (Level: A)
      • Learn More about 4.1.2 (Name, Role, Value)
      • Required for conformance to WCAG 2.0 and above on level A and above
      • Outcome mapping:
        • Any failed outcomes: not satisfied
        • All passed outcomes: further testing is needed
        • An inapplicable outcome: further testing is needed
  • Input Aspects


This rule checks that each form field element has an accessible name.


This rule applies to any element that is included in the accessibility tree, and that has one of the following semantic roles: checkbox, combobox (select elements), listbox, menuitemcheckbox, menuitemradio, radio, searchbox, slider, spinbutton, switch, textbox.

Note: The list of roles is derived by taking all the ARIA 1.1 roles that:

  • have a semantic roles that inherits from the abstract input or select role, and
  • does not have a required context role that itself inherits from one of those roles.
  • The option role is not part of the list of applicable roles, because it does not meet the definition of a User interface component. This means WCAG 2.1 does not require it to have an accessible name.


Each target element has an accessible name that is not only whitespace.


There are currently no assumptions

Accessibility Support

Certain assistive technologies can be set up to ignore the title attribute, which means that to some users the title attribute will not act as an accessible name.


Note: This rule does not fail 3.3.2 as there are sufficient techniques within 3.3.2 that don't need the elements to have an accessible name. For example "G131: Providing descriptive labels" AND "G162: Positioning labels to maximize predictability of relationships" would be sufficient.

Test Cases


Passed Example 1

Implicit role with implicit label.

	first name
	<input />

Passed Example 2

Implicit role with aria-label

<input aria-label="last name" disabled />

Passed Example 3

Implicit role with explicit label

<label for="country">Country</label>
<select id="country">

Passed Example 4

Implicit role with aria-labelledby.

<div id="country">Country</div>
<textarea aria-labelledby="country"></textarea>

Passed Example 5

Explicit role.

<div aria-label="country" role="combobox" aria-disabled="true">England</div>

Passed Example 6

The accessible name is not only whitespace.

	<input />


Failed Example 1

No accessible name.

<input />

Failed Example 2

Non-focusable element still needs an accessible name.

<input tabindex="-1" />

Failed Example 3

aria-label with empty text string

<div aria-label=" " role="combobox">England</div>

Failed Example 4

The label does not exist.

<div aria-labelledby="non-existing" role="combobox">England</div>

Failed Example 5

The implicit label is not supported on div elements.

	first name
	<div role="textbox"></div>

Failed Example 6

The explicit label is not supported on div elements.

<label for="lastname">first name</label>
<div role="textbox" id="lastname"></div>

Failed Example 7

The accessible name is only whitespace.

<label> <input /></label>


Inapplicable Example 1

Hidden to everyone.

<input aria-label="firstname" style="display:none;" />

Inapplicable Example 2

Hidden to assistive technologies.

<input aria-hidden="true" aria-label="firstname" />

Inapplicable Example 3

Role has explicitly been set to something that isn't a form field.

<input role="presentation" />

Inapplicable Example 4

Option inherits from input, but has a required context role of listbox which inherits from select. We should therefore not consider option as applicable.

<select role="none">
	<option value="volvo">Volvo</option>
	<option value="saab">Saab</option>
	<option value="opel">Opel</option>


Accessible Name

key: accessible-name

The programmatically determined name of a user interface element that is included in the accessibility tree.

The accessible name is calculated using the accessible name and description computation.

For native markup languages, such as HTML and SVG, additional information on how to calculate the accessible name can be found in HTML Accessibility API Mappings 1.0, Accessible Name and Description Computation (work in progress) and SVG Accessibility API Mappings, Name and Description (work in progress).

Explicit Semantic Role

key: explicit-role

The explicit semantic role is the semantic role of an element set by its role attribute.

The role attribute takes a list of tokens. The explicit semantic role is the first valid role in this list. If none of the tokens are valid, the implicit semantic role will be used instead.

Non-abstract roles defined in the following specifications are considered valid:

Other roles may be added as they become available. Not all roles will be supported in all assistive technologies. Testers are encouraged to adjust which roles are allowed according to the accessibility support base line. For the purposes of executing test cases in all rules, it should be assumed that all roles are supported by assistive technologies so that none of the roles fail due to lack of accessibility support.

Acccessibility Support

Some browsers and assistive technologies treat the tokens of the role attribute as case-sensitive. Unless lowercase letters are used for the value of the role attribute, not all user agents will be able to interpret the tokens correctly. ARIA in HTML also specifies that authors must use lowercase letters for the role and aria-* attributes (work in progress).

Implicit Semantic Role

key: implicit-role

The Implicit Semantic Role is the semantic role of each element that is used when no valid explicit semantic role is specified. Elements with no role attribute, or with a role attribute containing no valid token, are mapped to their implicit role.

Implicit roles for HTML and SVG, are documented in the HTML accessibility API mappings (work in progress), the ARIA in HTML (work in progress) documentation, and the SVG accessibility API mappings (work in progress).

Included in the accessibility tree

key: included-in-the-accessibility-tree

Elements included in the accessibility tree of platform specific accessibility APIs. Elements in the accessibility tree are exposed to assistive technologies, allowing users to interact with the elements in a way that meet the requirements of the individual user.

The general rules for when elements are included in the accessibility tree are defined in the core accessibility API mappings. For native markup languages, such as HTML and SVG, additional rules for when elements are included in the accessibility tree can be found in the HTML accessibility API mappings (work in progress) and the SVG accessibility API mappings (work in progress).

Note: Users of assistive technologies might still be able to interact with elements that are not included in the accessibility tree. An example of this is a focusable element with an aria-hidden attribute with a value of true. Such an element could still be interacted with using sequential keyboard navigation regardless of the assistive technologies used, even though the element would not be included in the accessibility tree.


key: outcome

A conclusion that comes from evaluating an ACT Rule on a test subject or one of its constituent test target. An outcome can be one of the three following types:

  • Inapplicable: No part of the test subject matches the applicability
  • Passed: A test target meets all expectations
  • Failed: A test target does not meet all expectations

Note: A rule has one passed or failed outcome for every test target. When there are no test targets the rule has one inapplicable outcome. This means that each test subject will have one or more outcomes.

Note: Implementers using the EARL10-Schema can express the outcome with the outcome property. In addition to passed, failed and inapplicable, EARL 1.0 also defined an incomplete outcome. While this cannot be the outcome of an ACT Rule when applied in its entirety, it often happens that rules are only partially evaluated. For example, when applicability was automated, but the expectations have to be evaluated manually. Such "interim" results can be expressed with the incomplete outcome.

Semantic Role

key: semantic-role

A semantic role is a semantic association that indicates an object's type. This allows tools to present and support interaction with the object in a manner that is consistent with user expectations about other objects of that type.

The semantic role of an element is its explicit semantic role if it has any, otherwise, the implicit semantic role is used.


key: whitespace

Characters that have the Unicode "White_Space" property in the Unicode properties list.

This includes:

  • all characters in the Unicode Separator categories, and
  • the following characters in the Other, Control category:

    • Character tabulation (U+0009)
    • Line Feed (LF) (U+000A)
    • Line Tabulation (U+000B)
    • Form Feed (FF) (U+000C)
    • Carriage Return (CR) (U+000D)
    • Next Line (NEL) (U+0085)


Aug 21, 2019test: add tests to verify h4 headings (#810)
Aug 21, 2019fix: update links to WCAG21 resources (#776)
Aug 21, 2019Editorial changes (#725)
Aug 14, 2019feat: Define implicit/explicit role (4e8ab6, b20e66, c487ae, e086e5, 5c01ea) (#689)
Jul 26, 2019Editorial changes (#702)
Jul 2, 2019chore: Correct various typos (#640)
May 18, 2019chore: Validating rules frontmatter on CI (#551)
May 15, 2019Glossary and Rule update: Replacing "non-empty" definition (#430)
May 9, 2019Chore: Adapt site to ACT Rules CR format (#547)
May 7, 2019Template update - Form field has accessible name (#508)
Apr 29, 2019chore: rename files and update associations (#489)
Apr 16, 2019chore: add unique id to all rules (#478)
Apr 15, 2019chore: WCAG ACT RULES CG Website Update (#437)
Feb 13, 2019Removed 3.3.2 from name and list of success criterion (#379)
Nov 19, 2018Remove "focusable" and "is visible" from Applicability in several rules due to consistency concerns (#310)
Nov 12, 2018chore: remove selector `data-rule-target` (#347)
Oct 29, 2018Add SC 4.1.2 to form-field-has-name (#319)
Oct 12, 2018"Included in accessibility tree" instead of "exposed to assistive technologies" (#269)
Oct 9, 2018Fix: testcase generation (#296)
Aug 30, 2018Chore: Update test cases format and descriptions (#230)
Aug 13, 2018fix: aria prop id mismatch
Jul 19, 2018Rule: SC3-3-2-form-field-has-name (#152)

Useful Links


Tool NameCreated ByReport
AlfaSiteimproveView Report