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

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.

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

- Dominic