w3c / accname

Accessible Name and Description Computation
https://w3c.github.io/accname/
61 stars 23 forks source link

Step 2E isn't used for form field + name-from-label when it is the current node in an aria-labelledby traversal #179

Open smhigley opened 1 year ago

smhigley commented 1 year ago

Using the accName for the button in the following markup as a reduced example:

<label for="inputId">Something</label>
<input id="inputId">
<button aria-labelledby="inputId">***</button>

My reading of the accname spec is that the following should happen for the button:

  1. It should hit 2.B.ii and follow the idRef inputId
  2. Start from step 2 with the input as the current node
  3. The input should use step 2E to calculate its text alternative, and return the text of the <label>
  4. The button's accName should be "Something"

This is not the case for Firefox, Chrome, Edge, or Safari in my testing. All of them return the value of the input as its text alternative when within an aria-labelledby traversal instead of the name derived from the <label>. My guess is that browsers are following step 2C here, even though the input is directly referenced, and not within a parent label.

I'd like to confirm whether the correct behavior is for the button to have the accName "Something" here, or whether the current browser behavior is correct.

JAWS-test commented 1 year ago

I think you are right: according to Accname, in your example the button label should be "Something". However, what the browsers do feels more correct - i.e. maybe the accname should be adjusted here rather than changing the behavior of the browsers.

Problem in the AccName is also that the example 3 is wrong:

spectranaut commented 1 year ago

This was discussed in last week meetings: https://www.w3.org/2023/01/12-aria-minutes#t05