RE: FW: [NVDA] #809: Support for longdesc in web browsers

Silvia Pfeiffer wrote:
>
> I make no such assumption. But I make the assumption
> that any information provided to a screenreader is likely
> to target more than blind users, including such users as
> you point out and that therefore there are technologies
> that make use of the same APIs and information that
> screenreaders make use of.

You see, this is where there seems to be a disconnect: the Accessibility
APIs are for those technologies that require that abstraction layer, but not
every user needs to use that same abstraction layer. 

Users with cognitive disabilities (for example), may not actually be using a
tool or tool-stack that includes a tool that uses the AAPIs - they may very
well just be surfing the web with nothing more than a browser and standard
OS. For example, in a different vein, a dyslexic user could over-ride author
style-sheets to *always* set the background color to cream (versus white),
as that lower contrast will reduce the "dancing letters" that black text on
a white background often produces. There is nothing with this strategy that
involves the Accessibility APIs.

Sticking all accessibility support into a box marked "AAPI users only" is a
backward step (not to mention having a faint whiff of segregation), and
either ascribes magical properties to those APIs, or ignores a significant
segment of the population - unless of course you are suggesting that the
browsers provide native interaction support to those APIs, which currently
the do not (Safari/VoiceOver coming closest to that). 

Allow me to quote from James Teh, one of the developers of NVDA:

	"NVDASR now directly supports #longdesc, primarily because most
browsers don't support it properly even though they should. In IE, we use
the DOM. IE doesn't expose anything related to longdesc to a11y APIs.
Firefox kinda supports longdesc, but only via APIs. It doesn't expose it to
non-AT users, which imo is silly." -
https://twitter.com/jcsteh/status/266685342025932800 


It's those non-AT users that James, Laura Carlson, myself and whole raft of
others are concerned about. If there is one key point to be learned here, it
is that currently today, the Accessibility APIs are used almost exclusively
by Assistive Technologies, but not all Persons With Disabilities (PWT, which
is a cleaner expression than Accessibility Users) use Assistive
Technologies. Relying exclusively on the AAPIs excludes those users! Please
do not lose sight of this critical fact.


> Again, I make no such claim. My claim is that where Web
> developers see such descriptions being useful to more than
> accessibility users, they will make it visible on the site.

But again, this presumes that those developers will be able to determine
what each individual user will need or want, which I feel is unrealistic.
Those developers may grok that a long description is required for
non-sighted users, but may not also understand that other, sighted users,
may also want that description. As an analogy, it is similar to saying that
everybody *may* want closed captions (so we will make showing/hiding them
part of the browser behavior), but only blind users would want descriptive
audio/descriptive text (so we will only expose that content stream to users
of Assistive Technology) - it is a leap that I can't make, and think you
would be hard to defend.


> In fact, I'd like to encourage them to do so. The thing is:
> in both cases it is important that accessibility users are
> able to discover the availability of that data and that's
> what the attribute is for.

And here we are in partial agreement, the question is, how do we make this
discoverability available to all users, and not just those users that are
using Assistive Technology? I disagree that the AAPIs is or should be the
only way to do so - that the discoverability should be available to any and
all user(s).

JF

Received on Friday, 9 November 2012 19:16:52 UTC