RE: ISSUE 30 @longdesc use cases

Jonas Sicking wrote:
> You can even support older UAs which doesn't support the
> 'hidden' attribute using CSS or simply adding a style="display:none;"
> attribute.

Hi Jonas,

FYI, both the @hidden attribute and "display:none;" hides content from
screen-readers as well. Whether or not this is appropriate behaviour for a
screen reader has been discussed before at great length, but regardless of
which side of that discussion you come down on, as the browser folk keep
reminding us, the implementation behaviour is the one that counts today,
and that's what screen readers do at this time. (In the case of @hidden,
this is in fact the behavior that is described in the spec:)

	"When specified on an element, it (@hidden) indicates that the
element is not yet, or is no longer, relevant. User agents should not
render elements that have the hidden attribute specified." [1]

So the longer description is not "relevant"? Hmmm.... (I'm positive Jonas
that this is not what you actually want)

The real problem with out-right removing a perfectly valid but under-used
part of HTML (whether an element or attribute) today is that there are
ripple effects that the simple engineering decision affects that fall
outside of the direct engineering decision. Deprecating @longdesc (or as
it is structured in HTML5, conforming but with an advisory) would have
allowed a graceful longer-tail exit strategy (if one assumes that
@longdesc is fatally flawed - and many do not even accept that). That is
also why it was the second (lesser preferred but accepted) option that the
Accessibility Task Force put forth [2] (yet the Chairs suggested that this
was the least preferred option - despite the fact that it is already the
option and behaviour for @summary... [3][4]).  The current decision simply
removes things immediately, and leave the fall-out to somebody else to
clean up - a situation that is *extremely* objectionable to many.

Rest assured, this is not resolved yet by any stretch of the imagination. 

The flip-side question is: 

Why is it so difficult for today's browsers to provide the attribute
support for all users? Is it really that hard for Mozilla to go from
showing the URL of a long description link in the right-click context
menu, to actually making it a workable/serviceable link for all users?
Nobody has adequately explained why browsers today (outside of Opera and
iCab) have not supported this now decade-old attribute in any useful way
(an attribute BTW, that remains conformant and valid in HTML 4/XHTML 1
today). Why must the accessibility community find work-around solutions
for browser failures? What happened to users over authors over
implementers over technical purity? It seems that removing the attribute
is a technically pure solution to a perceived problem, but it only solves
one problem, and even then the problem it solves is not the bigger problem
but rather a detail of the larger issue: complex images require complex
descriptions for those users who cannot see or otherwise grasp what the
image is seeking to convey, and to date most web authors have simply not
provided that longer description - in page, off page, anywhere. 

The quality of the longer description is the real problem, not the method
that we use to link it to any given image: in this regard @longdesc is
actually quite elegant, as it makes the link a direct attribute of the
image asset (as opposed to creating an association to an external link
that then goes to the same longer description) - as well, @longdesc
*today* can point to both URI's *OR* IDREF's (if authors really believe
that in-page descriptions are better - a point still debated [5]), whilst
aria-described by is limited to IDREFs at this time. However neither
solution ensures that the data at the other end of the link is valid or
valuable, which is the larger issue. Killing off @longdesc simply shoots
the better messenger first.



Received on Monday, 23 August 2010 18:03:25 UTC