Important: This website does not attempt to establish a standard for how assistive technologies must behave. Read the FAQ for more information. Additionally, this is a work in progress. Please submit feedback or suggestions.

Run Test: The html required attribute on each HTML radio button in a fieldset

Current support: undefined

This test checks the html required attribute as applied to each HTML radio button in a fieldset. Some general notes: * The HTML spec suggests that it is okay to place the required attribute on only one of the radio buttons, however, only that radio button will be conveyed as required. Other radio buttons in the group will not be conveyed as required, and if screen reader user jumps to a radio button that doesn't have a required attribute then the requiredness might of the group might be missed. * Currently, the most robust solution to mark a group of radio buttons as required is to place the text 'required' in the group label. * In most screen readers, this technique will result in the required state being conveyed for each radio in the group. Some users might find this confusing since only one radio can be selected at a time.

Go back to the test details page

Step 1: What are you testing with?

Select your testing combination.

Note: your selection will be saved until you change it or clear your browser cache.

Make sure everything is up to date

Always make sure that your OS, Browser, and Assistive technology are up to date with the latest production versions before submitting test results. Also make sure that your assistive technology is set to factory defaults.

Please be sure to read the full instructions before completing the test.

Step 2: Run test cases and submit your findings

Launch the chosen assistive technology that you want to test with.
Ensure that your OS, AT, and Browser are all up to date.
Navigate to the test page iframe (after these instructions) or open the test page.
For each test case, locate the target element(s) and test whether or not the expectations are met

Note: Screen readers will usually announce an element in the format: "<role>, <accessible name>, <other states and properties>, <accessible description>". The order in which the name, role, and properties are announced might differ between screen readers. The exact vocabulary used will also differ.

Technology information

The selected AT/Browser combo is:

Use the "what are you testing with?" form to change your combination.

AT Version (required)

OS Version (required)

Browser Version (required)

Test cases for JAWS + Chrome

Test case: Use Down arrow (Read next item) to navigate forward to `*[required]`

Launch JAWS and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Down arrow (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

input[type="radio"] element, MUST convey its name

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.

Result

Notes

input[type="radio"] element, MUST convey its role

Examples:

A screen reader might be announce the role as "radio"
Voice control software will let the user say something like "click radio" to focus a the input or flag the role with a number.

Result

Notes

input[type="radio"] element, MUST convey the position in set information

Examples:

A screen reader might something like "1 of 6".

Result

Notes

input[type="radio"] element, MUST convey the unchecked state

Examples:

A screen reader might announce "unchecked" or imply that the element is not checked by not announcing the checked state at all.

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward to `*[required]`

Launch JAWS and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

legend element, MUST convey its nameResult

Notes

input[type="radio"] element, MUST convey its name

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.

Result

Notes

input[type="radio"] element, MUST convey its role

Examples:

A screen reader might be announce the role as "radio"
Voice control software will let the user say something like "click radio" to focus a the input or flag the role with a number.

Result

Notes

input[type="radio"] element, MUST convey the position in set information

Examples:

A screen reader might something like "1 of 6".

Result

Notes

input[type="radio"] element, MUST convey the unchecked state

Examples:

A screen reader might announce "unchecked" or imply that the element is not checked by not announcing the checked state at all.

Result

Notes

Test case: Use Up arrow (Read previous item) to navigate backwards to `*[required]`

Launch JAWS and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Up arrow (Read previous item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

Test case: Use Shift + Tab (Read previous focusable item) to navigate backwards to `*[required]`

Launch JAWS and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Shift + Tab (Read previous focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

legend element, MUST convey its nameResult

Notes

Test case: Use Down arrow (Read next item) to navigate forward to the start of `fieldset`

Launch JAWS and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Down arrow (Read next item)
- After issuing the command, virtual focus should be: start of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

legend element, MUST convey its nameResult

Notes

Test case: Use Up arrow (Read previous item) to navigate backwards to the end of `fieldset`

Launch JAWS and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Up arrow (Read previous item)
- After issuing the command, virtual focus should be: end of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

Test case: Use Down arrow (Read next item) to navigate forward to `input[type="radio"][checked]`

Launch JAWS and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"][checked]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Down arrow (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the checked state

Examples:

A screen reader might announce "checked"

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward to `input[type="radio"][checked]`

Launch JAWS and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"][checked]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the checked state

Examples:

A screen reader might announce "checked"

Result

Notes

Test case: Use Space (Activate Form Control) on the target of `input[type="radio"]`

Launch JAWS and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: target
- Keyboard focus is: target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Space (Activate Form Control)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey a change in the checked state

Examples:

A screen reader might announce "checked" or "not checked"
A screen reader might announce the entire control again with the new state

Result

Notes

Test case: Use f (Next form field) to navigate forward to `input[type="radio"]`

Launch JAWS and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: f (Next form field)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, SHOULD provide shortcuts to jump to this roleResult

Notes

Test case: Use Insert + F3 (Open element list)

Launch JAWS and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Mode is: auto (do not explicitly change the mode)
Issue the command: Insert + F3 (Open element list)
- After issuing the command, virtual focus should be: na
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, SHOULD provide shortcuts to jump to this roleResult

Notes

Test cases for JAWS + Edge

Test case: Use Down arrow (Read next item) to navigate forward to `*[required]`

Launch JAWS and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Down arrow (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

input[type="radio"] element, MUST convey its name

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.

Result

Notes

input[type="radio"] element, MUST convey its role

Examples:

A screen reader might be announce the role as "radio"
Voice control software will let the user say something like "click radio" to focus a the input or flag the role with a number.

Result

Notes

input[type="radio"] element, MUST convey the position in set information

Examples:

A screen reader might something like "1 of 6".

Result

Notes

input[type="radio"] element, MUST convey the unchecked state

Examples:

A screen reader might announce "unchecked" or imply that the element is not checked by not announcing the checked state at all.

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward to `*[required]`

Launch JAWS and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

legend element, MUST convey its nameResult

Notes

input[type="radio"] element, MUST convey its name

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.

Result

Notes

input[type="radio"] element, MUST convey its role

Examples:

A screen reader might be announce the role as "radio"
Voice control software will let the user say something like "click radio" to focus a the input or flag the role with a number.

Result

Notes

input[type="radio"] element, MUST convey the position in set information

Examples:

A screen reader might something like "1 of 6".

Result

Notes

input[type="radio"] element, MUST convey the unchecked state

Examples:

A screen reader might announce "unchecked" or imply that the element is not checked by not announcing the checked state at all.

Result

Notes

Test case: Use Up arrow (Read previous item) to navigate backwards to `*[required]`

Launch JAWS and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Up arrow (Read previous item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

Test case: Use Shift + Tab (Read previous focusable item) to navigate backwards to `*[required]`

Launch JAWS and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Shift + Tab (Read previous focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

legend element, MUST convey its nameResult

Notes

Test case: Use Down arrow (Read next item) to navigate forward to the start of `fieldset`

Launch JAWS and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Down arrow (Read next item)
- After issuing the command, virtual focus should be: start of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

legend element, MUST convey its nameResult

Notes

Test case: Use Up arrow (Read previous item) to navigate backwards to the end of `fieldset`

Launch JAWS and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Up arrow (Read previous item)
- After issuing the command, virtual focus should be: end of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

Test case: Use Down arrow (Read next item) to navigate forward to `input[type="radio"][checked]`

Launch JAWS and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"][checked]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Down arrow (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the checked state

Examples:

A screen reader might announce "checked"

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward to `input[type="radio"][checked]`

Launch JAWS and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"][checked]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the checked state

Examples:

A screen reader might announce "checked"

Result

Notes

Test case: Use Space (Activate Form Control) on the target of `input[type="radio"]`

Launch JAWS and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: target
- Keyboard focus is: target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Space (Activate Form Control)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey a change in the checked state

Examples:

A screen reader might announce "checked" or "not checked"
A screen reader might announce the entire control again with the new state

Result

Notes

Test case: Use f (Next form field) to navigate forward to `input[type="radio"]`

Launch JAWS and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: f (Next form field)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, SHOULD provide shortcuts to jump to this roleResult

Notes

Test case: Use Insert + F3 (Open element list)

Launch JAWS and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Mode is: auto (do not explicitly change the mode)
Issue the command: Insert + F3 (Open element list)
- After issuing the command, virtual focus should be: na
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, SHOULD provide shortcuts to jump to this roleResult

Notes

Test cases for JAWS + Firefox

Test case: Use Down arrow (Read next item) to navigate forward to `*[required]`

Launch JAWS and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Down arrow (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

Test case: Use Tab (Read next focusable item) to navigate forward to `*[required]`

Launch JAWS and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

Test case: Use Up arrow (Read previous item) to navigate backwards to `*[required]`

Launch JAWS and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Up arrow (Read previous item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

Test case: Use Shift + Tab (Read previous focusable item) to navigate backwards to `*[required]`

Launch JAWS and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Shift + Tab (Read previous focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

Test case: Use Down arrow (Read next item) to navigate forward to the start of `fieldset`

Launch JAWS and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Down arrow (Read next item)
- After issuing the command, virtual focus should be: start of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward into `fieldset`

Launch JAWS and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

Test case: Use Up arrow (Read previous item) to navigate backwards to the end of `fieldset`

Launch JAWS and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Up arrow (Read previous item)
- After issuing the command, virtual focus should be: end of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

Test case: Use Shift + Tab (Read previous focusable item) to navigate backwards into `fieldset`

Launch JAWS and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Shift + Tab (Read previous focusable item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

Test case: Use Down arrow (Read next item) to navigate forward to the start of `legend, fieldset`

Launch JAWS and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:legend, fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Down arrow (Read next item)
- After issuing the command, virtual focus should be: start of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

legend element, MUST convey its nameResult

Notes

Test case: Use Tab (Read next focusable item) to navigate forward into `legend, fieldset`

Launch JAWS and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:legend, fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

legend element, MUST convey its nameResult

Notes

Test case: Use Up arrow (Read previous item) to navigate backwards to the end of `legend, fieldset`

Launch JAWS and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:legend, fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Up arrow (Read previous item)
- After issuing the command, virtual focus should be: end of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

legend element, MUST convey its nameResult

Notes

Test case: Use Shift + Tab (Read previous focusable item) to navigate backwards into `legend, fieldset`

Launch JAWS and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:legend, fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Shift + Tab (Read previous focusable item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

legend element, MUST convey its nameResult

Notes

Test case: Use Down arrow (Read next item) to navigate forward to `input[type="radio"]`

Launch JAWS and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Down arrow (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey its name

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.

Result

Notes

input[type="radio"] element, MUST convey its role

Examples:

A screen reader might be announce the role as "radio"
Voice control software will let the user say something like "click radio" to focus a the input or flag the role with a number.

Result

Notes

input[type="radio"] element, MUST convey the position in set information

Examples:

A screen reader might something like "1 of 6".

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward to `input[type="radio"]`

Launch JAWS and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey its name

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.

Result

Notes

input[type="radio"] element, MUST convey its role

Examples:

A screen reader might be announce the role as "radio"
Voice control software will let the user say something like "click radio" to focus a the input or flag the role with a number.

Result

Notes

input[type="radio"] element, MUST convey the position in set information

Examples:

A screen reader might something like "1 of 6".

Result

Notes

Test case: Use Down arrow (Read next item) to navigate forward to `input[type="radio"][checked]`

Launch JAWS and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"][checked]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Down arrow (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the checked state

Examples:

A screen reader might announce "checked"

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward to `input[type="radio"][checked]`

Launch JAWS and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"][checked]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the checked state

Examples:

A screen reader might announce "checked"

Result

Notes

Test case: Use Down arrow (Read next item) to navigate forward to `input[type="radio"]:not(checked)`

Launch JAWS and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]:not(checked)
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Down arrow (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the unchecked state

Examples:

A screen reader might announce "unchecked" or imply that the element is not checked by not announcing the checked state at all.

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward to `input[type="radio"]:not(checked)`

Launch JAWS and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]:not(checked)
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the unchecked state

Examples:

A screen reader might announce "unchecked" or imply that the element is not checked by not announcing the checked state at all.

Result

Notes

Test case: Use Space (Activate Form Control) on the target of `input[type="radio"]`

Launch JAWS and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: target
- Keyboard focus is: target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Space (Activate Form Control)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey a change in the checked state

Examples:

A screen reader might announce "checked" or "not checked"
A screen reader might announce the entire control again with the new state

Result

Notes

Test case: Use f (Next form field) to navigate forward to `input[type="radio"]`

Launch JAWS and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: f (Next form field)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, SHOULD provide shortcuts to jump to this roleResult

Notes

Test case: Use Insert + F3 (Open element list)

Launch JAWS and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Mode is: auto (do not explicitly change the mode)
Issue the command: Insert + F3 (Open element list)
- After issuing the command, virtual focus should be: na
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, SHOULD provide shortcuts to jump to this roleResult

Notes

Test cases for JAWS + IE

Test case: Use Down arrow (Read next item) to navigate forward to `*[required]`

Launch JAWS and IE.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Down arrow (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

Test case: Use Tab (Read next focusable item) to navigate forward to `*[required]`

Launch JAWS and IE.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

Test case: Use Up arrow (Read previous item) to navigate backwards to `*[required]`

Launch JAWS and IE.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Up arrow (Read previous item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

Test case: Use Shift + Tab (Read previous focusable item) to navigate backwards to `*[required]`

Launch JAWS and IE.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Shift + Tab (Read previous focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

Test case: Use Down arrow (Read next item) to navigate forward to the start of `fieldset`

Launch JAWS and IE.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Down arrow (Read next item)
- After issuing the command, virtual focus should be: start of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward into `fieldset`

Launch JAWS and IE.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

Test case: Use Up arrow (Read previous item) to navigate backwards to the end of `fieldset`

Launch JAWS and IE.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Up arrow (Read previous item)
- After issuing the command, virtual focus should be: end of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

Test case: Use Shift + Tab (Read previous focusable item) to navigate backwards into `fieldset`

Launch JAWS and IE.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Shift + Tab (Read previous focusable item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

Test case: Use Down arrow (Read next item) to navigate forward to the start of `legend, fieldset`

Launch JAWS and IE.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:legend, fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Down arrow (Read next item)
- After issuing the command, virtual focus should be: start of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

legend element, MUST convey its nameResult

Notes

Test case: Use Tab (Read next focusable item) to navigate forward into `legend, fieldset`

Launch JAWS and IE.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:legend, fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

legend element, MUST convey its nameResult

Notes

Test case: Use Up arrow (Read previous item) to navigate backwards to the end of `legend, fieldset`

Launch JAWS and IE.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:legend, fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Up arrow (Read previous item)
- After issuing the command, virtual focus should be: end of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

legend element, MUST convey its nameResult

Notes

Test case: Use Shift + Tab (Read previous focusable item) to navigate backwards into `legend, fieldset`

Launch JAWS and IE.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:legend, fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Shift + Tab (Read previous focusable item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

legend element, MUST convey its nameResult

Notes

Test case: Use Down arrow (Read next item) to navigate forward to `input[type="radio"]`

Launch JAWS and IE.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Down arrow (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey its name

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.

Result

Notes

input[type="radio"] element, MUST convey its role

Examples:

A screen reader might be announce the role as "radio"
Voice control software will let the user say something like "click radio" to focus a the input or flag the role with a number.

Result

Notes

input[type="radio"] element, MUST convey the position in set information

Examples:

A screen reader might something like "1 of 6".

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward to `input[type="radio"]`

Launch JAWS and IE.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey its name

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.

Result

Notes

input[type="radio"] element, MUST convey its role

Examples:

A screen reader might be announce the role as "radio"
Voice control software will let the user say something like "click radio" to focus a the input or flag the role with a number.

Result

Notes

input[type="radio"] element, MUST convey the position in set information

Examples:

A screen reader might something like "1 of 6".

Result

Notes

Test case: Use Down arrow (Read next item) to navigate forward to `input[type="radio"][checked]`

Launch JAWS and IE.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"][checked]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Down arrow (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the checked state

Examples:

A screen reader might announce "checked"

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward to `input[type="radio"][checked]`

Launch JAWS and IE.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"][checked]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the checked state

Examples:

A screen reader might announce "checked"

Result

Notes

Test case: Use Down arrow (Read next item) to navigate forward to `input[type="radio"]:not(checked)`

Launch JAWS and IE.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]:not(checked)
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Down arrow (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the unchecked state

Examples:

A screen reader might announce "unchecked" or imply that the element is not checked by not announcing the checked state at all.

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward to `input[type="radio"]:not(checked)`

Launch JAWS and IE.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]:not(checked)
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the unchecked state

Examples:

A screen reader might announce "unchecked" or imply that the element is not checked by not announcing the checked state at all.

Result

Notes

Test case: Use Space (Activate Form Control) on the target of `input[type="radio"]`

Launch JAWS and IE.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: target
- Keyboard focus is: target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Space (Activate Form Control)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey a change in the checked state

Examples:

A screen reader might announce "checked" or "not checked"
A screen reader might announce the entire control again with the new state

Result

Notes

Test case: Use f (Next form field) to navigate forward to `input[type="radio"]`

Launch JAWS and IE.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: f (Next form field)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, SHOULD provide shortcuts to jump to this roleResult

Notes

Test case: Use Insert + F3 (Open element list)

Launch JAWS and IE.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Mode is: auto (do not explicitly change the mode)
Issue the command: Insert + F3 (Open element list)
- After issuing the command, virtual focus should be: na
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, SHOULD provide shortcuts to jump to this roleResult

Notes

Test cases for Narrator + Edge

Test case: Use Down arrow (Jump to next item (scan mode)) to navigate forward to the start of `*[required]`

Launch Narrator and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Down arrow (Jump to next item (scan mode))
- After issuing the command, virtual focus should be: start of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

Test case: Use Tab (Read next focusable item) to navigate forward into `*[required]`

Launch Narrator and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

Test case: Use Up arrow (Jump to previous item (scan mode)) to navigate backwards to the end of `*[required]`

Launch Narrator and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Up arrow (Jump to previous item (scan mode))
- After issuing the command, virtual focus should be: end of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

Test case: Use Shift + Tab (Read previous focusable item) to navigate backwards into `*[required]`

Launch Narrator and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Shift + Tab (Read previous focusable item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

Test case: Use Down arrow (Jump to next item (scan mode)) to navigate forward to the start of `fieldset`

Launch Narrator and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Down arrow (Jump to next item (scan mode))
- After issuing the command, virtual focus should be: start of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward into `fieldset`

Launch Narrator and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

Test case: Use Up arrow (Jump to previous item (scan mode)) to navigate backwards to the end of `fieldset`

Launch Narrator and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Up arrow (Jump to previous item (scan mode))
- After issuing the command, virtual focus should be: end of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

Test case: Use Shift + Tab (Read previous focusable item) to navigate backwards into `fieldset`

Launch Narrator and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Shift + Tab (Read previous focusable item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

Test case: Use Down arrow (Jump to next item (scan mode)) to navigate forward to the start of `legend, fieldset`

Launch Narrator and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:legend, fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Down arrow (Jump to next item (scan mode))
- After issuing the command, virtual focus should be: start of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

legend element, MUST convey its nameResult

Notes

Test case: Use Tab (Read next focusable item) to navigate forward into `legend, fieldset`

Launch Narrator and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:legend, fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

legend element, MUST convey its nameResult

Notes

Test case: Use Up arrow (Jump to previous item (scan mode)) to navigate backwards to the end of `legend, fieldset`

Launch Narrator and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:legend, fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Up arrow (Jump to previous item (scan mode))
- After issuing the command, virtual focus should be: end of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

legend element, MUST convey its nameResult

Notes

Test case: Use Shift + Tab (Read previous focusable item) to navigate backwards into `legend, fieldset`

Launch Narrator and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:legend, fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Shift + Tab (Read previous focusable item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

legend element, MUST convey its nameResult

Notes

Test case: Use Down arrow (Jump to next item (scan mode)) to navigate forward to the start of `input[type="radio"]`

Launch Narrator and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Down arrow (Jump to next item (scan mode))
- After issuing the command, virtual focus should be: start of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey its name

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.

Result

Notes

input[type="radio"] element, MUST convey its role

Examples:

A screen reader might be announce the role as "radio"
Voice control software will let the user say something like "click radio" to focus a the input or flag the role with a number.

Result

Notes

input[type="radio"] element, MUST convey the position in set information

Examples:

A screen reader might something like "1 of 6".

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward into `input[type="radio"]`

Launch Narrator and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey its name

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.

Result

Notes

input[type="radio"] element, MUST convey its role

Examples:

A screen reader might be announce the role as "radio"
Voice control software will let the user say something like "click radio" to focus a the input or flag the role with a number.

Result

Notes

input[type="radio"] element, MUST convey the position in set information

Examples:

A screen reader might something like "1 of 6".

Result

Notes

Test case: Use Down arrow (Jump to next item (scan mode)) to navigate forward to the start of `input[type="radio"][checked]`

Launch Narrator and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"][checked]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Down arrow (Jump to next item (scan mode))
- After issuing the command, virtual focus should be: start of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the checked state

Examples:

A screen reader might announce "checked"

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward into `input[type="radio"][checked]`

Launch Narrator and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"][checked]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the checked state

Examples:

A screen reader might announce "checked"

Result

Notes

Test case: Use Down arrow (Jump to next item (scan mode)) to navigate forward to the start of `input[type="radio"]:not(checked)`

Launch Narrator and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]:not(checked)
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Down arrow (Jump to next item (scan mode))
- After issuing the command, virtual focus should be: start of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the unchecked state

Examples:

A screen reader might announce "unchecked" or imply that the element is not checked by not announcing the checked state at all.

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward into `input[type="radio"]:not(checked)`

Launch Narrator and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]:not(checked)
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the unchecked state

Examples:

A screen reader might announce "unchecked" or imply that the element is not checked by not announcing the checked state at all.

Result

Notes

Test case: Use Space (Activate Form Control) on the target of `input[type="radio"]`

Launch Narrator and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: target
- Keyboard focus is: target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Space (Activate Form Control)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey a change in the checked state

Examples:

A screen reader might announce "checked" or "not checked"
A screen reader might announce the entire control again with the new state

Result

Notes

Test case: Use f (Next form field) to navigate forward to `input[type="radio"]`

Launch Narrator and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: f (Next form field)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, SHOULD provide shortcuts to jump to this roleResult

Notes

Test cases for NVDA + Chrome

Test case: Use down arrow (Read next item) to navigate forward to `*[required]`

Launch NVDA and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: down arrow (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

input[type="radio"] element, MUST convey its name

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.

Result

Notes

input[type="radio"] element, MUST convey its role

Examples:

A screen reader might be announce the role as "radio"
Voice control software will let the user say something like "click radio" to focus a the input or flag the role with a number.

Result

Notes

input[type="radio"] element, MUST convey the position in set information

Examples:

A screen reader might something like "1 of 6".

Result

Notes

input[type="radio"] element, MUST convey the unchecked state

Examples:

A screen reader might announce "unchecked" or imply that the element is not checked by not announcing the checked state at all.

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward to `*[required]`

Launch NVDA and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

legend element, MUST convey its nameResult

Notes

input[type="radio"] element, MUST convey its name

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.

Result

Notes

input[type="radio"] element, MUST convey its role

Examples:

A screen reader might be announce the role as "radio"
Voice control software will let the user say something like "click radio" to focus a the input or flag the role with a number.

Result

Notes

input[type="radio"] element, MUST convey the position in set information

Examples:

A screen reader might something like "1 of 6".

Result

Notes

input[type="radio"] element, MUST convey the unchecked state

Examples:

A screen reader might announce "unchecked" or imply that the element is not checked by not announcing the checked state at all.

Result

Notes

Test case: Use up arrow (Read previous item) to navigate backwards to `*[required]`

Launch NVDA and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: up arrow (Read previous item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

legend element, MUST convey its nameResult

Notes

Test case: Use Shift + Tab (Read previous focusable item) to navigate backwards to `*[required]`

Launch NVDA and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Shift + Tab (Read previous focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

legend element, MUST convey its nameResult

Notes

Test case: Use down arrow (Read next item) to navigate forward to the start of `fieldset`

Launch NVDA and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: down arrow (Read next item)
- After issuing the command, virtual focus should be: start of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

legend element, MUST convey its nameResult

Notes

Test case: Use down arrow (Read next item) to navigate forward to `input[type="radio"][checked]`

Launch NVDA and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"][checked]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: down arrow (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the checked state

Examples:

A screen reader might announce "checked"

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward to `input[type="radio"][checked]`

Launch NVDA and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"][checked]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the checked state

Examples:

A screen reader might announce "checked"

Result

Notes

Test case: Use Space (Activate Form Control) on the target of `input[type="radio"]`

Launch NVDA and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: target
- Keyboard focus is: target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Space (Activate Form Control)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey a change in the checked state

Examples:

A screen reader might announce "checked" or "not checked"
A screen reader might announce the entire control again with the new state

Result

Notes

Test case: Use f (Next form field) to navigate forward to `input[type="radio"]`

Launch NVDA and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: f (Next form field)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, SHOULD provide shortcuts to jump to this roleResult

Notes

Test case: Use NVDA + F7 (Open Elements List)

Launch NVDA and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Mode is: auto (do not explicitly change the mode)
Issue the command: NVDA + F7 (Open Elements List)
- After issuing the command, virtual focus should be: na
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, SHOULD provide shortcuts to jump to this roleResult

Notes

Test cases for NVDA + Edge

Test case: Use down arrow (Read next item) to navigate forward to `*[required]`

Launch NVDA and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: down arrow (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

input[type="radio"] element, MUST convey its name

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.

Result

Notes

input[type="radio"] element, MUST convey its role

Examples:

A screen reader might be announce the role as "radio"
Voice control software will let the user say something like "click radio" to focus a the input or flag the role with a number.

Result

Notes

input[type="radio"] element, MUST convey the position in set information

Examples:

A screen reader might something like "1 of 6".

Result

Notes

input[type="radio"] element, MUST convey the unchecked state

Examples:

A screen reader might announce "unchecked" or imply that the element is not checked by not announcing the checked state at all.

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward to `*[required]`

Launch NVDA and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

legend element, MUST convey its nameResult

Notes

input[type="radio"] element, MUST convey its name

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.

Result

Notes

input[type="radio"] element, MUST convey its role

Examples:

A screen reader might be announce the role as "radio"
Voice control software will let the user say something like "click radio" to focus a the input or flag the role with a number.

Result

Notes

input[type="radio"] element, MUST convey the position in set information

Examples:

A screen reader might something like "1 of 6".

Result

Notes

input[type="radio"] element, MUST convey the unchecked state

Examples:

A screen reader might announce "unchecked" or imply that the element is not checked by not announcing the checked state at all.

Result

Notes

Test case: Use up arrow (Read previous item) to navigate backwards to `*[required]`

Launch NVDA and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: up arrow (Read previous item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

legend element, MUST convey its nameResult

Notes

Test case: Use Shift + Tab (Read previous focusable item) to navigate backwards to `*[required]`

Launch NVDA and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Shift + Tab (Read previous focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

legend element, MUST convey its nameResult

Notes

Test case: Use down arrow (Read next item) to navigate forward to the start of `fieldset`

Launch NVDA and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: down arrow (Read next item)
- After issuing the command, virtual focus should be: start of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

legend element, MUST convey its nameResult

Notes

Test case: Use down arrow (Read next item) to navigate forward to `input[type="radio"][checked]`

Launch NVDA and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"][checked]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: down arrow (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the checked state

Examples:

A screen reader might announce "checked"

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward to `input[type="radio"][checked]`

Launch NVDA and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"][checked]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the checked state

Examples:

A screen reader might announce "checked"

Result

Notes

Test case: Use Space (Activate Form Control) on the target of `input[type="radio"]`

Launch NVDA and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: target
- Keyboard focus is: target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Space (Activate Form Control)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey a change in the checked state

Examples:

A screen reader might announce "checked" or "not checked"
A screen reader might announce the entire control again with the new state

Result

Notes

Test case: Use f (Next form field) to navigate forward to `input[type="radio"]`

Launch NVDA and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: f (Next form field)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, SHOULD provide shortcuts to jump to this roleResult

Notes

Test case: Use NVDA + F7 (Open Elements List)

Launch NVDA and Edge.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Mode is: auto (do not explicitly change the mode)
Issue the command: NVDA + F7 (Open Elements List)
- After issuing the command, virtual focus should be: na
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, SHOULD provide shortcuts to jump to this roleResult

Notes

Test cases for NVDA + Firefox

Test case: Use down arrow (Read next item) to navigate forward to `*[required]`

Launch NVDA and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: down arrow (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

Test case: Use Tab (Read next focusable item) to navigate forward to `*[required]`

Launch NVDA and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

Test case: Use up arrow (Read previous item) to navigate backwards to `*[required]`

Launch NVDA and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: up arrow (Read previous item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

Test case: Use Shift + Tab (Read previous focusable item) to navigate backwards to `*[required]`

Launch NVDA and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Shift + Tab (Read previous focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

Test case: Use down arrow (Read next item) to navigate forward to the start of `fieldset`

Launch NVDA and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: down arrow (Read next item)
- After issuing the command, virtual focus should be: start of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward into `fieldset`

Launch NVDA and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

Test case: Use up arrow (Read previous item) to navigate backwards to the end of `fieldset`

Launch NVDA and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: up arrow (Read previous item)
- After issuing the command, virtual focus should be: end of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

Test case: Use Shift + Tab (Read previous focusable item) to navigate backwards into `fieldset`

Launch NVDA and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Shift + Tab (Read previous focusable item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

Test case: Use down arrow (Read next item) to navigate forward to the start of `legend, fieldset`

Launch NVDA and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:legend, fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: down arrow (Read next item)
- After issuing the command, virtual focus should be: start of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

legend element, MUST convey its nameResult

Notes

Test case: Use Tab (Read next focusable item) to navigate forward into `legend, fieldset`

Launch NVDA and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:legend, fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

legend element, MUST convey its nameResult

Notes

Test case: Use up arrow (Read previous item) to navigate backwards to the end of `legend, fieldset`

Launch NVDA and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:legend, fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: up arrow (Read previous item)
- After issuing the command, virtual focus should be: end of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

legend element, MUST convey its nameResult

Notes

Test case: Use Shift + Tab (Read previous focusable item) to navigate backwards into `legend, fieldset`

Launch NVDA and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:legend, fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Shift + Tab (Read previous focusable item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

legend element, MUST convey its nameResult

Notes

Test case: Use down arrow (Read next item) to navigate forward to `input[type="radio"]`

Launch NVDA and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: down arrow (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey its name

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.

Result

Notes

input[type="radio"] element, MUST convey its role

Examples:

A screen reader might be announce the role as "radio"
Voice control software will let the user say something like "click radio" to focus a the input or flag the role with a number.

Result

Notes

input[type="radio"] element, MUST convey the position in set information

Examples:

A screen reader might something like "1 of 6".

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward to `input[type="radio"]`

Launch NVDA and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey its name

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.

Result

Notes

input[type="radio"] element, MUST convey its role

Examples:

A screen reader might be announce the role as "radio"
Voice control software will let the user say something like "click radio" to focus a the input or flag the role with a number.

Result

Notes

input[type="radio"] element, MUST convey the position in set information

Examples:

A screen reader might something like "1 of 6".

Result

Notes

Test case: Use down arrow (Read next item) to navigate forward to `input[type="radio"][checked]`

Launch NVDA and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"][checked]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: down arrow (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the checked state

Examples:

A screen reader might announce "checked"

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward to `input[type="radio"][checked]`

Launch NVDA and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"][checked]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the checked state

Examples:

A screen reader might announce "checked"

Result

Notes

Test case: Use down arrow (Read next item) to navigate forward to `input[type="radio"]:not(checked)`

Launch NVDA and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]:not(checked)
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: down arrow (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the unchecked state

Examples:

A screen reader might announce "unchecked" or imply that the element is not checked by not announcing the checked state at all.

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward to `input[type="radio"]:not(checked)`

Launch NVDA and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]:not(checked)
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the unchecked state

Examples:

A screen reader might announce "unchecked" or imply that the element is not checked by not announcing the checked state at all.

Result

Notes

Test case: Use Space (Activate Form Control) on the target of `input[type="radio"]`

Launch NVDA and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: target
- Keyboard focus is: target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Space (Activate Form Control)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey a change in the checked state

Examples:

A screen reader might announce "checked" or "not checked"
A screen reader might announce the entire control again with the new state

Result

Notes

Test case: Use f (Next form field) to navigate forward to `input[type="radio"]`

Launch NVDA and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: f (Next form field)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, SHOULD provide shortcuts to jump to this roleResult

Notes

Test case: Use NVDA + F7 (Open Elements List)

Launch NVDA and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Mode is: auto (do not explicitly change the mode)
Issue the command: NVDA + F7 (Open Elements List)
- After issuing the command, virtual focus should be: na
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, SHOULD provide shortcuts to jump to this roleResult

Notes

Test cases for TalkBack + Chrome

Test case: Use Swipe right (or alt+right arrow) (Read next item) to navigate forward to `*[required]`

Launch TalkBack and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Swipe right (or alt+right arrow) (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

Test case: Use Swipe left (or alt+left arrow) (Read previous item) to navigate backwards to `*[required]`

Launch TalkBack and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Swipe left (or alt+left arrow) (Read previous item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

Test case: Use Swipe right (or alt+right arrow) (Read next item) to navigate forward into `fieldset`

Launch TalkBack and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Swipe right (or alt+right arrow) (Read next item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

Test case: Use Swipe left (or alt+left arrow) (Read previous item) to navigate backwards into `fieldset`

Launch TalkBack and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Swipe left (or alt+left arrow) (Read previous item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

Test case: Use Swipe right (or alt+right arrow) (Read next item) to navigate forward into `legend, fieldset`

Launch TalkBack and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:legend, fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Swipe right (or alt+right arrow) (Read next item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

legend element, MUST convey its nameResult

Notes

Test case: Use Swipe left (or alt+left arrow) (Read previous item) to navigate backwards into `legend, fieldset`

Launch TalkBack and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:legend, fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Swipe left (or alt+left arrow) (Read previous item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

legend element, MUST convey its nameResult

Notes

Test case: Use Swipe right (or alt+right arrow) (Read next item) to navigate forward to `input[type="radio"]`

Launch TalkBack and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Swipe right (or alt+right arrow) (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey its name

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.

Result

Notes

input[type="radio"] element, MUST convey its role

Examples:

A screen reader might be announce the role as "radio"
Voice control software will let the user say something like "click radio" to focus a the input or flag the role with a number.

Result

Notes

input[type="radio"] element, MUST convey the position in set information

Examples:

A screen reader might something like "1 of 6".

Result

Notes

Test case: Use Swipe right (or alt+right arrow) (Read next item) to navigate forward to `input[type="radio"][checked]`

Launch TalkBack and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"][checked]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Swipe right (or alt+right arrow) (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the checked state

Examples:

A screen reader might announce "checked"

Result

Notes

Test case: Use Swipe right (or alt+right arrow) (Read next item) to navigate forward to `input[type="radio"]:not(checked)`

Launch TalkBack and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]:not(checked)
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Swipe right (or alt+right arrow) (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the unchecked state

Examples:

A screen reader might announce "unchecked" or imply that the element is not checked by not announcing the checked state at all.

Result

Notes

Test case: Use double tap (Activate form control) on the target of `input[type="radio"]`

Launch TalkBack and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: target
- Keyboard focus is: target
- Mode is: auto (do not explicitly change the mode)
Issue the command: double tap (Activate form control)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey a change in the checked state

Examples:

A screen reader might announce "checked" or "not checked"
A screen reader might announce the entire control again with the new state

Result

Notes

Test case: Use Swipe down (alt+c) (next control (correct reading control must be selected)) to navigate forward to `input[type="radio"]`

Launch TalkBack and Chrome.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Swipe down (alt+c) (next control (correct reading control must be selected))
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, SHOULD provide shortcuts to jump to this roleResult

Notes

Test cases for VoiceOver (iOS) + Safari

Test case: Use Swipe Right (Next item) to navigate forward to `*[required]`

Launch VoiceOver (iOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Swipe Right (Next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

Test case: Use Swipe Left (Previous item) to navigate backwards to `*[required]`

Launch VoiceOver (iOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Swipe Left (Previous item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

Test case: Use Swipe Right (Next item) to navigate forward into `fieldset`

Launch VoiceOver (iOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Swipe Right (Next item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

Test case: Use Swipe Left (Previous item) to navigate backwards into `fieldset`

Launch VoiceOver (iOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Swipe Left (Previous item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

Test case: Use Swipe Right (Next item) to navigate forwards out of `fieldset`

Launch VoiceOver (iOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: within target
- Keyboard focus is: within target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Swipe Right (Next item)
- After issuing the command, virtual focus should be: after target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

Test case: Use Swipe Right (Next item) to navigate forward into `legend, fieldset`

Launch VoiceOver (iOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:legend, fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Swipe Right (Next item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

legend element, MUST convey its nameResult

Notes

Test case: Use Swipe Right (Next item) to navigate forward to `input[type="radio"]`

Launch VoiceOver (iOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Swipe Right (Next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey its name

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.

Result

Notes

input[type="radio"] element, MUST convey its role

Examples:

A screen reader might be announce the role as "radio"
Voice control software will let the user say something like "click radio" to focus a the input or flag the role with a number.

Result

Notes

input[type="radio"] element, MUST convey the position in set information

Examples:

A screen reader might something like "1 of 6".

Result

Notes

Test case: Use Swipe Right (Next item) to navigate forward to `input[type="radio"][checked]`

Launch VoiceOver (iOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"][checked]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Swipe Right (Next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the checked state

Examples:

A screen reader might announce "checked"

Result

Notes

Test case: Use Swipe Right (Next item) to navigate forward to `input[type="radio"]:not(checked)`

Launch VoiceOver (iOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]:not(checked)
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Swipe Right (Next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the unchecked state

Examples:

A screen reader might announce "unchecked" or imply that the element is not checked by not announcing the checked state at all.

Result

Notes

Test case: Use Double tap (Activate Form Control) on the target of `input[type="radio"]`

Launch VoiceOver (iOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: target
- Keyboard focus is: target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Double tap (Activate Form Control)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey a change in the checked state

Examples:

A screen reader might announce "checked" or "not checked"
A screen reader might announce the entire control again with the new state

Result

Notes

Test case: Use Swipe down (next form control (correct item type must be selected)) to navigate forward to `input[type="radio"]`

Launch VoiceOver (iOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Swipe down (next form control (correct item type must be selected))
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, SHOULD provide shortcuts to jump to this roleResult

Notes

Test cases for VoiceOver (macOS) + Safari

Test case: Use VO + Right arrow (Read next item) to navigate forward to `*[required]`

Launch VoiceOver (macOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: VO + Right arrow (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

Test case: Use Tab (Read next focusable item) to navigate forward to `*[required]`

Launch VoiceOver (macOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

Test case: Use VO + Left Arrow (Read previous item) to navigate backwards to `*[required]`

Launch VoiceOver (macOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: VO + Left Arrow (Read previous item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

Test case: Use Shift + Tab (Read previous focusable item) to navigate backwards to `*[required]`

Launch VoiceOver (macOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Shift + Tab (Read previous focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

Test case: Use VO + Right arrow (Read next item) to navigate forward to the start of `fieldset`

Launch VoiceOver (macOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: VO + Right arrow (Read next item)
- After issuing the command, virtual focus should be: start of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward into `fieldset`

Launch VoiceOver (macOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

Test case: Use VO + Left Arrow (Read previous item) to navigate backwards to the end of `fieldset`

Launch VoiceOver (macOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: VO + Left Arrow (Read previous item)
- After issuing the command, virtual focus should be: end of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

Test case: Use Shift + Tab (Read previous focusable item) to navigate backwards into `fieldset`

Launch VoiceOver (macOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Shift + Tab (Read previous focusable item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

Test case: Use VO + Right arrow (Read next item) to navigate forward to `legend, fieldset`

Launch VoiceOver (macOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:legend, fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: VO + Right arrow (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

legend element, MUST convey its nameResult

Notes

legend element, MUST convey its nameResult

Notes

Test case: Use Tab (Read next focusable item) to navigate forward to `legend, fieldset`

Launch VoiceOver (macOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:legend, fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

legend element, MUST convey its nameResult

Notes

Test case: Use VO + Right arrow (Read next item) to navigate forward to `input[type="radio"]`

Launch VoiceOver (macOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: VO + Right arrow (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey its name

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.

Result

Notes

input[type="radio"] element, MUST convey its role

Examples:

A screen reader might be announce the role as "radio"
Voice control software will let the user say something like "click radio" to focus a the input or flag the role with a number.

Result

Notes

input[type="radio"] element, MUST convey the position in set information

Examples:

A screen reader might something like "1 of 6".

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward to `input[type="radio"]`

Launch VoiceOver (macOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey its name

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.

Result

Notes

input[type="radio"] element, MUST convey its role

Examples:

A screen reader might be announce the role as "radio"
Voice control software will let the user say something like "click radio" to focus a the input or flag the role with a number.

Result

Notes

input[type="radio"] element, MUST convey the position in set information

Examples:

A screen reader might something like "1 of 6".

Result

Notes

Test case: Use VO + Right arrow (Read next item) to navigate forward to `input[type="radio"][checked]`

Launch VoiceOver (macOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"][checked]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: VO + Right arrow (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the checked state

Examples:

A screen reader might announce "checked"

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward to `input[type="radio"][checked]`

Launch VoiceOver (macOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"][checked]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the checked state

Examples:

A screen reader might announce "checked"

Result

Notes

Test case: Use VO + Right arrow (Read next item) to navigate forward to `input[type="radio"]:not(checked)`

Launch VoiceOver (macOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]:not(checked)
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: VO + Right arrow (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the unchecked state

Examples:

A screen reader might announce "unchecked" or imply that the element is not checked by not announcing the checked state at all.

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward to `input[type="radio"]:not(checked)`

Launch VoiceOver (macOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]:not(checked)
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the unchecked state

Examples:

A screen reader might announce "unchecked" or imply that the element is not checked by not announcing the checked state at all.

Result

Notes

Test case: Use Space (Activate Form Control) on the target of `input[type="radio"]`

Launch VoiceOver (macOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: target
- Keyboard focus is: target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Space (Activate Form Control)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey a change in the checked state

Examples:

A screen reader might announce "checked" or "not checked"
A screen reader might announce the entire control again with the new state

Result

Notes

Test case: Use VO + Command + J (Next Form Control) to navigate forward to `input[type="radio"]`

Launch VoiceOver (macOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: VO + Command + J (Next Form Control)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, SHOULD provide shortcuts to jump to this roleResult

Notes

Test case: Use VO + U (Open Rotor)

Launch VoiceOver (macOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Mode is: auto (do not explicitly change the mode)
Issue the command: VO + U (Open Rotor)
- After issuing the command, virtual focus should be: na
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, SHOULD provide shortcuts to jump to this roleResult

Notes

Test cases for Orca + Firefox

Test case: Use down arrow (Read next item) to navigate forward to `*[required]`

Launch Orca and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: down arrow (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

Test case: Use Tab (Read next focusable item) to navigate forward to `*[required]`

Launch Orca and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

Test case: Use up arrow (Read previous item) to navigate backwards to `*[required]`

Launch Orca and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: up arrow (Read previous item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

Test case: Use Shift + Tab (Read previous focusable item) to navigate backwards to `*[required]`

Launch Orca and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:*[required]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Shift + Tab (Read previous focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

required attribute, MUST convey the property, applied to input[type="radio"] element

Examples:

A screen reader might announce the property along with the elements name, role, and value

Result

Notes

required attribute, MAY convey the invalid state when empty, applied to input[type="radio"] elementResult

Notes

Test case: Use down arrow (Read next item) to navigate forward to the start of `fieldset`

Launch Orca and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: down arrow (Read next item)
- After issuing the command, virtual focus should be: start of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward into `fieldset`

Launch Orca and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

Test case: Use up arrow (Read previous item) to navigate backwards to the end of `fieldset`

Launch Orca and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: up arrow (Read previous item)
- After issuing the command, virtual focus should be: end of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

Test case: Use Shift + Tab (Read previous focusable item) to navigate backwards into `fieldset`

Launch Orca and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Shift + Tab (Read previous focusable item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

fieldset element, MUST convey its role

Examples:

A screen reader might announce an element as something like "<name>, <role>"
A screen reader might imply the role by the presence of certain context roles
Voice Control software might let the user say something like "click, <role>".
Voice Control software might let the user say something like "show numbers", and interactive roles will be flagged with numbers.

Result

Notes

fieldset element, MUST convey its name

Examples:

A screen reader might convey the fieldset as "<role> <name-from-legend>"

Result

Notes

fieldset element, MUST convey the boundaries of the element

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

Result

Notes

Test case: Use down arrow (Read next item) to navigate forward to the start of `legend, fieldset`

Launch Orca and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:legend, fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: down arrow (Read next item)
- After issuing the command, virtual focus should be: start of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

legend element, MUST convey its nameResult

Notes

Test case: Use Tab (Read next focusable item) to navigate forward into `legend, fieldset`

Launch Orca and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:legend, fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

legend element, MUST convey its nameResult

Notes

Test case: Use up arrow (Read previous item) to navigate backwards to the end of `legend, fieldset`

Launch Orca and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:legend, fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: up arrow (Read previous item)
- After issuing the command, virtual focus should be: end of target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

legend element, MUST convey its nameResult

Notes

Test case: Use Shift + Tab (Read previous focusable item) to navigate backwards into `legend, fieldset`

Launch Orca and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:legend, fieldset
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: after target
- Keyboard focus is: after target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Shift + Tab (Read previous focusable item)
- After issuing the command, virtual focus should be: within target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

legend element, MUST convey its nameResult

Notes

Test case: Use down arrow (Read next item) to navigate forward to `input[type="radio"]`

Launch Orca and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: down arrow (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey its name

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.

Result

Notes

input[type="radio"] element, MUST convey its role

Examples:

A screen reader might be announce the role as "radio"
Voice control software will let the user say something like "click radio" to focus a the input or flag the role with a number.

Result

Notes

input[type="radio"] element, MUST convey the position in set information

Examples:

A screen reader might something like "1 of 6".

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward to `input[type="radio"]`

Launch Orca and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey its name

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.

Result

Notes

input[type="radio"] element, MUST convey its role

Examples:

A screen reader might be announce the role as "radio"
Voice control software will let the user say something like "click radio" to focus a the input or flag the role with a number.

Result

Notes

input[type="radio"] element, MUST convey the position in set information

Examples:

A screen reader might something like "1 of 6".

Result

Notes

Test case: Use down arrow (Read next item) to navigate forward to `input[type="radio"][checked]`

Launch Orca and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"][checked]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: down arrow (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the checked state

Examples:

A screen reader might announce "checked"

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward to `input[type="radio"][checked]`

Launch Orca and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"][checked]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the checked state

Examples:

A screen reader might announce "checked"

Result

Notes

Test case: Use down arrow (Read next item) to navigate forward to `input[type="radio"]:not(checked)`

Launch Orca and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]:not(checked)
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: down arrow (Read next item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the unchecked state

Examples:

A screen reader might announce "unchecked" or imply that the element is not checked by not announcing the checked state at all.

Result

Notes

Test case: Use Tab (Read next focusable item) to navigate forward to `input[type="radio"]:not(checked)`

Launch Orca and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]:not(checked)
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Tab (Read next focusable item)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey the unchecked state

Examples:

A screen reader might announce "unchecked" or imply that the element is not checked by not announcing the checked state at all.

Result

Notes

Test case: Use Space (Activate Form Control) on the target of `input[type="radio"]`

Launch Orca and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: target
- Keyboard focus is: target
- Mode is: auto (do not explicitly change the mode)
Issue the command: Space (Activate Form Control)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey a change in the checked state

Examples:

A screen reader might announce "checked" or "not checked"
A screen reader might announce the entire control again with the new state

Result

Notes

Test case: Use r (Next radio button) to navigate forward to `input[type="radio"]`

Launch Orca and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: r (Next radio button)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, SHOULD provide shortcuts to jump to this roleResult

Notes

Test case: Use alt + shift + r (list radio buttons) to navigate forward to `input[type="radio"]`

Launch Orca and Firefox.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Position and configure the screen reader so that the following conditions are met
- Virtual focus is: before target
- Keyboard focus is: before target
- Mode is: auto (do not explicitly change the mode)
Issue the command: alt + shift + r (list radio buttons)
- After issuing the command, virtual focus should be: target
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, SHOULD provide shortcuts to jump to this roleResult

Notes

Test cases for Voice Control (MacOS) + Safari

Test case: Use "Click <text>" (Activate item by name)

Launch Voice Control (MacOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Issue the command: "Click <text>" (Activate item by name)
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey its name

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.

Result

Notes

Test case: Use "Show numbers" (Turn on the numbers overlay)

Launch Voice Control (MacOS) and Safari.
Navigate to the test page.
Find the target element(s) that you will test against. Identify all elements that match this selector:input[type="radio"]
- If multiple elements match the selector, repeat this test for all instances. However, choose a single instance to report against. If you feel that the selector should be more specific, please open a GitHub Issue.
Issue the command: "Show numbers" (Turn on the numbers overlay)
Record results for the relevant expectations

OutputNotesIf support is hidden behind non-default settings, briefly describe that setting

input[type="radio"] element, MUST convey its role

Examples:

A screen reader might be announce the role as "radio"
Voice control software will let the user say something like "click radio" to focus a the input or flag the role with a number.

Result

Notes

Run Test: The html required attribute on each HTML radio button in a fieldset

Step 1: What are you testing with?

Make sure everything is up to date

Step 2: Run test cases and submit your findings

Test cases for Dragon Naturally Speaking + Chrome

Test cases for Dragon Naturally Speaking + IE

Test cases for Dragon Naturally Speaking + Firefox

Test cases for JAWS + Chrome

Test cases for JAWS + Edge

Test cases for JAWS + Firefox

Test cases for JAWS + IE

Test cases for Narrator + Edge

Test cases for Narrator + Firefox

Test cases for Narrator + Chrome

Test cases for Narrator + IE

Test cases for NVDA + Chrome

Test cases for NVDA + Edge

Test cases for NVDA + Firefox

Test cases for NVDA + IE

Test cases for TalkBack + Chrome

Test cases for TalkBack + Firefox

Test cases for Voice Access (Android) + Chrome

Test cases for Voice Access (Android) + Firefox

Test cases for VoiceOver (iOS) + Safari

Test cases for VoiceOver (iOS) + Chrome

Test cases for VoiceOver (macOS) + Safari

Test cases for VoiceOver (macOS) + Chrome

Test cases for VoiceOver (macOS) + Firefox

Test cases for Orca + Firefox

Test cases for Orca + Chrome

Test cases for Voice Control (iOS) + Safari

Test cases for Voice Control (MacOS) + Safari

Test cases for Voice Control (MacOS) + Chrome

Test cases for Voice Control (MacOS) + Firefox

Test cases for Windows Speech Recognition + Edge

Test cases for Windows Speech Recognition + Chrome

Test cases for Windows Voice Access + Edge

Test cases for Windows Voice Access + Chrome

Test cases for Windows Keyboard + Chrome

Test cases for Windows Keyboard + Firefox

Test cases for Windows Keyboard + Edge

Test cases for Mac Keyboard + Chrome

Test cases for Mac Keyboard + Safari

Test cases for Mac Keyboard + Firefox

Test cases for iOS Keyboard + Safari

Test cases for Android Keyboard + Chrome

Test cases for Android Keyboard + Firefox

Copy/paste this into a github issue

Related Features

Is something not right?