E-mail List Archives

Re: Longdesc implementations/alternatives?

for

From: John Foliot
Date: Jun 24, 2015 5:30PM


> PS - This is where John Foliot responds to defend longdesc. I know this
> because we've had this conversation already at least 20 times on this
> list. :-)

Or not.

The problem statement is that complex images need textual long descriptions.
How you provide that is dependent on a multitude of factors, including visual
and architectural design considerations.

For example, consider the following:

* providing a textual description directly below an info-graphic full of text
likely won't fly at many commercial websites: it's redundantly redundant. It
also adds a modicum of additional weight to the page for all users, as opposed
to a slimmer page that allows for the GET call of the longer text only when
requested by the end user. In today's age of minification and concern over
page weight (as related to mobile) this is a consideration to factor in.

* providing a text-based link on the page, adjacent to the complex image, may
not meet specific design criteria - design criteria that *can* be met using
other techniques. Standing hard on "we HAVE to make it a visible text link" in
scenarios like this is an expenditure of effort that has diminishing returns.

* making the complex image a direct link to the longer description may not
always work - what if the image is already reserved as a linking asset to
something else?

* Jared is correct, aria-describedby, when pointed to a text equivalent
(especially off-screen), will lose its structured mark-up, so that technique
is flawed as well (a major flaw with Ted's solution I believe).

This is by design BTW, as you really don't want html positioned off-screen or
out of sight - what would that do to tabbing and visible tab-focus (if/when
applicable)? These are both critical accessibility concerns as well, and so by
design browsers will flatten all off-screen text to "string-text" - no markup.
(This is also the same reason why you cannot use markup, such as <span
lang=""></span> in ALT text for images)

It also means that something like this:

<span id="long_description" style="display:none" aria-hidden="true">Text
description available <a href="">here</a></span>

...won't work, as the hyper-link will be flattened to string-text. Steve
Faulkner's post states:

"The ARIA attributes aria-labelledby and aria-describedby can be used to
provide an accessible name or accessible description for a subset of HTML
elements."
http://www.paciellogroup.com/blog/2015/05/short-note-on-aria-labelledby-and-aria-describedby/

Steve was accurate when he stated "a subset" - I will add that <img> is not
part of that subset for reasons explained here.

* Creating your graphic as an accessible SVG sounds great on paper, until you
try to do it consistently in a full-on production environment (where authoring
tools for accessible SVG haven't really progressed much beyond Notepad) -
besides, user-agent support for a technique like that is still not ubiquitous.


The debate over whether to use @longdesc or not is not a binary discussion.
Fighting for, and ultimately retaining @longdesc in HTML5 provided an
additional OPTION to the content author, one that should be chosen in context.
In my opinion, that was a fight worth fighting.

As a personal development decision, each developer needs to think about the
ramifications of all of the options before them, and choose as wisely as they
can. @longdesc is just a specialized way of linking one thing to another, and
ensuring that the link has a programmatic means of association, but it does
not preclude other techniques - nor should it.

For teachers and others who are leading the way, I am saddened when they
dismiss @longdesc as a potential option (of many), due in part to the years of
argument around the attribute during the development of HTML5, and a past
history of poor-to-non-existent browser support, while at the same time noting
that today all major screen-readers, except VoiceOver, provide robust support
for @longdesc; and that educational publishers such as Pearson are using
@longdesc to meet their legal obligation with regard to educational
text-books, publications already covered by existing copyright laws.

It's sad that the browsers have not yet gotten to the point where they are
providing visual support of longer text descriptions, for those with cognitive
issues who would also sometimes benefit from their inclusion, but I also know
that if/when it comes down to providing those longer descriptions to
non-sighted users only versus nobody, I'll choose the former - it isn't
perfect, but it at least addresses the largest impacted user-group

@longdesc is neither the *right* way nor the *wrong* way - it is simply *A*
way - one that has known flaws - yes, just like all the other potential
options on offer.

Today, as content authors, we have numerous imperfect ways of addressing the
problem statement, including the examples Robert noted. Dirk Ginader's example
(based upon an idea I asked him to work up) was one such, and others have
emerged since then. Joe Dolson took some of the ideas already floating out
there, added some slick CSS transitions to the mix, and developed a cool
WordPress plugin that refined the original idea Dirk and I discussed
way-back-when. (You can see it in action here:
http://openwebcamp.com/who-is-molly-holzschlag/ - scroll down to the "pull
quote" from Aaron Gustafson.)

Bottom line: you can be religious about a technique (for or against), or you
can engage your brain and provide a solution to the real problem with careful
thought and contemplation. That's what is most important to me.

Cheers!

JF
-----------------------------
John Foliot
Principle Accessibility Strategist - Deque Systems
W3C Contributor - Accessibility
Co-Founder, Open Web Camp





> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
> Behalf Of Jared Smith
> Sent: Wednesday, June 24, 2015 8:42 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Longdesc implementations/alternatives?
>
> I think the best approach to complex images is to either place the long
> description in context (perhaps a data table immediately after the
> image) or to provide a link to a long description page.
>
> While there is minimal support for longdesc, it is still almost
> entirely screen reader specific. Long description pages can be helpful
> to all users, so efforts should be taken to make them easily presented
> to all users. A link is the best way to do this.
>
> The primary issue with using aria-describedby is that any structure in
> the referenced element is lost - it is read as a stream of text. On
> your example page, all of the headings, lists, etc. are lost when read
> in conjunction with the image. This also means that the screen reader
> user can't navigate or control reading within the description. They
> can't pause and start reading where they left off, for example. And
> because long descriptions are, by definition, long, this can pose
> significant issues. Also, if the referenced element is hidden, it may
> not be read at all - http://www.paciellogroup.com/blog/2015/05/short-
> note-on-aria-labelledby-and-aria-describedby/
>
> Personally, I've never used or recommended longdesc. It does not
> provide any benefit over a standard link to the long description page.
>
> Jared
>
> PS - This is where John Foliot responds to defend longdesc. I know this
> because we've had this conversation already at least 20 times on this
> list. :-) > > archives at http://webaim.org/discussion/archives
>