5 ms·

How accessible is this approach to screen reader users and people who rely on keyboard interaction alone? Edit: A quick test reveals these tooltips are not acc

by 10dpd 11y ago

How accessible is this approach to screen reader users and people who rely on keyboard interaction alone? Edit: A quick test reveals these tooltips are not accessible at all.

robin_reala 11y ago
Not with keyboard interaction: they’d have to add :focus rules and tabindexes to the parent. Screen readers sometimes read out generated content. Léonie has more info: http://tink.uk/accessibility-support-for-css-generated-content/ http://tink.uk/accessibility-support-for-css-generated-conte...
kdamken 11y ago
Unfortunately that's a major deal breaker for using this for any professional project. Making things accessible isn't really that hard, and it makes the lives of people who need it much easier. It's a shame it's not more common place.
- oneeyedpigeon 11y ago
  Yup. Use of the title attribute would be better, but I don't think there's a way to turn off the default behaviour, unfortunately.
wodenokoto 11y ago
Isn't there a tag for links similar to the description tag for images? If so, you could just enter the tooltip there as well.
- robin_reala 11y ago
  No. Well, you could use aria-describedby but that has to refer to a separate element. There’s no generic aria-description.
  - ehnto 11y ago
    You could use aria-label potentially, but it has fairly scrict semantic connotations as a label for an input, I believe.
    - prezjordan 11y ago
      aria-label is totally cool for not-input's: https://www.w3.org/WAI/GL/wiki/Using_aria-label_to_provide_labels_for_objects#Example_1 https://www.w3.org/WAI/GL/wiki/Using_aria-label_to_provide_l...
    - chinchang 11y ago
      Yeah, that should bring in some accessibility. Right now the library uses `data-hint` attribute. We could use `aria-label` attribute instead!
chinchang 11y ago
Keyboard accessibility should arrive soon: https://github.com/chinchang/hint.css/pull/111 https://github.com/chinchang/hint.css/pull/111
prezjordan 11y ago
To address the screen-reader concerns: As a proof of concept I was able to swap out `data-hint` for `aria-label` without issue: https://github.com/jdan/hint.css/commit/e6541166ec055c525485c5922027aab0b7a25004 https://github.com/jdan/hint.css/commit/e6541166ec055c525485... `aria-label` is essentially used twice here - both to populate the tooltip's contents, and to provide an accessibility label to the element that can be read off by a screen-reader. I proposed these changes to the maintainers under an existing a11y issue (yay to people thinking about it!), but pointed out that if folks are using this library to supplement the contents of an element with a tooltip instead of labeling it, then the a11y changes are not ideal because a screen-reader will omit the element's contents in favor of whatever is inside the tooltip. My gut tells me that this library is mainly used to annotate things like icons.
danielnixon 11y ago
As soon as I see "pure CSS" or "CSS only" this is the first thing I think of. This meme that "pure CSS" is a Good Thing is a shame.

by 10dpd 11y ago

How accessible is this approach to screen reader users and people who rely on keyboard interaction alone? Edit: A quick test reveals these tooltips are not accessible at all.

robin_reala 11y ago

Not with keyboard interaction: they’d have to add :focus rules and tabindexes to the parent. Screen readers sometimes read out generated content. Léonie has more info: http://tink.uk/accessibility-support-for-css-generated-content/ http://tink.uk/accessibility-support-for-css-generated-conte...

kdamken 11y ago

Unfortunately that's a major deal breaker for using this for any professional project. Making things accessible isn't really that hard, and it makes the lives of people who need it much easier. It's a shame it's not more common place.

oneeyedpigeon 11y ago
Yup. Use of the title attribute would be better, but I don't think there's a way to turn off the default behaviour, unfortunately.

wodenokoto 11y ago

Isn't there a tag for links similar to the description tag for images? If so, you could just enter the tooltip there as well.

robin_reala 11y ago
No. Well, you could use aria-describedby but that has to refer to a separate element. There’s no generic aria-description.
- ehnto 11y ago
  You could use aria-label potentially, but it has fairly scrict semantic connotations as a label for an input, I believe.
  - prezjordan 11y ago
    aria-label is totally cool for not-input's: https://www.w3.org/WAI/GL/wiki/Using_aria-label_to_provide_labels_for_objects#Example_1 https://www.w3.org/WAI/GL/wiki/Using_aria-label_to_provide_l...
  - chinchang 11y ago
    Yeah, that should bring in some accessibility. Right now the library uses `data-hint` attribute. We could use `aria-label` attribute instead!

chinchang 11y ago

Keyboard accessibility should arrive soon: https://github.com/chinchang/hint.css/pull/111 https://github.com/chinchang/hint.css/pull/111

prezjordan 11y ago

To address the screen-reader concerns: As a proof of concept I was able to swap out `data-hint` for `aria-label` without issue: https://github.com/jdan/hint.css/commit/e6541166ec055c525485c5922027aab0b7a25004 https://github.com/jdan/hint.css/commit/e6541166ec055c525485... `aria-label` is essentially used twice here - both to populate the tooltip's contents, and to provide an accessibility label to the element that can be read off by a screen-reader. I proposed these changes to the maintainers under an existing a11y issue (yay to people thinking about it!), but pointed out that if folks are using this library to supplement the contents of an element with a tooltip instead of labeling it, then the a11y changes are not ideal because a screen-reader will omit the element's contents in favor of whatever is inside the tooltip. My gut tells me that this library is mainly used to annotate things like icons.

danielnixon 11y ago

As soon as I see "pure CSS" or "CSS only" this is the first thing I think of. This meme that "pure CSS" is a Good Thing is a shame.