-
-
Notifications
You must be signed in to change notification settings - Fork 625
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
'title' attribute value should not be read when 'aria-label' is available in [Chrome] and [Firefox] #7841
Comments
Maybe only read the 'title' in addition to the 'aria-label' if the values of the two are different? |
Thank you for providing a test case. The Whether From my own testing, with Chrome version:
The NVDA dev info for this object shows that these values come from the name and description:
See the computation of name and description fields as prescribed by WAI-ARIA 1.1 spec. Also relevant is the accessible name for roles description |
@feerrenrut Yes, "hover" with the mouse. The reason I think title should not be reported when The specific case I'm referring to is when Thanks! |
Yes, repeating information is not very helpful. However, I think this is a web authoring error. Are you suggesting that when the values for While we might be able to detect and improve this situation, doing so would actually make it harder for accessibility testing of web sites. It makes the problem less apparent. So there is the question of whether we should. |
The W3C spec prohibits the usage of the
|
@feerrenrut hi, vscode developer here. Thanks a lot |
This is a bit confusing. To be clear, what is happening is the following: the description property is being read, and the name. The description can be turned off by users, but we want to ensure that the description is reported as well. We aren't using title to calculate name here, but the description is equivalent to a tooltip. Tooltips are suplimental info, and ideally shouldn't be the same as the name. Take the example of a button which says "remove", and when the user hovers over the remove button, it says "Removes the addon from the system" This info is provided through the description for the user. |
I came here facing the same issue and just wanted to share my point of view as I have it top of mind. As the For a screen reader user it makes sense to provide more context. Elaborating on the example from @derekriemer I believe "Remove" is often enough as tooltip for sighted users, while "Removes the addon from the system" would be better for screen reader users. Being able to differentiate text like that seems very helpful to me and generally it would be a whole lot easier and more "separation of concerns" if To me this means that the suggestion of only reading both if they differ is not relevant, I would prefer the point @BerGer23 is making by referencing the W3C spec. As it is now when I want sighted users to see a short tooltip, I'll have to author my html by having two elements, one with the On another note; why does NVDA even have differences between browsers? If the browsers get the exact same html from my site, why does NVDA behavior differ? |
Agree with @BerGer23 and @deap82 in reference to the WAI guidelines. Here's the dilemma I found myself looking into: The anchor element has the page number in it (e.g. '1', '2', '3'). The tooltip has 'Page #' in it (e.g. 'Page 1', 'Page 2', 'Page 3'). NVDA reads the following '2 link page 2' (name, type, description). A web developer has no way in this scenario to both maintain a singular '#' as the anchor text, keep a If I add an aria-label, it will read 'Page 2 Link Page 2', which is also incorrect. I can add an |
Keeping @BerGer23's comment in mind, I think the suggestion in #7841 (comment):
is a good starting point. The W3C Maps for HTML Community Group has currently implemented web maps from 12 different tools where 9 of them have at least 1 component where both |
Firefox suppresses the AccDescription, of which the title attribute is usually the primary source, if the AccName is the same. So if the name is from aria-label, but the title is also provided for tooltips for sighted people, and these two are identical, Firefox strips out the AccDescription. JAWS adopted this behavior also for other cases, such as Chromium, or Windows 32 apps. Orca on Linux does the same for ATK. I believe there are enough reasons for NVDA to be proactive here and suppress the AccDescription if the AccName is identical. It would reduce verbiage for us users in many more circumstances. Advertising for each and every authoring error or what we perceive as such, is much more cumbersome and stressful than making this change in NVDA. There won't be any information loss if these two are identical, so NVDA may as well strip AccDescription in those cases. |
100% agree with @MarcoZehe |
I agree this would be better for end users. For a11y testers using NVDA, there could be an argument to preserve this behavior behind a option (so they can more easily detect this case). Though if all screen readers accept and work around this issue, then it might as well be the standard. |
All screen readers that I tried (VoiceOver and Orca) do not duplicate read the title and the aria-label. fyi @jhomme |
Hi, |
It's not always For example, I found a case where a listbox option's name and description are identical (in Chrome and chromium Edge).
The author used the CSS magic of I wouldn't even call this case an author error - it's just an unfortunate side effect of the weirdness of the Since NVDA reads both name and description, it ends up double-speaking when they're identical, as they are in this case. As @MarcoZehe pointed out in #7841 (comment), Firefox (wisely) doesn't expose the description if it's identical to the name (no matter where the name comes from). So for NVDA to avoid double-speaking, there seem to be 2 choices:
|
Agree with the above. Also note that Screen Reader Orca on linux already does what is suggested under 2. |
Both `aria-label` and `title` has same value and NVDA reading both the texts while navigating between buttons. NVDA already has an open issue nvaccess/nvda#7841. We're removing `aria-label` until they fix it.
Fixed via #12888 |
There are many variations described on this issue. I'm going to close this issue (due to the merging of #12888). Please create a new issue to describe any variations that are not addressed. |
…14529) Both `aria-label` and `title` have the same value and NVDA reading both the texts while navigating between buttons. NVDA already has an open issue nvaccess/nvda#7841. We're removing `aria-label` until they fix it.
Steps to reproduce:
Expected behavior:
Actual behavior:
System configuration:
NVDA version: NVDA 2017.3
Windows version: Windows Server 2016
The text was updated successfully, but these errors were encountered: