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

[css-speech][css-content] Making Generated Content Accessible

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 05 Nov 2014 09:51:17 -0800
Message-ID: <545A6395.2070101@inkedblade.net>
To: James Craig <jcraig@apple.com>
CC: Alan Stearns <stearns@adobe.com>, www-style list <www-style@w3.org>, "jackalmage@gmail.com" <jackalmage@gmail.com>, fantasai <fantasai@inkedblade.net>
On 11/05/2014 09:31 AM, James Craig wrote:
> Please see the 2012 www-style thread referenced below.
>>>>> http://lists.w3.org/Archives/Public/www-style/2012Nov/thread.html#msg233
> I originally discussed non url() content fallback and was persuaded
> by members of the CSS WG that “alt” was the best solution. Among
> other reasons, the content property provides no way to specify
> fallback content for rendered *text* content such as glyphs.
> content: "\2730", attr(title); /* pointless */

Yes, this a problem that needs solving. But a separate property is not a
good solution. Either we need to have some form of switching at the style
rule level, or we need some form of switching inline within the content
property syntax.

> Speech media is mutually exclusive with screen media, so it *only* covers
> the DAISY case (linearized audio) and does not apply to any assistive
> technology as far as I can tell. Perhaps the speech media type should
> be renamed linearized-audio to avoid to misconception that it applies to
> *screen* readers and other assistive technology that use speech, including
> screen magnifiers.

Then perhaps we need some new media type or query, or to redefine how 'speech'
works. I think it's important that CSS be able to target styles at the screen
reader. I think it's also important that we make it easy to target all forms
of speech output, for things like this. (I'm rather less convinced that we
need to distinguish between the two. Screen reader to me seems like it should
be an alternate navigational interface over the same aural canvas.)

> Perhaps these two CSS modules should be combined to avoid this confusion
> in the future?

No, they are quite different sets of functionality... It's just that
::before/::after pseudos tend to be used with the 'content' property.
But anyway, that's a problem for us to solve, not something for you
to worry about. ^_^

Received on Wednesday, 5 November 2014 18:15:07 UTC

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