-
Notifications
You must be signed in to change notification settings - Fork 776
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
"Radio Inputs With Same Name Attribute ... " error when label has "display:none" #188
Comments
The display: none takes the label out of the screenreader's purview, and that's why the error returns. I'm on an iPod so link is pasted below. Check out an accessible hide content CSS rule set. This hides the label from sighted users with normal style sheets, but keeps the label and its attributes visible to screen readers. Should silence the error. https://www.paciellogroup.com/blog/2012/05/html5-accessibility-chops-hidden-and-aria-hidden/ Sent from my iPod
|
Thanks for the response! I'm thinking I might not fully understand the problem. Is it breaking an accessibility rule to have a hidden label, that is hidden from all users (screen reader or not), but that is used by aria-labelledby? The problem that I'm having is that I don't have good explanatory text on screen (that isn't too verbose) to use in an aria-labelledby for all the related inputs. So, I created a label with one word ("Answer") and hid it, adding it to the aria-labelledby to allow for screen readers to pick it up before each answer. Listening to it with a screen reader, it sounds perfect, and is exactly what I want. So, I'm wondering if this still breaks some rule that I am unaware of (aria-labelledby must use labels that are not hidden elsewhere from the screen reader)? |
@ianmclean2011 I believe the issue is the display: none declaration on your overarching label, that's the reference for your aria-labelledby attribute. By setting that label with the Answer ID to display: none, you're removing it from the screen reader's document outline, and thus the inputs' aria-labelledby attributes have nothing to reference. I worked up a new fiddle, based on your original, that hides the Answer label in a screenreader accessible way. A quick run of aXe Chrome plugin did not show the error with the updated styles. Hope this helps explain the issue and fix the error. |
Thanks for the JSFiddle and the explanation! Is there any way to hide a label from all users (screen reader or not), and still have it used by aria-labelledby? When I used style="display:none", the screen reader was still able to pick up the label in the aria-labelledby for each input, without saying "Answer" at a point that was inappropriate. With the fix above, a screen reader now says "Answer" at an inappropriate point. If that is bad form/breaking an accessibility rule, I'd really like to know. |
You're welcome. One thing that occurred to me, you might be overloading the label, semantically. Have you considered grouping the label + radio buttons in a fieldset with a legend? If I remember correctly, the legend will be read once, and should be able to take the aria-labelledby designation. Could be as simple as:
This should give you the single reading of "Answer" you want, and increase semantics for the radio group. |
This definitely made things a bit cleaner, and I'll try it out ... thanks! I still think this might be an Axe bug. If you look here: https://www.paciellogroup.com/blog/2015/05/short-note-on-aria-labelledby-and-aria-describedby/ It says that "The ARIA attributes aria-labelledby and aria-describedby can be used to provide an accessible name or accessible description for a subset of HTML elements. It is important to note that by design, hiding the content (using CSS display:none or visibility:hidden or the HTML hidden attribute) of the element(s) referenced by these attributes does not stop the content from being used to provide the name/description." I understand that hiding a label from all users by using "display:none" removes it from the accessibility tree and from the screen reader. I just interpreted the error to be related to grouping using aria-labelledby, and that if the aria-labelledby can pick up and display hidden text for the screen reader, then it accomplishes what the error was trying to fix. I'm sorry if I'm missing something here. If there is an additional WCAG rule that aria-labelledby must reference labels that are screen reader visible, or something else, then that's fine. I just really want to understand it. Thanks for all the help so far, and thanks for a really great product! |
@ianmclean2011 that bug is known and will be fixed in the 2.0 release coming in the next couple of months |
Awesome ... thank you very much! |
I think this issue has been fixed, I don't get a violation for the radio buttons in the above JSFiddle. I'm going to close this issue, but can you let us know if the problem persists? |
This bug still seems to occur in current version of axe |
You're quite right. Not sure why this got closed prematurely. I'll sort it out. It looks like an easy fix. |
Hello,
I was working on improving the accessibility of a web application, and Axe threw a "Radio inputs with the same name attribute value must be part of a group" error in relation to radio button answers for a question. I didn't have a reasonable label to use, so I added a label, and gave it a try (this fixed the problem). The label I added didn't really have a proper place on the page, but made sense in preceding each of the answers, so I set the display, of the labe,l to none. This sounded good with NVDA, but the Axe error returned. Is this a bug in Axe, or am I doing something wrong?
Here is a jsfiddle sample:
https://jsfiddle.net/re7gugjn/
Removing the "display:none" from 'Answer' fixes the error, but leaving it in does not, even though it seems to fix the underlying problem that causes the error.
The text was updated successfully, but these errors were encountered: