W3C home > Mailing lists > Public > public-html@w3.org > March 2011

RE: example spec text for longdesc

From: John Foliot <jfoliot@stanford.edu>
Date: Fri, 25 Mar 2011 19:21:27 -0700 (PDT)
To: "'Jonas Sicking'" <jonas@sicking.cc>, "'Laura Carlson'" <laura.lee.carlson@gmail.com>
Cc: "'Henri Sivonen'" <hsivonen@iki.fi>, "'HTMLWG WG'" <public-html@w3.org>
Message-ID: <010501cbeb5c$82ce5530$886aff90$@edu>
Jonas Sicking wrote:
> First of all it has always surprised me that the list of use cases
> only list discusses adding accessibility information to images. Is
> there a reason things like tables, SVG (and portions thereof), figures
> and forms are left out?

Thanks for the good questions Jonas. I appreciate the fact that there is
ongoing dialog about @longdesc as we collectively seek to make a better
web for all. 

In actual fact, @longdesc as specified in HTML4 can be added to both <img>
and frames/iframes: 
	"This attribute specifies a link to a long description of the
image. This description should supplement the short description provided
using the alt attribute."
	"This attribute specifies a link to a long description of the
frame. This description should supplement the short description provided
using the title attribute, and may be particularly useful for non-visual
user agents."

Equivalent 'description' functionality for tables is supplied by @summary:

	"This attribute provides a summary of the table's purpose and
structure for user agents rendering to non-visual media such as speech and

SVG uses a slightly different approach, with the <title>/<desc> elements: 
	"The combination of the hierarchy and alternative equivalents can
help a user who cannot see to create a rough mental model of an image."

Figure is new to HTML5, and could conceivably also take the @longdesc
attribute, once we get @longdesc reinstated into HTML5 as a conforming
attribute. Should I file the bug, or will you? <smile>

> Technically, wouldn't you even want to be able
> to have a long description for a part of a web page that contains a
> fairly complicated piece of UI?

Yes. See above.

> Also, ease of use seems to be missing from that page.

Can you elaborate more on what you mean by "ease of use"? 

In the user-agents primarily targeted by @longdesc, the majority of screen
readers announce the presence of a longer description (with no user
intervention) immediately after announcing the value of @alt, at that
point however the end user is presented with the choice of pursuing the
longer description, or skipping past it - a key consideration. Choosing to
follow a link is pretty easy. <grin>

In the few visual instances we have today, the link to the longer
description is presented to the user in the contextual menu (this is
native in Opera, and what the Firefox plug-in currently does today). In
talking about this issue at both the SxSW and CSUN conferences earlier
this month, there seemed *to me* to be a general consensus that this is
both useful and appropriate behavior/rendering. Specifically, the
developers of NVDA agreed that this was what they envisioned as a right
way forward, and should this be added to Firefox (for example) they could
happily support it in NVDA. Earlier today, Sean Hayes (Microsoft) posted a
MSDN blog on how to extend similar functionality to Internet Explorer
rnet-explorer-to-handle-longdesc.aspx) so it seems that there is also a
conversion around a standard activation mechanism for sighted users - the
contextual menu. I think this is a Good Thing(TM).

The one missing piece today is finding a way to signal to sighted users
that they can actually access something useful from their contextual menu
when images have longer descriptions (in other words, in-document

Since one of the design goals of @longdesc was to provide a specific
functionality *without* having a visual impact on the authored page (the
dreaded and shunned "D" link), we have a fairly serious conflict of
requirements. However, it seems to me that placing an icon or other
indicator in the browser chrome would be a workable compromise, one in
fact that Chaals McCathieNevile has illustrated with his recent Opera
(https://addons.opera.com/addons/extensions/details/tellmemore/1.2/). I am
talking with another developer to take this model and create a Chrome
extension as well, and once Patrick Lauke comes up for air, he agreed to
look at adding something similar to his existing Firefox plug-in.

Other suggestions on how to more easily address these conflicting
requirements are welcome.

> Once you include these use cases and requirements it seems much less
> that longdesc is a proper solution. It's only available on <img>ages
> (this missing all other ways even for including images such as
> <canvas> and <object>).

I see no reason why it cannot be an attribute for these elements as well:
we are writing a new spec, so we can certainly add this to the spec -
there is still lots that needs to be done with <canvas> today to ensure
accessibility, so let's include <canvas> as an element that the @longdesc
attribute can be added to. (Show of hands?)

> It isn't very user friendly.

How so?

> Lots of people
> seem to misunderstand it to include the actual describing text rather
> than a link to it.

Jonas, the web of 1997 is very different than the web of 2011. The
majority of web developers today do not hand-code their sites, even if
many members of this mailing list still do. WYSIWYG editors have pretty
much solved this problem years ago by indicating to the author a "browser
for the file" function when adding @longdesc to complex images.

Finally, as the March 11 email to the Chairs from Geoff Freed indicates
professional content producers (such as those involved in the ePub
initiative, or the US federally funded DIAGRAM Project) are interested and
ready to use @longdesc to meet their own existing requirements. I
personally have faith that should they start using @longdesc, they will do
so properly and accurately, greatly increasing the pool of useful and well
constructed @longdesc descriptions. (Is it important to note that these
authors are primarily interested in richly structured documents, and *NOT*
web-app development?)

For these reasons, I must discard your assertion here; we have ample
evidence to suggest that this is not going to be a problem moving forward.

> Not only that, but since it is url based, rather
> than id based, it encourages people to put the description in an
> external resource, which more often than not is not what you want to
> do.

Can you back that assertion with proof? 

In fact, one of the use-cases presented, "Describing a Logo"
(http://www.d.umn.edu/~lcarlson/research/ld.html#uc-01) having the longer
description as one page, with multiple pages pointing to that same
resource *is* the use-case. (Content authors would agree with this, this
being after all a Best Practice for both JavaScript and CSS today - write
it once and share it across all documents.) Having @longdesc capable of
pointing to an external URL is in fact also the reason why
aria-describedby cannot alone solve the problem statement. 

The second use-case, "Describing a Cartoon"
(http://www.d.umn.edu/~lcarlson/research/ld.html#uc-02) is another
instance where the artist does not want in-page text interfering with the
visual rendering of the page; it makes little sense to recreate the dialog
of a series of cartoon speech bubbles directly after the cartoon from a
visual/design perspective. In these cases, we simply will not get what we
need, as the 'design' of the artist in this instance will always trump the
'data' requirements if those requirements become too onerous. 

> It turns out that ARIA already have a attribute that almost fits the
> bill, and this is aria-describedby. As is pointed out on the wiki
> page, the problem is that the ARIA specification only allows exposing
> text content to the user, rather than arbitrary content, such as
> links.

Actually, the problems are more serious than that. As you note, the text
value of aria-describedby cannot be semantically structured; no lists, no
tables, etc. In the case of a complex pie chart, the best way of
'textualizing' the image would likely be via a table. Aria-describedby
cannot do this.

As well, as implemented today, the value string of the @aria-describedby
attribute is immediately read aloud by consuming technology (screen
readers): there is no end-user choice to listen to it or not. This could
actually lead to a very degraded experience for non-sighted users; again
it is not the optimum choice. (I will concede that we might want to talk
to screen reader vendors about this as well)

Finally, we must remember that ARIA is and always has been considered a
bridging technology until "native semantics" provided the required
functionality, a point that was made in the prevailing Change Proposal you
and I both contributed to:
http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements (At the
writing of that Change Proposal you did not indicate that you disagreed
with that statement, and I hope you've not changed your mind on that now.)

Why-ever then would we remove a native attribute (@longdesc) and replace
it with a bridging solution? Seems like backward movement to me.

> This problem can be fixed though by changing the ARIA specification.
> By changing ARIA to say that aria-describedby can point to arbitrary
> content, rather than just refer to the textual contents of it, we
> solve multiple problems in one go.

Not really. In fact, there have been a few high-level thought discussions
about introducing a new aria attribute in a future ARIA dot Next version
that would better solve the problem (rather than attempting to re-work a
functioning attribute). However, when you spec out the requirements, it
looks and feels *JUST LIKE* @longdesc. None-the-less, should HTML5 not
retain @longdesc, it is a possible strategy to implement needed
functionality from outside of the actual HTML5 specification - we could
simply back-door @longdesc functionality (called something else) via ARIA.
Seems kind of silly and childish to me (not to mention breaking backward
compatibility) - we should admit that @longdesc serves a function, that
retaining it in HTML5 causes no harm and adds benefit, and move on.

> This would first of all allow aria-describedby to solve all the use
> cases in the wiki, as well as the ones pointed out in this message. It
> also seems to fulfill the ease of use requirement better as people so
> far seems to put an id in aria-describedby rather than the actual
> text.
> Additionally, it improves aria-describedby which currently IMHO
> suffers both from ease of use problems, as well as
> internationalization problems. It is very unintuitive to me that
> aria-describedby points to an element, which can contain arbitrary
> semantics, but then discards these semantics and only uses the
> elements textual content. Additionally, some locales, such as
> japanese, commonly uses markup, for example ruby, to expose important
> semantics. aria-describedby currently drops these which seems like a
> problem.

All of the problems described here can be solved by @longdesc today by
simply making it conformant in HTML5 (and maybe getting the browsers to do
something useful with it). @longdesc can point to an IDREF as well as an
URI which could/would be a semantically structured page that could support
ruby, tables, lists, hyperlinks and more. You are instead suggesting that
we re-invent the wheel by modifying ARIA attributes very late in the ARIA
Recommendation Process (and not as comments to the ARIA WG, but rather
here in the HTML WG).  

(I have also heard that "opening a new page/tab" is poor usability. If I
am to accept that, then what to do? Perhaps something like what Dirk did
here: http://blog.ginader.de/dev/jquery/longdesc/examples/webaim/index.php
- see the iFrame example, and it's use of XHR a.k.a. AJAX. Some people see
'broken', I see challenges, and thank Dirk for implementing my
proof-of-concept idea.)

> And yes, I am aware that the wiki claims that aria-describedby has
> other problems. I'll deal with those if we can agree that this aspect
> of aria-describedby can be fixed.

Jonas, aria-describedby is not broken. It does what it was designed to do,
and it was never designed to replace native functionality we've already
had since 1999 (with @longdesc).

> So, if we really want to focus on creating the best possible technical
> solution for helping AT users, rather than focusing on restoring any
> and all accessibility feature for HTML4 at all cost, then I think
> there clearly are better solutions than longdesc.

I'd flip that around and suggest that if @longdesc continues to have
problems, we should own those problems and fix them. That is what was done
with <b> and <i> previously (where new 'semantics' were added to what
initially were presentational elements), and frankly the only real problem
that remains with robust support of @longdesc is that the mainstream
browsers fail to do anything useful with @longdesc, fobbing it off on AT
tools or plug-ins. 

(And if plug-ins is the way to go, so be it: the browsers need not do
anything more than let HTML5 move forward with @longdesc being conformant.
Cost to browsers? $0.00. Benefit to users and concerned content authors?
Immeasurable. I would prefer that browsers however worked towards better
results: invest the little time and effort it takes to get this right.)

If we are to believe the design goals and principles of HTML5:

* evolution, not revolution
* users, over authors, over implementers, over code purity
* paving cowpaths

...then the only logical conclusion that can be reached is that we need to
tighten up on @longdesc, and not seek to re-invent the wheel here.  As a
member of one of the browser teams on this list, I challenge you to go
back to your developers and look to find a good solution to support an
attribute that has been with us for over a decade.

This really shouldn't be so hard or complicated.

Received on Saturday, 26 March 2011 02:22:04 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:11 UTC