Skip to content
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

Closed
mgifford opened this issue Jul 2, 2014 · 20 comments
Closed

Screen reader testing #81

mgifford opened this issue Jul 2, 2014 · 20 comments

Comments

@mgifford
Copy link

mgifford commented Jul 2, 2014

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
Copy link
Author

mgifford commented Jul 2, 2014

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

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

@lewisnyman
Copy link

lewisnyman commented Jul 2, 2014

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
Copy link
Author

mgifford commented Jul 2, 2014

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
Copy link

lewisnyman commented Jul 3, 2014

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

@Abbe98
Copy link

Abbe98 commented Jul 4, 2014

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
Copy link
Author

mgifford commented Jul 5, 2014

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
Copy link

Abbe98 commented Jul 5, 2014

<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
Copy link

lewisnyman commented Jul 6, 2014

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

@mgifford
Copy link
Author

mgifford commented Jul 6, 2014

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
Copy link

Abbe98 commented Jul 6, 2014

@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
Copy link

Misiu commented Sep 10, 2014

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

@mgifford
Copy link
Author

mgifford commented Sep 10, 2014

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
Copy link

thierryk commented Jan 28, 2016

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
Copy link
Contributor

jdan commented Feb 1, 2016

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: jdan@e654116

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

screen shot 2016-02-01 at 10 24 25 am

But the tooltip's contents are now accessible to screen-readers:

screen shot 2016-02-01 at 10 25 06 am

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:

image

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
Copy link

tfoxy commented Feb 20, 2016

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
Copy link
Owner

chinchang commented Feb 23, 2016

@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'. 😕

@tfoxy
Copy link

tfoxy commented Feb 24, 2016

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
Copy link
Owner

chinchang commented Apr 18, 2016

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
Copy link
Author

mgifford commented Apr 18, 2016

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
Copy link
Owner

chinchang commented May 21, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants