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

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

Closed
fantasai opened this Issue Sep 21, 2016 · 8 comments

Comments

Projects
None yet
4 participants
@fantasai
Contributor

fantasai commented Sep 21, 2016

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.

@fantasai fantasai added the Agenda+ label Jan 3, 2017

@cookiecrook

This comment has been minimized.

Contributor

cookiecrook commented Jan 5, 2017

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

This comment has been minimized.

Contributor

cookiecrook commented Jan 5, 2017

@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

This comment has been minimized.

jessebeach commented Jan 5, 2017

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

This comment has been minimized.

Contributor

cookiecrook commented Jan 5, 2017

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

This comment has been minimized.

Contributor

cookiecrook commented Jan 5, 2017

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

This comment has been minimized.

jessebeach commented Jan 5, 2017

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

This comment has been minimized.

bocampbell commented Jan 11, 2017

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

@fantasai fantasai added Needs Edits and removed Agenda+ labels Jan 31, 2017

@fantasai fantasai closed this in 4acaaa7 Feb 1, 2017

@fantasai fantasai removed the Needs Edits label Feb 1, 2017

@fantasai

This comment has been minimized.

Contributor

fantasai commented 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 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.

triple-underscore added a commit to triple-underscore/triple-underscore.github.io that referenced this issue May 6, 2017

[css-speech] Editor’s Draft に切り替え
speak プロパティの値が更新された:

Rename 'speak: none' and 'speak: normal' to 'speak: never' and 'speak:
always' for clarity, per WG resolution.
<https://lists.w3.org/Archives/Public/www-style/2017Jan/0005.html>
Fixes w3c/csswg-drafts#510 .

w3c/csswg-drafts@4acaaa7
32473f098cb

仕様上の他の更新はなし。

その他の編集(マークアップその他の簡素化
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment