E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 5 (In chronological order)

From: Robert Fentress
Date: Wed, Jun 24 2015 9:13AM
Subject: Longdesc implementations/alternatives?
No previous message | Next message →

Is longdesc something folks are using at this point? I've read the support
for it has improved
<http://www.karlgroves.com/2014/08/26/longdesc-where-are-the-alternatives/>;,
but I had been recommending, instead, that people add the attribute
aria-describedby to the image
<http://www.last-child.com/accessible-infographics/infographics-aria-describedby/>;,
with the attribute's value referencing the id of an element with
aria-hidden="true" applied to it.

In Karl Grove's piece linked to above, I ran across these examples of ways
to make longdesc work more consistently and expose the information it
provides to other users (especially those with cognitive disabilities):

- Dirk Ginader's jQuery Accessible Longdesc Plugin
<https://github.com/ginader/Accessible-Longdesc>
- Steve Faulkner's Flipbox web component
<http://rawgit.com/stevefaulkner/flipbox/master/demo/testpage.html>;
- James Craig's iFrame example <http://cookiecrook.com/longdesc/iframe/>;

One thing I noticed from all of these is that they replace the image with
the text alternative, which, if intended to help individuals with cognitive
disabilities better understand the content being presented, seems
sub-optimal. Better, I would think, would be to trigger a movable dialog
or popover that contains the text. That way, the user could see the image
and read the text, comparing the two.

Do you know of anyone who has taken this approach? Do you have a better
one?

Best,
Rob

--
Robert Fentress
Senior Accessibility Solutions Designer
540.231.1255

Technology-enhanced Learning & Online Strategies
Assistive Technologies
1180 Torgersen Hall
620 Drillfield Drive (0434)
Blacksburg, Virginia 24061

From: Jared Smith
Date: Wed, Jun 24 2015 9:41AM
Subject: Re: Longdesc implementations/alternatives?
← Previous message | Next message →

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. :-)

From: John Foliot
Date: Wed, Jun 24 2015 5:30PM
Subject: Re: Longdesc implementations/alternatives?
← Previous message | Next message →

> 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





>

From: Moore,Michael (HHSC)
Date: Thu, Jun 25 2015 8:20AM
Subject: Re: Longdesc implementations/alternatives?
← Previous message | Next message →

John Foliot wrote: "* 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?"

I would like to add one more problem that I have noticed when making the images links to a description or with image links in general. It is very difficult for sighted mouse users to identify the link. This has implications for people with cognitive or intellectual disabilities who may find the descriptions helpful.

Mike Moore
Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office

From: John Foliot
Date: Thu, Jun 25 2015 11:32AM
Subject: Re: Longdesc implementations/alternatives?
← Previous message | No next message

+1

JF



>