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

Populate tooltip content using the aria-label attribute #128

Merged
merged 1 commit into from
Mar 14, 2016

Conversation

jdan
Copy link
Contributor

@jdan jdan commented Mar 2, 2016

Hi @chinchang!

Copying some notes from my original issue comment:

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.

…hang#81

This changeset modifies `hint-core.scss` to use `aria-label` as its source so that the tooltip content can be read by screen-readers. This pattern is used in GitHub's "Primer" framework (see http://primercss.io/tooltips/)

Doing so required all base styles to be applied to the `hint--`-prefixed classes, since `data-hint` is no longer used.

To test these changes I modified `demo.html` to use the new `aria-label` pattern, then modified the "bottom-right" demo button so that its tooltip read off "Hello, world." I confirmed that the sentence was read off by a screen-reader (VoiceOver in Safari, as well as ChromeVox in chrome).

These changes come with the assumption that tooltips are in fact a label for the element they are annotating - meaning that the contents of the element will be skipped over by the screen-reader in favor of the tooltip's contents. If the tooltips are primarily used to annotate icons, this is perfectly acceptable.
@jdan
Copy link
Contributor Author

jdan commented Mar 2, 2016

In your response you outlined the following strategy for generating the tooltip text:

  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

Do you know if it's possible to do this with content/attr alone?

@jasonblanchard
Copy link

👍

@danlopez
Copy link

danlopez commented Mar 8, 2016

This would be really helpful to get merged in, any progress on this @chinchang?

@chinchang
Copy link
Owner

@jdan I have some theories in mind. Will try implementing them if they work out.

@danlopez Will spend time on this the coming weekend.

Merging this branch into the a11y WIP branch to take it forward.

chinchang added a commit that referenced this pull request Mar 14, 2016
Populate tooltip content using the aria-label attribute
@chinchang chinchang merged commit e004a4c into chinchang:a11y Mar 14, 2016
@jdan
Copy link
Contributor Author

jdan commented Mar 14, 2016

Excellent, keep me posted! Happy to contribute in any capacity.

@danlopez
Copy link

Hey @chinchang - any updates on the timeline to get this work merged back into master?

@chinchang
Copy link
Owner

I went through the specs for css3-content property: https://www.w3.org/TR/css3-content/

Though they seem to have a provision for fallback syntax in attr like so:

figure[alt] { content: attr(href, url), attr(alt); }

it doesn't look like its implemented in browsers yet!

So that means handling aria-label and data-hint attributes probably won't be possible by a single file. That leaves us to having a separate version of hint.css with a11y features, say hint-a11y.css (just like we have hint-base.css now).

How does that sound? Comments, suggestions?

@jdan
Copy link
Contributor Author

jdan commented Apr 17, 2016

My suggestion is to use aria-label instead of data-hint completely as a breaking change :) I'm biased though.

Separating them into two files sounds fine, just hoping folks will use it!

@danlopez
Copy link

We'd definitely use hint-a11y.css if it were provided.

@chinchang
Copy link
Owner

chinchang commented Apr 18, 2016

@jdan @danlopez :) You guys are a11y supporters! Though I am also running a poll to get more inputs: https://twitter.com/hint_css/status/722155293518376961

BTW, good news is that I have been able to provide support for both aria-label and data-hint attributes just using CSS using @tfoxy code in the associated issue: #81 (comment) 👍
Have opened a PR against dev with my changes.

Would be great if you guys can review #137

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

Successfully merging this pull request may close these issues.

4 participants