-
Notifications
You must be signed in to change notification settings - Fork 27
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
Button accessibility name doesn't indicate label element can be used #357
Comments
Also applies for |
The inputs in section 4.1 (type="text", "password", "search", "tel", "url" and textarea element) do mention label, as follows:
But the inputs in section 4.2 (type="button", "submit", "reset") don't mention label. So we can reuse the above wording for those. The HTML labelable elements are: button, input (if the type attribute is not in the Hidden state), meter, output, progress, select, textarea, and form-associated custom elements So from that list, we need to add the point about label to:
Note that section 4.7 Other form elements also mentions label:
Should we just assume that meter, progress, select, and FACE are lumped under "Other form elements", or should we call them out specifically? Also, should we specifically mention that input type="hidden" is not labelable? |
closes #471 in resolving #357, I failed to update the text that says "if steps 1 to 2..." - as the inclusion of label added a 3rd step. Looking at this further though, it seemed this could be clarified a bit more as the previous steps made it seem like if `value=""` was used, that the localized text strings of submit or reset should be used. but that's not how this shakes out in reality, where if a value attribute is used, even if it's value is the empty string, it will become the control's accessible name. so the revised text is an attempt to make that clear, and purposefully removes saying to use the localized text string of submit or reset, since those can vary per browser. Rather, I refer to these now as HTML does by saying the "implementation defined string". The title attribute step was update to reference the fact that someone _could_ do <input type=submit value>` which would mean the button had no accName, so if that's the case, then `title` should be used.
The label element seems to be usable to label buttons but this doesn't seem to be list in the accessible name calculation.
The text was updated successfully, but these errors were encountered: