Screen reader testing

[mgifford]

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.

[mgifford]

Adding ARIA might help, even just the role role="tooltip"

Some examples here: http://www.w3.org/WAI/PF/aria-practices/#tooltip

[lewisnyman]

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?

[mgifford]

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: http://www.oaa-accessibility.org/examplep/tooltip2/ http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/test_Tooltip.html

Using role="tooltip" in conjunction with:

<div id="password-tip" role="tooltip">Was emailed to you when you signed up</div>

and:

[role="tooltip"] {
    background: none repeat scroll 0 0 #ef8100;
    display: none;
    margin: 0;
    z-index: 2;
}

Might help.

These are from http://heydonworks.com/practical_aria_examples/

The different behavior from AT definietly doesn't help.

[lewisnyman]

But this implementation is impossible with hint.css, because there is no html to add the role attribute to.

[Abbe98]

I think that the best solution is using aria-label, CSS3 Speech won't be supported by any browser in the near future...

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 alt text would be used by screen readers.

[mgifford]

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.

[Abbe98]

<a href="#" class="hint--bottom" data-hint="Some text" aria-label="Some text"></a> <a href="#" class="hint--bottom" data-hint="Some text"><img src="someimage" alt="Some text" /></a>

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: <a href="#" class="hint--bottom" data-hint="Text describing link">Text</a>

Still a note about using aria-label should be added to the documentation together with examples of when it's needed and when it's not...

[lewisnyman]

It seems like to best fix here is to add the aria-label attribute to all the examples?

[mgifford]

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.

[Abbe98]

@lewisnyman adding aria-label would be the best solution right now.

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.

[Misiu]

@Abbe98 I agree. Besides GitHub is using aria-label in their CSS tooltips

[mgifford]

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.

[thierryk]

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 title attribute of abbr accessible to sighted users. That was a tongue in cheek example, but creating a tab stop (via tabindex for non focusable elements) may be the first step.

As a side note, regarding @mgifford comment:

[role="tooltip"] {
    background: none repeat scroll 0 0 #ef8100;
    display: none;
    margin: 0;
    z-index: 2;
}

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: https://developer.yahoo.com/blogs/ydn/clip-hidden-content-better-accessibility-53456.html but that would require to have that content inside a node instead of the value of an attribute...

[jdan]

Hey all,

I've forked this repository and committed a proof-of-concept change to use aria-label as the source for the tooltip's contents: https://github.com/jdan/hint.css/commit/e6541166ec055c525485c5922027aab0b7a25004

You'll see that using aria-label instead of data-hint has the same results:

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.

[tfoxy]

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>

[chinchang]

@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 data-hint attribute but also support aria-label attribute so that existing apps don't break with new library. Summarizing the requirements:

1. If only data-hint present, use data-hint
2. If only aria-label present, use aria-label
3. If both data-hint and aria-label present, use aria-label

Also, in your fork you can use [class*="hint--"] selector instead of using all hint-* classes to put base styles on...much smaller :)

I have created a WIP branch for accessibility - a11y. Would request you to please open a PR against that branch which can be taken forward.

@tfoxy I didn't get why you mentioned about 'repeating tooltip text twice'. :confused:

[tfoxy]

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.

[chinchang]

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?

[mgifford]

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.

[chinchang]

🏁 This is finally live in v2.3.0! Thanks everyone who requested, helped and worked on this feature 😄