Re: [user-context] What are the use cases for exposing screen reader or magnifier version info?

Sent from my iPad

On Feb 5, 2013, at 2:16 AM, "Dominic Mazzoni" <dmazzoni@google.com> wrote:

> On Mon, Feb 4, 2013 at 3:39 PM, Richard Schwerdtfeger <schwer@us.ibm.com> wrote:
>> ok. I see these issues:
>> 
>> - accessibility test tools don't analyze CSS so this is a big hit for accessibility checkers.
>> - we need to train accessibility testers
> 
> To clarify, I don't anticipate either of these being affected. The browser would be the one mapping CSS to elements, and it would expose the ARIA roles, states and properties via the native accessibility APIs exactly as if the attributes were on the elements. So native tools and testers would not be affected.
> 

Web developers use accessibility test tools that access the DOM. They are not platform accessibility experts and we can't expect them to be.

> - what will trigger the state changes. 
> 
> Up to the web developer how to trigger them, exactly as now. Browsers are already heavily optimized for applying style changes to thousands of elements quickly, we'd be leveraging that work.
>  
>> - this is a hit when we are trying to do aria 1.1, finish aria 1.0, SVG access, html5 access, aria 1.0 cr, indie UI events and context
> 
>> So, I have concerns over priorities. When you look at these far more important items needing completion I think this could wait although I see some benefits.
>> 
>> Accessible Analytics for big data is a big hole we need to fill ... SVG and canvas.
> 
> I threw out the idea because it seemed relevant to the initial question in this thread (exposing information about AT to web apps), then we ended up on a tangent. I don't think it's higher priority than any of the other work you mentioned, but I do think performance is a concern and one that shouldn't be ignored.
> 
>> I would recommend synching what you are suggesting with aria 2 work.
> 
> Agreed, that sounds like a good home for this idea.

ok
> 
> - Dominic
>