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

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

From: Florian Rivoal <florian@rivoal.net>
Date: Wed, 3 Dec 2014 15:20:09 +0100
Cc: James Craig <jcraig@apple.com>, 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: <5EF0BD3C-56C6-4706-AE54-83A044218E95@rivoal.net>
To: Daniel Weck <daniel.weck@gmail.com>
On 03 Dec 2014, at 14:50, 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.
> 
> 
> Hello,

Hi, Thanks for the feedback, I was hoping you'd pop in.

> 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).

The exclusive nature of media types has turned out to be an issue in almost all cases, which is why we're generally trying to deprecate them, and replace them by media features which capture the key aspect that made the media types different.

Unlike a type like handheld for example, which was so similar to screen that browsers never matched it due to compat concerns, speech may be sufficiently different from screen an exclusive media type could work. At the same time, given the existence both of speech-UAs which only read the content out loud in a linear fashion (E-pub reader) *and* of speech UAs which do speech as an assistive complement to a visual 2d rendering, I am not so sure that this is really exclusive.

What would you think (naming aside) about a media feature like this:
speech: none | linear | screen-based

Ignoring the possible issue of legacy content for now, it seems to me that there would be no need for the speech media type if we had that, and that its ability to discriminate between linear vs screen oriented speech makes its more useful.

 - Florian 
Received on Wednesday, 3 December 2014 14:20:35 UTC

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