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

[mediaqueries-4 ] Deprecate 'speech' media type as well? #1751

Open
patrickhlauke opened this Issue Aug 23, 2017 · 14 comments

Comments

Projects
None yet
6 participants
@patrickhlauke
Member

patrickhlauke commented Aug 23, 2017

Possibly too late now for MQ4, but just wondering if there is any known support in the wild for the "speech" media type https://www.w3.org/TR/mediaqueries-4/#media-types

To my knowledge, the answer is no...which makes me wonder if that should also be deprecated along braille, aural and co.

@patrickhlauke

This comment has been minimized.

Member

patrickhlauke commented Aug 25, 2017

@frivoal

This comment has been minimized.

Contributor

frivoal commented Sep 26, 2017

Thanks for bringing this to my attention.

The current definition of speech is lousy, as screen readers, which it claims should match it, are a better fit for screen (plus some extra capabilities), since they do work on the result of a visual layout. If that's really what it's for, it should be deprecated, because it is wrong.

If we want to use it for a set of user agents completely disjoint from visual UAs (e.g. “Siri/Alexa, read me the wikipedia page about strawman arguments”), then it would make some more sense as a media type. Which still leaves us with a question of whether anyone implements that.

Either way, it should not stay the way it is.

@tabatkins Any thoughts? Who do we get in touch with to know if they are interested in this for pure-speech UAs (not screen readers)?

@patrickhlauke

This comment has been minimized.

Member

patrickhlauke commented Sep 26, 2017

The current definition of speech is lousy, as screen readers, which it claims should match it, are a better fit for screen (plus some extra capabilities), since they do work on the result of a visual layout. If that's really what it's for, it should be deprecated, because it is wrong.

Yup, and also noting that screen readers are also used not just by 100% blind users, but those with partial sight as well, and even users with good eyesight but cognitive issues. Plus of course the fact that SRs sit on top of browsers, and the browsers clearly behave as screen user agents (although they may be able to detect there's AT running, they don't switch to now pretending to be speech devices, which would be wrong anyway per the previous bit about SR use).

@tabatkins

This comment has been minimized.

Member

tabatkins commented Sep 26, 2017

I only kept it because it was supposedly what things that used CSS Speech should identify as. If there's no actual use-cases (or the use-cases are all merely theoretical, and all UAs in reality just report "screen" and assistive agents are ok with this), then I'm totally fine with dropping it and just going with the screen/print dichotomy.

@frivoal

This comment has been minimized.

Contributor

frivoal commented Sep 27, 2017

Right, but CSS speech isn't just meant for screen readers (although they can use it was well), but also for UAs that do a pure audio rendition of the document, without any reference to a 2D visual layout. For these, the speech media type isn't crazy, except I don't know if this is just a theoretical use case, or if there are audio UAs that implement it, or audio UAs that would implement it but just haven't got around doing it yet.

My googlefu isn't very strong today, but I am pretty sure that there are EPUB UAs that can read the book aloud to you, instead of displaying it. I presume they actually work on marked up text and could support css-speech and this MQ, but I don't actually know and maybe they just work on plain text. We should check with these if they already support this or plan to, or have any kind of feedback about this.

@patrickhlauke

This comment has been minimized.

Member

patrickhlauke commented Sep 27, 2017

At the very least, can the spec be updated to not claim "Matches screenreaders" ? Because we do know that that part is not true (in, as far as I'm aware, all current screenreader scenarios).

@frivoal

This comment has been minimized.

Contributor

frivoal commented Sep 27, 2017

Sure, we'll either do that or drop the thing entirely. Either way, we need a WG resolution to make this normative change, so I'd rather get enough info ahead of time and do it right in one go. But if we can't find anything, that tells us what to do.

@frivoal

This comment has been minimized.

Contributor

frivoal commented Sep 27, 2017

@tabatkins

This comment has been minimized.

Member

tabatkins commented Oct 27, 2017

Marked as Needs Edits, because we can at least do the "stop claiming this is for screenreaders" part.

@frivoal, do you think you have enough data to bring up the rest of the issue to the WG?

@bradkemper

This comment has been minimized.

bradkemper commented Oct 29, 2017

It seems to me that what we’d be looking for is something that does parsing of Style sheets, like a browser does, but then builds its own layout tree (speech tree) after applying the rules. foo { display:none }, for instance, would remove foo from the speech tree, whether from the speech media type or the all or screen media type. But :focus foo { display: block } would put it back in. If display was used this way inside a MQ, you wouldn’t need a separate speak property.

Someone should just write a plug-in to do that.

@patrickhlauke

This comment has been minimized.

Member

patrickhlauke commented Mar 15, 2018

Is there any more information needed to bring this to the WG for a decision?

@frivoal

This comment has been minimized.

Contributor

frivoal commented Mar 19, 2018

I've done the edits discussed above (“speech is for pure-audio UAs, not screen readers”). As for deprecating it altogether, someone needs to follow up the investigation started / suggested by the tweet from #1751 (comment), and then come back to the WG.

I may get to it eventually, but if anybody wants to dive in and report back, that'd be very much appreciated.

@frivoal frivoal added the Help Wanted label Mar 19, 2018

@Krinkle

This comment has been minimized.

Krinkle commented Apr 11, 2018

To add to the above, I think the speech media type is an important one to keep.

I suspect pure-audio UAs will soon evolves from the various virtual voice assistants (Apple Siri, Google, Amazon Alexa, ..). They have yet to allow browsing an actual HTML web page, but it's not a big leap from the current web-based actions. It'd be nice to have the handling in place to arrange things differently as-needed, once this evolves.

@dd8

This comment has been minimized.

dd8 commented May 18, 2018

Results for @media speech CSS query and media=speech on link element

https://www.powermapper.com/tests/screen-readers/content/media-query-speech/
https://www.powermapper.com/tests/screen-readers/content/media-link-speech/

TL;DR; not implemented in any common screen reader / browser combination

Results from the Speech section of http://css3test.com/ for common browsers:

Chrome 66: CSS speech support 0%
Safari 11: CSS speech support 0%
Firefox 60: CSS speech support 0%
Edge 17: CSS speech support 0%
Internet Explorer 11: CSS speech support 0%
Opera 53: CSS speech support 0%

... and bug trackers for different browser and AT vendors:

NVDA screen reader: not supported
nvaccess/nvda#4242

Mozilla: not supported
https://bugzilla.mozilla.org/show_bug.cgi?id=1339987

Chrome: not supported
https://bugs.chromium.org/p/chromium/issues/detail?id=369863
https://groups.google.com/forum/#!topic/axs-chrome-discuss/b6qcNhlealg

Opera: experimental (prefixed) support up to Opera 12.10 - removed in Opera 15
https://stackoverflow.com/a/13515280

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