Re: User Contexts: identifying assistive technologies

I understand the use-cases for a web site wanting to know that assistive
technology is running, and I fully support these.

However, what's the use case for wanting to know the exact screen reader
name and version? I think there's real danger that web sites would
customize their experience for the most widely-used screen reader
(currently JAWS) and ignore others. I don't think the occasional benefits
would outweigh the added complication to the API, or the

In addition, other uses of accessibility APIs are automation and search.
Any changes that a site makes to improve accessibility might be be helpful
to any application that automates the browser, and they might also be
helpful to a search engine that's crawling the page for relevant text and
annotations. (And yes, in case anyone's wondering, Google does execute
JavaScript when it crawls your page - this is nothing new.)

There's even a fine line between these - APIs that used to be only for
accessibility end up being useful for other things. Mac OS X calls
accessibility APIs when you three-finger-tap on a word to get its
definition. Windows 8 calls accessibility APIs when a control gets focused
to determine if that control should pop up the keyboard. Browsers show
"alt" text when you hover over an image.

I would prefer an API that simply exposes broad categories of accessibility
*features* that should be supported. If a user agent knows that
accessibility APIs are being called by some third-party, but it doesn't
know what the client is or what type of AT it is, it might return true for
all.

- Dominic