RE: 48-Hour Consensus Call: InstateLongdesc CP Update

Silvia Pfeiffer wrote:
> 
> you can't have it both ways:

Ah, but with @longdesc I do. Today.

I encourage you to go look at Dirk's example I've posted - by exposing the
linked content (using @longdesc to do the linking) then the long description
does indeed render an exposed, tab-focusable link. (here's the link:
http://blog.ginader.de/dev/jquery/longdesc/examples/webaim/index.php) 

> 
> Either it is visible content, then it is created by Web Devs to be
> visible and thus also accessible.
> 
> Or it is accessibility content, then it is not visible to anything but
> AT.

OK, so I must reject that binary position, on a number of grounds:

1) All AT are not screen readers (and I've pointed that out numerous times
as well - please be accurate in describing what you want, or believe you
want), as well, not all screen readers support ARIA.

2) Some tools, such as ZoomText are both screen readers and screen
magnifiers - how and what are they supposed to do when there is a link
behind an image? It's read aloud, but not visibly seen - wow, I can see some
possible security problems there (click-jacking)...

3) Not all users who will benefit from a longer textual description  will be
using a screen reader (or any AT for that matter) - both Chaals and David
Singer have presented credible and real user-profiles that illustrate that
amply.

4) ARIA attributes do not have UI actions prescribed to them - in fact David
Bolter of Mozilla has written on behalf of the idea that ARIA should remain
that way. The aria-label, aria-labelledby and aria-describedby attributes
today provide the accessible name and accessible description to screen
readers without any user interaction, it just comes, and unless we
collectively decide that aria-* attributes can (and should under certain
circumstances) prescribe UI actions it is going to limit the usefulness of
any specific aria solution. (I note that in this regard, Chaals and David B.
are in opposite thinking).  I will also suggest that force-feeding longer
textual descriptions that users must halt (rather than request) is a poor
user-experience. 


> That the content in the document that you are referencing from
> @longdesc can be both, does not mean that it will be both through a
> single attribute. If our main use case is accessibility - as I
> understand it is - then the second use case is the important one and
> we need an a11y attribute (preferably an @aria-attribute).

No, we need a solution that has a certain amount of Universality to it -
crafting tool-specific solutions to problems that transcend a specific set
of users is a horrible design pattern (in my opinion).

To be crystal clear and respectfully frank, this is for more than just for
blind users: always has been and always will be. The fact that non-sighted
users today (who can choose between at least 2 browsers and 3 screen readers
- more actually) have a leg up on other users who could benefit from longer
textual descriptions is not something we should be entrenching into HTML,
but rather actively seeking to overcome.


> In this
> case we can encourage the Web Dev to further also expose the document
> visibly through other markup means. I think this is the only realistic
> way of solving this double use case.

...or get real user-agent support for @longdesc, which today can solve the
use-case for both sighted and non-sighted users, using different but
appropriate methodologies. Creating silo solutions is not the way to go
forward, nor is six different scenario-specific authoring solutions that
address some but not all use-cases (differently).

JF

Received on Tuesday, 25 September 2012 04:25:36 UTC