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
https://wpt.fyi/results/accname/name/comp_host_language_label.html has “encapsulation” tests, from which can be induced a requirement that when computing the accessible name for a <label>-ed form control (“embedded control”), then any content (text content or attribute values) from the control itself that would otherwise be included in the accessible-name computation for it ancestor <label> must instead be skipped and not included.
But that requirement is not explicitly stated anywhere in the accname spec.
Link to the version of the specification or documentation you were looking at at.
- Updates the listed inputs and button types to steps more consistent in wording.
- incorporates w3c/accname#246 into the label steps for the mentioned form controls
- starting to migrate from just using "subtree" to "text equivalent computation of the element's subtree" - as the simple use of 'subtree' has come up in a handful of reviews for html aam naming steps
the "other form controls" is not touched in this update - as there are also other pending PRs - re select element - that start breaking that apart.
Hi, can you please provide a code example here to demonstrate the issue?
As far as duplicate node references go, this was meant to be addressed within the following spec text.
"LabelledBy: Otherwise, if the current node has an aria-labelledby attribute that contains at least one valid IDREF, and the current node is not already part of an ongoing aria-labelledby or aria-describedby traversal, process its IDREFs in the order they occur:"
Specifically:
"and the current node is not already part of an ongoing aria-labelledby or aria-describedby traversal"
In theory this means that the same node shouldn't be processed more than once, but browsers always have done so anyway.
https://wpt.fyi/results/accname/name/comp_host_language_label.html has “encapsulation” tests, from which can be induced a requirement that when computing the accessible name for a
<label>
-ed form control (“embedded control”), then any content (text content or attribute values) from the control itself that would otherwise be included in the accessible-name computation for it ancestor<label>
must instead be skipped and not included.But that requirement is not explicitly stated anywhere in the accname spec.
Link to the version of the specification or documentation you were looking at at.
https://w3c.github.io/accname/#comp_embedded_control
Does the issue exists in the editors draft (the editors draft is the most recent draft of the specification)? Yes
The text was updated successfully, but these errors were encountered: