RE: example spec text for longdesc

Steve Faulkner wrote:
>
> (Matt Turley wrote:)
> > The drawback of including an attribute specifically for the purpose of
> > hiding accessibility
>
> it is not intended that longdesc will 'hide accessibility' in fact it is
> the opposite as I have attempted to articulate in the example spec text
> [1].
> Of course browser vendors cannot be forced to expose longdesc in a
device
> independent way, just as they cannot be forced to expose title attribute
> content in a device independent way, but authors can work around browser
> support issues.

Indeed. This is, in fact, the crux of the problem: GUI browsers today do
not natively provide an indication to sighted users that @longdesc content
exists when used in a document. The majority of screen readers *do*
announce the presence of @longdesc content, after which the user can
follow that link, or choose not to. But for sighted users, at this time no
browser has an obvious, 'in your face' indication that a longer
description exists on a complex image. Which begs the question: who is
doing the disservice to users here - the specification or the GUI
browsers?

It would be fairly safe to say that all those in favor of retaining
@longdesc agree that for maximum usefulness, a visual indication to those
sighted users who desire longer textual descriptions should exist.
However, using the 80/20 rule we currently have a situation where for the
majority user-group (non-sighted users who desire longer descriptions) we
have user-agents that provide this support: for the remaining 20% we have
solutions that can be addressed via scripting. And in fact, we have
exactly that today: browser plug-ins that afford sighted users the ability
to access longer descriptions [1], plug-ins that place a visible icon in
the browser chrome [2], and a jQuery module that use a combination of XHR
and in-page rendering (complete with an unobtrusive icon) that allows
sighted users to read the longer description [3]. 

Should browsers do more natively? Without a doubt. But can HTML5 *force*
them to do more? Highly unlikely - we can get, at best, SHOULD language
into the specification, but not MUST language.

[1 - Firefox plugin:
https://addons.mozilla.org/en-us/firefox/addon/longdesc/] 
[2 - Opera browser extension:
https://addons.opera.com/addons/extensions/details/tellmemore/1.2/] 
[3 - jQuery module: https://github.com/ginader/Accessible-Longdesc] 


> > How does a user know they can right-click and select Long Description?

It has long been asserted that a/some/many/all users need access to the
longer textual description. Yet no proof has been submitted that this is
indeed a fact.

If a sighted user knows that they will be needing/wanting to have longer
textual descriptions, then they will choose to use a browser or
browser/plug-in combination that affords them that option. Please let's
stop assuming that users are idiots and have no idea what they need/want.
If I need a screen magnification mechanism, I get the appropriate tool to
afford me that accommodation. If sighted authors (a sub-set of all users)
want to have a mechanism that allows them to see the presence of @longdesc
on legacy content they once authored (because, for some reason, after
going to the effort of creating longer textual descriptions in the first
place they "forget" about them), then the tools exist for them as well:
from native DOM inspectors in the browsers to the aforementioned plug-in
solutions.


> > Is it acceptable to deny access to users who don't know this access
> > method exists? Does longdesc in this scenario meet WCAG2's guiding
> > principles for being Perceivable, Operable, Understandable and Robust?

PERCEIVABLE:
It is perceivable, it's just that current GUI browsers do nothing with it:
screen readers 'perceive' it and...

OPERABLE:
...provide a device independent means of accessing the content, while not
disrupting the normal page-flow of the containing image/longdesc. 

UNDERSTANDABLE:
The requirement here is that it is clear what to do when you encounter
@longdesc. In screen readers, you are given the option of following a
link, or not following. That seems to meet the test of understandable -
following links is a core web function/operation. In the visual instances
we have, the contextual menu is where the option to follow the link is
presented (Opera, Firefox via the plugin, Internet Explorer -
http://blogs.msdn.com/b/accessibility/archive/2011/03/25/configuring-inter
net-explorer-to-handle-longdesc.aspx) - once again, this builds on common
and known interaction models that users are familiar with using. FWIW, in
conversation with the developers of NVDA (one of a few screen readers yet
to support @longdesc) at CSUN this year, they agreed with this approach,
and suggested that moving forward if this was the interaction model
adopted by browsers it would be their preferred model to support. (I
cannot provide proof of this conversation, but encourage anyone who wishes
to question this statement to approach Jamie and Michael directly and ask
them - I can provide email addresses off-list if you wish.)

ROBUST:
WCAG 2.0 here states: "Content must be robust enough that it can be
interpreted reliably by a wide variety of user agents, including assistive
technologies." - I believe that the combination of multiple screen
readers, along with plug-in/scripted solutions for multiple GUI browsers
today can allow us to conclude that this requirement is being met.


> >
> > Are there any circumstances where using a normal link instead of
> > longdesc would not lead to an immediate, significant improvement in
> > accessibility/usability?

This is the wrong question to be asking - of course what Matt asserts is
true. However, the correct question to be asking is "Are there any
circumstances when page authors will want to avoid placing a visible link
to a longer description on their page?" Laura Carlson's collection of
use-cases, along with statements from creators such as Kyle Weems
(CSSquirrel) establish that the answer to this question is 'yes'. In these
cases, what is the fall-back solution? @longdesc here serves a useful
option - not *THE* option, but *AN* option.


> >
> > There will be authors who want to use hidden links to long
> > descriptions.

Nobody is forcing Matt or any other author to make this choice. @longdesc
is not a mandatory requirement, it is a possible solution that mitigates
harm, while still addressing other author/content owner requirements.


> >
> > The fundamental question is whether we want to encourage authors to
> > use an accessibility technique that is hidden by design, by including
> > a specific attribute in the language for this purpose.

THE ENTIRE REASON FOR THE CREATION OF @LONGDESC IN THE FIRST PLACE WAS
THAT AUTHORS WANTED A MEANS TO ENSURE LONGER DESCRIPTIONS COULD BE
PROVIDED *WITHOUT* HAVING A VISUAL INCUMBERANCE ON THEIR PAGE - LONGDESC
WAS DEVELOPED TO ADDRESS DESIGNER NEEDS, BASED ON DESIGNER FEEDBACK!

> > Or whether we want to discourage hidden accessibility (but still
> > optionally support it via CSS positioning off screen,

It is unclear to me how content positioned off screen is perceivable to
sighted users. Placing that content off-screen, then linking to it via
ARIA attributes goes in the wrong directions, as ARIA is designed for
Adaptive Technology:

	"ARIA is intended to only affect accessibility API mappings (and
thus ATs). Features such as alt="", however, are relevant far beyond AT
users, for example to text browsers. It would be wrong, therefore, to make
solutions that exclusively affect accessibility APIs be a suitable
alternative for solutions that are necessary for UAs that do not use
accessibility APIs."
- Ian Hickson
http://lists.w3.org/Archives/Public/www-archive/2010Mar/0029.html 


> >
> > The drawback of including an attribute specifically for the purpose of
> > hiding accessibility is that authors will use the technique because
> > they think it is "for accessibility",

It is. It is also a good Universal Design technique, where the image
creator ensures that textual descriptions can be associated to their
complex images for those who cannot perceive the image as the creator
envisioned.


> > rather than a last resort.

Unsubstantiated assertion.


> > The
> > best way to make something accessible is to make it obvious and
> > available to all, and this is what we should be encouraging authors to
> > do via the conformance rules in HTML5.

This is a misuse of conformance checkers. Besides, as Jonas Sicking of
Mozilla stated:

	"A terrifyingly small percentage of the pages on the web pass a
validator. The far vast majority of pages doesn't even nest their tags
correctly. The sad truth is that while we can do what you suggest, it's
not going to have a big effect because people simply doesn't consult
validators to a large degree."
http://lists.w3.org/Archives/Public/public-html/2011Mar/0627.html 


JF

Received on Monday, 4 April 2011 18:51:14 UTC