Re: CSS issue: Need control of what is perceived by which technologies

Please note that this list is for discussion of “what the CSS spec should be” which is usually several steps ahead of “what CSS can I use *today* to solve problem X.” 

Even though your request can’t be done in a browser today, the best way to get something into a rendering engine is to file a bug, and potentially contribute a patch, and the best way to get something into the CSS spec is to discuss it here.

Also, since you mentioned not knowing of any screen reader that uses CSS 3 Speech, VoiceOver on iOS supports at least some of it. The values of the speak property: literal-punctuation, digits, etc. come to mind, and there was a demo in the WWDC 2011 video, “Combining Accessibility and Automation on iOS” which should be available as a free download—mobile now, or I’d include a link.

Note: This support was added about a month before speak was split into two properties: speak and speak-as. I found it surprising that the 2011 draft would change it so drastically, especially considering there had not been an updated draft since 2004.


On Dec 7, 2012, at 5:57 AM, Antony Kennedy <antony@silversquid.com> wrote:

>>> If this were true, then "speech" media would be completely useless.  I
>>> believe browsers can tell when a page is being read by AT, and can
>>> provide customized information for it.  (I could be wrong, though...)
> 
> 
> At the moment, the "speech" media *is* completely useless. I don't know of a single ScreenReader that pays attention to it. Am I mistaken?
> 
> If so, please let me know how I can achieve what I'm after with a real world example.
> 
> On 26 Nov 2012, at 20:08, James Craig <jcraig@apple.com> wrote:
> 
>> On Nov 26, 2012, at 10:01 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> 
>>> On Mon, Nov 19, 2012 at 2:58 AM, Antony Kennedy <antony@silversquid.com> wrote:
>>>> Is this something that can be sensibly achieved with media queries?  @media
>>>> not speech and  @media speech seem like they should work great here.
>>>> However, the screen reader attaches to the output of the browser (what the
>>>> browser sends via Operating System APIs) and not the browser itself, so when
>>>> the browser is parsing the CSS it never understands to expose or not expose
>>>> these pieces. aria attributes work correctly here though, so there must be a
>>>> solution!
>>> 
>>> If this were true, then "speech" media would be completely useless.  I
>>> believe browsers can tell when a page is being read by AT, and can
>>> provide customized information for it.  (I could be wrong, though...)
>> 
>> 
>> AT is a broad term and browsers cannot detect all forms, though providing customized information on a per-AT case is usually unnecessary. 
>> 
>> I don't think a new "perceivable" property is necessary here, because I believe the @media type query fits well here:
>> 
>>    element::before { content: ":"; }
>>    @media speech or reader { element::before { content: ""; } }
>> 
>> In this case, the UA should just not expose the text contents of the pseudo-element to the accessibility API, or mark it in the API as decorative or otherwise hidden.
>> 
>> I think what Antony is requesting is that the CSS spec should state something explicit to that effect.
>> 
>> James
>

Received on Friday, 7 December 2012 16:49:59 UTC