Support for W3C's CSS Speech Module #4242

Open
nvaccessAuto opened this Issue Jul 2, 2014 · 3 comments

Projects

None yet

1 participant

@nvaccessAuto

Reported by mgifford on 2014-07-02 00:20
I'm trying to see if there is a way to improve the accessibility for http://kushagragour.in/lab/hint/

Which is now part of Drupal 8.

I'd like to see that there is support for http://www.w3.org/TR/css3-speech/

So that we could either insert a pause or change the voice family befor the tooltip is used.

Right now in VoiceOver it is all read together. In ChromeVox it gets ignored. However, there should be some means to convey that the tooltip is distinct aurally from the text it is describing.

This is probably a lot bigger than NVDA. Does NVDA support the CSS Speech Module?

@nvaccessAuto

Comment 2 by jteh on 2014-07-02 06:18
To directly answer your question, no, the CSS speech module is not supported. This would need significant work in all existing browsers and screen readers and may even require additions to current accessibility APIs. This is not likely to happen any time soon.

Whether we should even do this is somewhat controversial. A screen reader is a bit different to an interface designed specifically for speech. The intention is to represent all functionality available to a "screen" user, even if, in doing so, the speech might not be as "friendly" as one might expect from a specialised speech interface. Being able to tell a screen reader how numbers should be read or a name should be pronounced might be ideal, though even here, we would hit problems mapping this back to screen position, for example. However, we wouldn't want the content to be made entirely different.

As to this specific case, generally, secondary content such as a tooltip is exposed separately from the primary content; e.g. as the "description" of the accessible element. For example, if you use the @title attribute on a link, the link content will be the link's name and the title will be its description. This way, the two types of content are separated and the screen reader can choose how to handle them. This can be done with ARIA attributes; e.g. aria-labelledby and aria-describedby. I feel this would be the more appropriate way to go here; i.e. expose them separately so that the AT decides how to handle them, rather than the library choosing a specific speech experience. The experience chosen by the library might be completely different from how a given screen reader normally reports tooltips.

I'm leaving this open because it certainly needs further discussion, but it's very low priority at this stage.

@nvaccessAuto

Comment 3 by mgifford on 2014-07-02 13:09
Very interesting! Thanks for taking the time to detail this.

I have asked in FF https://bugzilla.mozilla.org/show_bug.cgi?id=47159 & Chrome https://code.google.com/p/chromium/issues/detail?id=369863&q=css3%20speech&colspec=ID%20Pri%20M%20Iteration%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified

But neither is supporting it yet http://css3test.com/

I am sure that any of these elements could be easily abused in a way that makes it less accessible.

speak-as, pause, rest, cue all seem like they could be quite useful if done properly. But as with the title attribute, it's so easy to get it wrong. I've felt that it would be nice to use the voice-family consistently with say an admin theme or perhaps administration functions provided by the CMS. If there was support for this, it might provide the same aural cues that we have visually. Are there places where the pros/cons for this have been publically debated?

But yes, on the specific issue of tooltips, my sense is that the @title attribute has been badly abused and confused with alt text in general. My assumption has been that most screen reader users simply ignore the title as it usually isn't useful.

I don't know that there is a "normal" for tooltips. I'm assuming that these are still great examples Open Ajax Alliance & Dojo nightly http://www.w3.org/WAI/PF/aria-practices/#tooltip

I'm assuming NVDA supports the role="tooltip" and it does really feel like a describedby type of event.

Hopefully we can keep this conversation going a bit more.

@nvaccessAuto

Comment 4 by jteh (in reply to comment 3) on 2014-07-03 22:50
Replying to mgifford:

I've felt that it would be nice to use the voice-family consistently with say an admin theme or perhaps administration functions provided by the CMS. If there was support for this, it might provide the same aural cues that we have visually.

It's certainly a tricky issue. On the surface, it does seem to make sense that if you can style something visually, you should be able to style it aurally. However, a visual user doesn't require an intermediary tool to present information to them in a primarily linear fashion, so it is a more direct mapping. One problem is that a screen reader might use certain voices for specific purposes, so if something else uses these, it might be very confusing.

Are there places where the pros/cons for this have been publically debated?

Not that I know of.

But yes, on the specific issue of tooltips, my sense is that the @title attribute has been badly abused and confused with alt text in general. My assumption has been that most screen reader users simply ignore the title as it usually isn't useful.

That's not really my experience, especially on form fields and links.

I'm assuming NVDA supports the role="tooltip" and it does really feel like a describedby type of event.

Actually, NVDA doesn't really care about the tooltip role here. The key point is that aria-describedby references the tooltip, so the tooltip content becomes the "description" of the element in question. An NVDA user can then query this on demand and it is also reported when the element is focused, just as a sighted user would generally have to mouse over the element (or interact with it in some other way).

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