[css-speech] Rename speak: none | normal to speak: never | always

[fantasai]

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.

[cookiecrook]

WebKit implemented the spec version in ~2011 and the CSS draft changed shortly after (IIRC, the speak and speak-as properties were a single speak property 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]

@jessebeach @mcking65 I have a minor aversion to always since it implies a web author could override a screen reader user's verbosity prefs.

[jessebeach]

We were trying to avoid the word normal in the context of speech, in the sense that it suggests the possibility of abnormal.

What about auto | yes | no?

[cookiecrook]

What about auto | yes | no?

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 *-before and *-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 all or speak value into more specific contexts later.

speak: auto | all | none
speak: auto | speak | none
speak: default | all | none 
speak: default | speak | none

The speak-as property has a normal value, too. Should that also change to auto or default?

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]

Comments on the current value definitions for speak:

auto
Resolves to a computed value of none when display is none, otherwise resolves to a computed value of auto which yields a used value of normal.

The spec should either make it clear most text-to-speech contexts are affected by both display and visibility, or it should declare this means "speak if visibly rendered". The "if rendered" option might require a new glossary term that makes it clear opacity: 0 still counts as rendered even though display: none and visibility: hidden don't.

normal (Note: name may be changed)
The element is rendered aurally (regardless of its display value and the display and speak values of its ancestors).

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: none so 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]

The speak: auto | always | never was 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]

Passed for review within IBM Accessibility group. Positive feedback, no objections.

[fantasai]

@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 auto value 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 speak and speak-as into 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.

[ianthedev]

Hi all. Can we have an update on which syntax is the valid one for making elements/pseudo-elements inaudible? Is it speak: never or speak: none?

In the css-validator repository, I opened an issue regarding speak: never being 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.