Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[accname] “skip self” requirement is missing from the “Embedded Control” substep for accessible-name computation #246

Open
sideshowbarker opened this issue Nov 27, 2024 · 2 comments
Assignees

Comments

@sideshowbarker
Copy link
Member

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

@scottaohara
Copy link
Member

noting this should probably be referenced in the html aam naming steps for inputs, as well

@jnurthen jnurthen transferred this issue from w3c/aria Dec 5, 2024
scottaohara added a commit to w3c/aria that referenced this issue Dec 9, 2024
- 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.
@accdc
Copy link
Contributor

accdc commented Dec 20, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants