Technique ARIA14: Replacing “invisible label” with “accessible name” #4482
Conversation
Sorry that this will make the actual PR more difficult to read, but it’s necessary to be able to efficiently make changes for me.
Trying to be clear that aria-label sets the accessible name, also clarified some text. This technique could probably do with more examples of screen reader and voice input interactions, I’m not sure if readers understand what the impact really is and why it is important.
|
yatil marked as non substantive for IPR from ash-nazg. |
✅ Deploy Preview for wcag2 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for wcag2 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
There was a problem hiding this comment.
once the working example is modified as well, this looks good to me
Preview: https://deploy-preview-4482--wcag2.netlify.app/techniques/aria/aria14
Working example is now using an html dialog and also some more styling, just to be fancy. I also synced the example back to the technique.
#Conflicts: # techniques/aria/ARIA14.html
Co-authored-by: Hidde de Vries <[email protected]>
|
Discussed on backlog call 7/17. We didn't consense on final phrasing the technique. |
|
@dbjorge i seem to remember that last week you had a concern that even with my changes (which i've now merged in) there was something that would fall between the cracks...mind giving another look over just to see if that's still the case? |
@patrickhlauke Current version looks like an improvement to me, am fine with it merging as-updated! |
|
thanks for taking another look @dbjorge |
|
Thanks for taking a look @patrickhlauke. (Sorry when I don't reply here in time, even when tagged. I had to disable notifications because of bad previous interactions. I realize it's not optimal.) |
kfranqueiro
dismissed
dbjorge’s stale review
Requested changes have since been resolved, as reflected in later comments
|
this is the first time I've ever commented. As a literal thinker, it's very clear to me to what an invisible label is, that's very specific. However, when it's "accessible name", that's not very clear to me to what that actually means. I get it that some people may not like usage of "visible" or "invisible" as terms. But what does "accessible name" mean? coming from an ActuallyAutistic person here. |
|
I'm afraid that the concept of "accessible name" is actually quite foundational to most of ARIA, and as a consequence parts of WCAG (to the point that it's part of some success criteria like Label in Name - where "Name" is the accessible name), so not sure we can avoid using it... |
|
From a little discussion in the TF facilitators, we agree that accessible name is a foundational concept that we need to use, and that we could do with some introduction / support for people who aren't familiar with it. In some places we've linked to name, which is equivalent to accname. For the purpose of this PR, I suggested we carry on with accepting this PR (assuming the group agrees). Let's open a separate issue on explaining accessible name, which occurs in at over 60 places in the informative docs. Mike suggested adding a note under "name", which says this is effectively accname. We could then link to that from here, and potentially other places that use it. |
Co-authored-by: Mike Gower <[email protected]>
Thank you for your input. I have added a link pointing directly to a definition of "accessible name". Note that that definition itself uses "invisible property", which hopefully helps. Retaining "invisible label" risks other possible confusion, since WCAG explicitly says "a label is presented to all users". I suspect that was one of the motivations for @yatil to make the pull request. As Alastair notes, we will also revisit uses of "accessible name" in other guidance. I have initiated a draft pull request to start this work. #4633 |
|
Thank you for the excellent work on clarifying this technique and thoughtfully incorporating reviewer feedback. I had just one additional suggestion that I don’t believe has been mentioned yet: Localization reminder: It may be helpful to note that any I also noticed that the branch currently has some conflicts |
Thanks for flagging; those were caused by me, so I've resolved them. |
Trying to be clear that aria-label sets the accessible name, also clarified some text. This technique could probably do with more examples of screen reader and voice input interactions, I’m not sure if readers understand what the impact really is and why it is important.
I also modernised the language from “lightbox” to dialog, but I left the example mostly as is for now. It would be good to update it to a proper
<dialog>example.My apologies for automatically re-indenting the file, but it is so difficult to work with these files otherwise.
Diff view of changes
Preview of Technique ARIA14 from this PR, Using aria-label to provide an accessible name where a visible label cannot be used