10.1 Form Name - Identify Content

[kengdoj]

Consider visibility: hidden and display:none in Identify Content to omit from testing.

[kengdoj]

• Should these also be omitted from all forms testing? role="presentation" and role="none"

• Should these be listed in "Exceptions" section?

[kengdoj]

We have differences in interpretation of specs, ANDI, and browser acctree: when more than one role is assigned, and "presentation" is not first.

• Ex: role="link presentation" - ANDI does not detect this as a link; Edge Accessibility tree lists this as a link

Reference Specs:

Core Accessibility API Mappings 1.1:

5.4.1 General rules §
The following rules describe how to expose WAI-ARIA roles using the accessibility API:

1. The user agent MUST use the first token in the sequence of tokens in the role attribute value which matches the name of any non-abstract WAI-ARIA role according to rules that are specified in the Role Mapping Table below.

4. When an explicit or inherited role of none or presentation is applied to an element, the user agent MUST implement the rules for the none or the presentation role defined in Accessible Rich Internet Applications (WAI-ARIA) 1.0 [wai-aria-1.1]

Aria spec 1.1 states

For any element with a role of presentation and which is not focusable, the user agent MUST NOT expose the implicit native semantics of the element (the role and its states and properties) to accessibility APIs. However, the user agent MUST expose content and descendant elements that do not have an explicit or inherited role of presentation. Thus, the presentation role causes a given element to be treated as having no role or to be removed from the accessibility tree, but does not cause the content contained within the element to be removed from the accessibility tree.

[kengdoj]

Discussed with @johncotterssa: will plan to update ANDI to match acctree: role="link presentation" will be detected as a link. Will add caution warning that multiple roles are assigned.

[kengdoj]

For reference:
ACT Rules, like Form field has non-empty accessible name, use the phrase "element that is included in the accessibility tree" and the inapplicable examples include role="none", aria-hidden="true", display: none.

[drewnielson]

Still a problem if something looks and acts like a form element but could have role="none" or role="presentation", in which case a mouse user might still be able to perform intended function, but a screen reader user would not get the appropriate form element semantics. So would recommend explicitly excluding visibility:hidden and display:none in the Identify Content, BUT would not recommend excluding role="none" nor role="presentation"

[kengdoj]

Agree with @drewnielson in above recommendation. From Aria 1.1:

If an element with a role of presentation is focusable, or otherwise interactive, user agents MUST ignore the normal effect of the role and expose the element with implicit native semantics, in order to ensure that the element is both understandable and operable.

Current instruction: 1. Find all form components. Examples include buttons, text fields, radio buttons, checkboxes, read-only fields, and multi-select lists.

Edit option A: 1. Find all visible form components...
Edit option B: 1. Find all form components that do not have visibility:hidden or display:none...
Other edit suggestions?

[kengdoj]

Option B wins.