Test: HTML input with datalist test

Expectation for the datalist element: convey its role

This expectation is from the datalist element feature.

Rationale:

A screen reader user needs to know how they can interact with the element. Voice control software might use the role to help users activate controls that do not have a visible name.

Strength of this expectation for different types of assistive technologies:

• Screen Readers: MUST
• Voice Control: MUST

Examples:

• A screen reader might announce something like the "datalist", "listbox" role when entering the datalist. Note that it should not be conveyed as a menu per the AAM mappings.
• A screen reader might not announce the datalist role because it is implied by the presence of suggestions or auto complete functionality via the list attribute.
• Voice control software might let the user say something like "show choices" to open the datalist.

Grading method:

Just one of the listed commands must pass for the expectation to pass.

Expectation for the datalist element: convey the boundaries of the element

This expectation is from the datalist element feature.

Rationale:

A user needs to know when they enter and exit an element

Strength of this expectation for different types of assistive technologies:

• Screen Readers: MUST
• Voice Control: NA

Examples:

• A screen reader might announce the role of the element when entering and say something like "leaving" when exiting.
• A screen reader might not explicitly announce entering and existing the element, but instead imply that the is in the containing object by conveying the roles of required children (options in a listbox for example).
• A screen reader might announce position in set information such as "1 of 6".
• A screen reader might not convey boundaries if the content fits on a single line

Grading method:

All of the listed commands must pass for the expectation to pass.

Expectation for the datalist element: convey that changes in suggestions were made

This expectation is from the datalist element feature.

Rationale:

The user needs to know that the list of suggestions changed

Strength of this expectation for different types of assistive technologies:

• Screen Readers: SHOULD
• Voice Control: NA

Examples:

• A screen reader might announce the word "suggestions" whenever the list of suggestions changes.
• A screen reader might announce the value of every suggestion when the list of suggestions changes.

Grading method:

Just one of the listed commands must pass for the expectation to pass.

Expectation for the input[type="text"] element: convey its name

This expectation is from the input[type="text"] element feature.

Rationale:

A screen reader user needs to know what to enter.

Strength of this expectation for different types of assistive technologies:

• Screen Readers: MUST
• Voice Control: MUST

Examples:

• A screen reader will announce the name (label).
• Voice control software will let the user say something like "click <name>" to activate the control.

Grading method:

Just one of the listed commands must pass for the expectation to pass.

Notes:

For form inputs - commands to read line by line (down and up arrows in most windows screen readers) will not always result in the name being explicitly conveyed when the virtual focus is moved to an input where the label is visually displayed and programmatically associated with the input. This is acceptable because the name is implied by the fact that it should be naturally found in the reading order. Some screen readers choose to not convey the name in these cases, likely in an effort to reduce verbosity.

Expectation for the input[type="text"] element: convey its role

This expectation is from the input[type="text"] element feature.

Rationale:

A screen reader user needs to know how they can interact with the element. Voice control software might use the role to help users activate controls that do not have a visible name.

Strength of this expectation for different types of assistive technologies:

• Screen Readers: MUST
• Voice Control: MUST

Examples:

• A screen reader might be announce the role as "text input", "edit", "edit text", etc.
• A screen reader might announce a modified role when a datalist is attached, such as "combo box".
• Voice control software will let the user say something like "click text box" to focus a the input or flag the role with a number.

Grading method:

Just one of the listed commands must pass for the expectation to pass.

Expectation for the input[type="text"] element: convey the current value

This expectation is from the input[type="text"] element feature.

Rationale:

A screen reader user needs to know the current value of the input.

Strength of this expectation for different types of assistive technologies:

• Screen Readers: MUST
• Voice Control: NA

Grading method:

Just one of the listed commands must pass for the expectation to pass.

Expectation for the input[type="text"] element: convey changes in value

This expectation is from the input[type="text"] element feature.

Rationale:

The user needs to know that the value was successfully changed.

Strength of this expectation for different types of assistive technologies:

• Screen Readers: MUST
• Voice Control: NA

Examples:

• When the user enter texts, the screen reader will announce it back to them.
• When used with the datalist, the chosen suggestion should be announced after activating it.

Grading method:

All of the listed commands must pass for the expectation to pass.

Expectation for the input[type="text"] element: provide shortcuts to jump to this role

This expectation is from the input[type="text"] element feature.

Rationale:

Screen reader users might want to quickly navigate to elements of this type.

Strength of this expectation for different types of assistive technologies:

• Screen Readers: SHOULD
• Voice Control: NA

Grading method:

Just one of the listed commands must pass for the expectation to pass.