W3C home > Mailing lists > Public > public-indie-ui@w3.org > December 2012

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

From: James Craig <jcraig@apple.com>
Date: Thu, 06 Dec 2012 17:20:11 -0800
Cc: public-indie-ui <public-indie-ui@w3.org>
Message-id: <A3DDE862-5F9B-4307-9307-9EF92E4F0A47@apple.com>
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
On Oct 22, 2012, at 5:40 AM, Lachlan Hunt <lachlan.hunt@lachy.id.au> wrote:

> The user context draft exposes properties for obtaining the name and version information relating to both screen reader and magnifier software that a user may be using.  Although the spec attempts to consider privacy issues relating to these, what is the actual use case for exposing this potentially sensitive information at all?

Hi Lachlan,

Ideally it would not be needed (and in most cases I expect it will not be used), just as ideally, no one would ever have to check the user agent string or version. That said, assistive technology user interfaces and feature support vary even more widely than web rendering engines. For example:

1. Bug workarounds example: The current version of Window Eyes screen reader does not support as much of the ARIA spec as the other main screen readers on Windows: JAWS and NVDA. There's no way to use object detection to determine the differences, and the user agents expose the same information in either case. Working accessibility support isn't just a nice-to-have enhancement for the people that need it, so sometimes content authors need the ability to work around known bugs.

2. Interface difference example: Windows-style screen readers usually intercept and change the default behavior of Tab and other keyboard keys, so full keyboard navigation does not work as a page author may normally expect it to. ARIA attempts to solves some of this, but only on subtrees of certain defined interfaces (like the application role), and certain screen readers (e.g. JAWS 11 and later, I think) ignore that portion of the spec and do their own thing anyway. VoiceOver on OS X uses a very different interface from most Windows-style screen readers, and does not intercept or modify standard Tab navigation. I'm not listing these differences to claim that one is "right" or "wrong" but merely to illustrate the differences between them for which web authors sometimes have to account.

Assistive technology vendors are not beholden to W3C specifications (and most AT vendors are notoriously uninvolved in the standardization process), so exposing this information when it's absolutely necessary, (and only with user content), is one attempt to reduce the unreliability of AT interfaces on the Web.


PS. Sorry for the severely overdue response.
Received on Friday, 7 December 2012 01:20:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:09:15 UTC