-
-
Notifications
You must be signed in to change notification settings - Fork 698
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
Screen reader testing #81
Comments
Adding ARIA might help, even just the role role="tooltip" Some examples here: |
We wouldn't be able to add attributes to content generated in CSS. It is possible to add a recommendation use the aria-label attribute in combination with the data-hint attribute. Would that help? |
I started a discussion about this with the NVDA team here http://community.nvda-project.org/ticket/4242#comment:3 It's really more of an aria-describedby kind of issue, as the tooltip is always just a description of the main text. Two examples of accessible tooltips that are brought up are: Using role="tooltip" in conjunction with:
and:
Might help. These are from http://heydonworks.com/practical_aria_examples/ The different behavior from AT definietly doesn't help. |
But this implementation is impossible with hint.css, because there is no html to add the role attribute to. |
I think that the best solution is using Note that if you using hint.css on a image(for example a SVG icon) the ´alt´ attribute will do the job, the tooltip it self would be ignored but the |
Agreed with CSS3 Speech sadly. These are mostly for links though, so can't see how alt would work. aria-label though would be useful. However VoiceOver already reads it out just like it is regular text. |
Both examples is fully working in screen readers, I can't see where Hint.css can or should improve the support. Note that using Hint.css as the following example is bad accessibility practice and should be avoided: Still a note about using |
It seems like to best fix here is to add the aria-label attribute to all the examples? |
For longer text aria-describedby might be more relevant. But hint.css seems to work better for shorter text anyways. Would be great to see aria-label added to these examples. That is probably the best approach. |
@lewisnyman adding Still using a tooltip to describe links is bad accessibility practice, not for screen readers, but for people with disabilities such as dyslexia and ADHD. |
@Abbe98 I agree. Besides GitHub is using |
Sadly GitHub isn't the best example for accessible applications. Not that this says that the use of aria-label is a a bad one. |
Accessibility is not limited to screen-readers. Using ARIA here won't help sighted keyboard users. Ironically I did a fiddle yesterday (updated: https://jsfiddle.net/thierrykoblentz/s1ht4j41/1/) to show how one could make the As a side note, regarding @mgifford comment:
The above should hide the tooltip from all users (including screen-reader users). How would that be revealed to keyboard users? May be the easiest route to fix the screen-reader users experience would be to not hide the content of the tooltips in the first place, using a technique that make elements only invisible to sighted users: |
Hey all, I've forked this repository and committed a proof-of-concept change to use You'll see that using But the tooltip's contents are now accessible to screen-readers: These changes follow the assumption that the tooltip is labeling the element it is annotating. This means that screen-readers will not read off the actual content of the element itself, but only its tooltip. Consider the following: In the above scenario, "Checkout" will be omitted in favor of "You will be charged $5.00" by the screen-reader. Happy to talk about this in detail! @chinchang / any other maintainers, let me know if these changes are desirable and I'll be happy to put up a PR. |
I use the following css so I don't have to repeat the tooltip text twice: [data-hint=''][aria-label]:after {
content: attr(aria-label);
}
[data-hint=''][aria-label]:before,
[data-hint=''][aria-label]:after {
display: block !important;
}
[data-hint=''][aria-label='']:before,
[data-hint=''][aria-label='']:after {
display: none !important;
} <a href="#" class="hint--bottom" data-hint aria-label="Some text"></a> |
@jdan This is nice! Thanks for setting up a fork. Now a way needs to be found out for getting this breaking change into the main library. IMO, the library should continue working with
Also, in your fork you can use I have created a WIP branch for accessibility - @tfoxy I didn't get why you mentioned about 'repeating tooltip text twice'. 😕 |
I was referring to the comment made by @Abbe98, where right now you have to put the same value for data-hint and aria-label if you don't add a css rule. I like your suggestions. It would be great if there is an official support for aria-label. |
While we are on solving this, I had a doubt that I wanted to discuss here. I have heard a lot that a11y should be baked into your apps. I researched a bit into analytics for things like screen readers etc and found that its hard to detect if your app is actually being used on a screen reader. My question is: Why would I care about adding such a11y support (eg. screen reader support) when I don't really know if people really use my app with screen readers or not? |
Screen readers are just one type of disability. If you include people with hearing problems, mobility challenges, low vision, learning disabilities, as well as temporary conditions like injuries or incremental factors like aging, the % of folks with disabilities is closer to 20% of the population. So between that, increasing legislation and the moral arguments about rights to participation in society, there are a lot of reasons. Do they speak to you and your project? Possibly not. |
🏁 This is finally live in v2.3.0! Thanks everyone who requested, helped and worked on this feature 😄 |
Would be great to have some additinal screen reader testing.
The data-hint="LEFT-over Sir..." isn't read at all in ChromeVox and is read no different than the rest of the text in VoiceOver.
I haven't tested in WindowsEyes, NVDA or JAWS yet.
It would be important to have a pause of some sort at the very least. Alternately a prefix.
I don't think there's any support for this, but something like http://www.w3.org/TR/css3-speech/ would be very useful.
The text was updated successfully, but these errors were encountered: