W3C home > Mailing lists > Public > www-style@w3.org > December 2014

Re: [css-speech][css-content][mediaqueries] Making Generated Content Accessible

From: James Craig <jcraig@apple.com>
Date: Wed, 3 Dec 2014 18:30:10 -0800
Cc: Florian Rivoal <florian@rivoal.net>, fantasai <fantasai.lists@inkedblade.net>, Alan Stearns <stearns@adobe.com>, www-style list <www-style@w3.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, fantasai <fantasai@inkedblade.net>
Message-Id: <D9047669-4583-45E6-8523-3E96442547B8@apple.com>
To: Daniel Weck <daniel.weck@gmail.com>

> On Dec 3, 2014, at 5:50 AM, Daniel Weck <daniel.weck@gmail.com> wrote:
> On Wed, Dec 3, 2014 at 3:43 AM, James Craig <jcraig@apple.com> wrote:
>>> This raises 2 (related) questions. Is the introduction of this media feature sufficient to deprecate the “speech" media type into never matching? If not, can and should the same privacy model be applied to it?
>> My understanding is that the speech media type is *only* useful for linearized audio-only media not intended for the screen, since it is mutually exclusive with the screen media type. Most assistive technologies operate on some concept of a "screen" (including screen readers for the blind) so the speech media type should never apply to screen readers or ScreenMagnifier+Speech utilities, but its possible there is some use case. For example, if you were to turn an EPUB into a generated TTS audiobook, the speech media type could apply. I don't know if any implementations support that, but you'd probably want to check with someone from DAISY before making it a No-Op.
> Yes, from a content design perspective, the 'speech' Media Type can be
> used to define a "complete aural alternative to a visual presentation"
> (full quote below), and as per the specification: such representation
> would be mutually exclusive to other media types, when "rendered"
> within a *given* canvas. The same applies to 'braille' (for example),
> although the "tactile" Media Group also includes the 'embossed' Media
> Type (conversely, 'speech' stands on its own).

It's worth noting, like the linearized speech media type, this is linearized braille (e.g. an embossed braille book) not a refreshable braille display that would be used with a screen reader. I don't know of any implementations of the braille or embossed media types.

> I am not sure about the current state of screen-reader support for the
> CSS Speech properties (formerly "Aural" stylesheets), let alone for
> the selective application of properties defined within the scope of
> the 'speech' media type. My assumption is that there are very few
> implementations, most are partial, and based on the old "Aural"
> specification.

WebKit plus VoiceOver on iOS has had partial support since iOS 5. We demoed this at WWDC in 2011 (note the speak property demoed has since been updated to speak-as) but haven't seen much uptake since then. Slides and demo starts at 15:36 in https://developer.apple.com/videos/wwdc/2011/?id=519

> "
> The CSS Speech properties provide the ability to control speech pitch
> and rate, sound levels, TTS voices, etc. These stylesheet properties
> can be used together with visual properties (mixed media), or as a
> complete aural alternative to a visual presentation.
> "
> http://www.w3.org/TR/css3-speech/#intro
> The use of the 'speech' Media Type is merely a recommendation in the
> context of EPUB3. The CSS Speech properties can be applied in the
> default stylesheet of an EPUB XHTML5 document, irrespective of the
> 'speech' Media Type. I am not aware of any supporting e-reader
> implementation (more often than not, the screen-reader would take care
> of picking-up the CSS Speech properties anyway, but occasionally an
> e-reader could also be "self-voicing", interfacing directly with a TTS
> API, to programmatically pass the CSS parameters to the synthetic
> speech engine).
> More information about the historical shift from "aural" to "speech":
> http://www.w3.org/TR/css3-speech/#background
> Regards, Daniel

Thanks Daniel.

Received on Thursday, 4 December 2014 02:30:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:49 UTC