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

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

From: James Craig <jcraig@apple.com>
Date: Thu, 6 Nov 2014 11:51:11 -0800
Cc: Alan Stearns <stearns@adobe.com>, www-style list <www-style@w3.org>, "jackalmage@gmail.com" <jackalmage@gmail.com>, fantasai <fantasai@inkedblade.net>
Message-Id: <D4283AF4-C6FD-403A-94AB-E3F38089A332@apple.com>
To: fantasai <fantasai.lists@inkedblade.net>
[snip]

> On Nov 5, 2014, at 9:51 AM, fantasai <fantasai.lists@inkedblade.net> wrote:
> 
>> 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
> 
> 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 also proposed a "(screenreader)" media feature [1] as part of IndieUI (where a privacy model is defined [2]) and would happily pass off that work to the CSS WG if the CSS MQ spec would add the ability to restrict access to certain media features. We discussed this last year in the CSS WG meeting at the 2013 TPAC in Shenzhen. Admittedly, I was remote and had trouble hearing some of the follow-up discussion.

It'd be problematic to offer an unprotected "(screenreader)" media feature because it would offer any web page the ability to detect with a high degree of certainty that a visitor has a particular physical disability. In my opinion, it would be a privacy an personal security nightmare to implement *unless* CSS were to implement a media feature privacy model similar to the one defined in IndieUI User Context.

Another problem with relying on media queries is that they would change the default rendering to an "accessibility only" mode. For example:

.new::before { content: "\2730"; }
@media (screenreader) { .new::before { content: attr(title); } }

The above CSS would visibly render the "New!" text instead of the star glyph designed for the visual UI. This is not desirable and could cause serious layout problems. Visible layout does affect screen readers that have spatial navigation modes, such as VO on iOS. The point of "alt" is to convey a text "alternative" to accessibility APIs; it is not intended to change the default visual rendering when an assistive technology is enabled. Any solution that changes the default visual rendering may represent a incomplete understanding of the problem space.

Thanks,
James

1. http://rawgit.com/w3c/indie-ui/master/src/indie-ui-context.html#userScreenReaderSettings
2. http://rawgit.com/w3c/indie-ui/master/src/indie-ui-context.html#privacy-model
Received on Thursday, 6 November 2014 19:54:19 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:26 UTC