Repository navigation
[css-speech] Rename speak: none | normal to speak: never | always #510
Description
Discussing the speak property with Matthew King and Jesse Beach, they suggested that speak: auto | always | never would be easier to understand than speak: auto | normal | none. Seems like a great improvement to me, if no one has implemented it yet.
Activity
cookiecrook commentedon Jan 5, 2017
WebKit implemented the spec version in ~2011 and the CSS draft changed shortly after (IIRC, the
speakandspeak-asproperties were a singlespeakproperty at the time), but I don't believe it's been widely used since then. I'm open to any changes that make sense.iOS 5 demo and details starting at timecode 15:36.
https://developer.apple.com/videos/play/wwdc2011/519/
cookiecrook commentedon Jan 5, 2017
@jessebeach @mcking65 I have a minor aversion to
alwayssince it implies a web author could override a screen reader user's verbosity prefs.jessebeach commentedon Jan 5, 2017
We were trying to avoid the word
normalin the context of speech, in the sense that it suggests the possibility ofabnormal.What about
auto | yes | no?cookiecrook commentedon Jan 5, 2017
CSS tries to use open-ended keywords rather than closed boolean values like yes/no due to clarity and future extensibility concerns.
For example, a lot of CSS Speech (especially
*-beforeand*-after) is skewed toward linearized audio presentations (e.g. DAISY ebook reader) rather than critically brief-time-to-utterance screen reader navigation, but some uses may need to to differentiate those contexts. There could be future values that would allow authors to specify relevance when the audio is linearized (e.g. read all) or when the user was actively navigating the content (e.g. screen reader user navigates directly to this element). Similar distinctions might also be made for low-vision zoom+speech users, or for users with reading difficulties like dyslexia. Most platforms offer a "speak text on mouse hover" feature as a first- or third-party utility.What about these other possibilities for the time being? They leave open the possibility of splitting the
allorspeakvalue into more specific contexts later.The
speak-asproperty has anormalvalue, too. Should that also change toautoordefault?PS. Distinguishing "linear audio" from "screen reader" from "mouse hover speech" might be better implemented as media features than values, but I don't want boolean values to preclude them today.
Update 2017-02-01: @atanassov, are you interested in trying to resolve these issues CSS Speech (focused on linearized audio) so that it works for all contexts (assistive tech)? It's not a high priority for me, but I am interested in contributing if there is cross-implementation interest. IIRC, WebKit implements more of CSS-Spech than any other UA.
cookiecrook commentedon Jan 5, 2017
Comments on the current value definitions for
speak:The spec should either make it clear most text-to-speech contexts are affected by both
displayandvisibility, or it should declare this means "speak if visibly rendered". The "if rendered" option might require a new glossary term that makes it clearopacity: 0still counts as rendered even thoughdisplay: noneandvisibility: hiddendon't.I think it's unlikely anyone has implemented this as defined. What user benefit is achieved by ignoring the ancestor cascade?
Implementability could be questionable or challenging, too. Most implementations don't generate a render element for DOM elements matching
display: noneso it's unlikely there will be anything exposed to the accessibility APIs. I'm fairly certain this is the case in Gecko, WebKit, and Blink, but I am less certain about Edge.jessebeach commentedon Jan 5, 2017
The
speak: auto | always | neverwas intended to separate the aural ux from the visual display value. "Always" speak this element, regardless of whether it's visually displayed or not.In the end, I think we really just need an implementation that separates aural output from visibility, so that we're not reliant on offscreen hacks to keep content in the DOM, but out of sight. The token values of the speak prop are largely arbitrary as long as they front the correct behavior.
bocampbell commentedon Jan 11, 2017
Passed for review within IBM Accessibility group. Positive feedback, no objections.
fantasai commentedon Feb 1, 2017
@cookiecrook The issue with 'visibility' is covered in issue #511. The concern you state about descendants is handled by the specific ways in which the
autovalue computes and inherits. Also, while I appreciate your comments, both of these are out of scope for a renaming request. :) Wrt verbosity prefs and speech context-specific settings... I think you should open new issues for those, as I really can't handle them here, especially with so little information on what they are. Context in CSS is usually handled by media queries, fwiw.The WG resolved to accept the renaming suggestion in https://lists.w3.org/Archives/Public/www-style/2017Jan/0005.html. I think this greatly improves usability of the property, and it has been edited into the ED. I'll try to get an updated CR ready soon-ish; there was however a suggestion to split out
speakandspeak-asinto their own Level 1 draft (with the rest of the spec as Level 2), in which case there's some extra work to be done.[css-speech] Editor’s Draft に切り替え
ianthedev commentedon Apr 25, 2019
Hi all. Can we have an update on which syntax is the valid one for making elements/pseudo-elements inaudible? Is it
speak: neverorspeak: none?In the css-validator repository, I opened an issue regarding
speak: neverbeing reported as invalid by citing a spec. But someone closed the issue saying the spec I cited is a Retired Note and is never implemented.Merge pull request #510 from danielsakhapov/patch-1