You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Axe threw an error for the following code and it seems OK. Could it be that the tool is looking for the listbox to an actual child of the node that has a role of combobox? If so I'd say it should not require it to be a child of the node, as per the example in wai-aria 1.1 which is not a child. https://www.w3.org/TR/wai-aria-1.1/#combobox
The ARIA 1.1 spec does say combobox is allowed on a text input in 1.0 here:
The ARIA 1.0 specification describes a combobox pattern where a text input element has the combobox role and owns a listbox element. User agents, assistive technologies, and conformance checkers should continue to support the ARIA 1.0 pattern so that existing implementations of the ARIA 1.0 pattern remain functional.
For the snippet above, axe-core is partially complaining that the combobox doesn't own a listbox. This can be fixed with aria-owns on the input/combobox pointing to the listbox ID. That changes the result to show what I believe is a bug:
Required ARIA child role not present: textbox
The input is a self-closing element, so it can't contain any children. I think there are multiple versions of this pattern which makes it a confusing one to automate. Any input @wilco or @dylanb?
Axe threw an error for the following code and it seems OK. Could it be that the tool is looking for the listbox to an actual child of the node that has a role of combobox? If so I'd say it should not require it to be a child of the node, as per the example in wai-aria 1.1 which is not a child.
https://www.w3.org/TR/wai-aria-1.1/#combobox
The text was updated successfully, but these errors were encountered: