[Bug 13461] Commentary on Issue #30 (longdesc) from the Association of American Publishers

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13461

--- Comment #14 from Charles Pritchard <chuck@jumis.com> 2011-08-16 04:57:41 UTC ---
(In reply to comment #12)
> > (long term) Example:
> > 
> > <img aria-flowto="nextParagraph imgDescription" aria-owns="imgDescription"
> > alt="Pie chart illustrating the reasons people like pie." />
> > <div aria-label="Analyzing the pie chart" style="display: none"
> > id="imgDescription">This pie chart is broken up into 9 sections...</div>
> > <p id="nextParagraph" aria-label="Discussing the pie chart">
> > Pie is excellent, everyone can see that...</p>
> > 
> 
> Thanks for sharing this solution. I personally think that this solution is very
> clever. (CSS display:none content is typically hidden from screen reader users,
> so you'd have to position it off screen instead). 

The content of longdesc is hidden, as well, from the initial view. I'd hope
that through aria-flowto, the AT would lower the priority the display none
semantic. Of course, if that's not the case, there are many, many visibility
methods, such as offscreen positioning. For modern browsers, there's <canvas
height="0" width="0">alt content</canvas> and style="transform: scale(0,0)",
and all of that. Those kind of issues are really about supporting specific User
Agents/secondary user agents (such as IE6 or JAWS9, etc).

> With such coding, how could you write a browser feature that would show all
> long descriptions? The solution above uses nothing unique to long descriptions,
> and so long descriptions would be difficult/impossible to detect.
> 

Items such as aria-expanded and aria-haspopup, as well as aria-controls and
aria-owns provide authors an opportunity to mark-up their code with more
information, they also provide a standard means for other developers to
identify expanded and minimized content. I would recommend aria-expanded and
such semantics, for showing and hiding descriptions. There are various roles
and html5 tags (such as figcaption) which can also add semantics to the
elements, and in the worst case, data-* can be used on a per-site basis.


> Also, what is the over-all screen reader user experience? For example, in the
> solution above, how do you get back from the description, if you took that
> path? I'm sure a way could be specified. There might be a keyboard command to
> move to the previous step in aria-flowto. Also, if you just want to stay with
> the main text, and skip any image descriptions, how do you know which to choose
> "Analyzing the pie chart" or "Discussing the pie chart"? This is the type of
> analysis the AAP paper was requesting for any proposed replacements. 
> 

These are going to be AT specific -- as things typically are. In the example I
shared, the main text and the image description are both options in flowto --
but only the image description is set in the aria-owns semantic -- this lets
the AT know that the description is a long description for the image. As there
is only one other path, the AT can continue with it.

One of the nice things about ARIA, is that the scripting environment can also
base its behavior on ARIA semantics. One could use this vocabulary: role='img"
aria-flowto + aria-owns, and aria-expanded, to drive the scripting environment,
instead of using private variables. This allows the scripting engine to rely on
the DOM state instead of an opaque, internal state. And that's handy.

> Finally, how does the skill set required to code this compare with the skill
> set required to code longdesc? It seems that (with a little further
> discussion/refinement on this solution) this could be used for hidden long
> descriptions while aria-describedby is used when the description is on the same
> page, allowing a different user experience for the 2 different situations -
> that's great. longdesc and aria-describedby make a similar duo. But, which duo
> is more complex to teach/code?

What is our baseline for the skill-set? The vocabulary used is larger than
"longdesc", with its minimal vocabulary, but that also means more room for
semantic expression, and in a sense, a more rigid environment. With longdesc, a
scripting author might have to use onclick and window.open to share a
description, with ARIA, an author might use aria-expanded and display, instead.
setAttribute and getAttribute are a little bit easier in that minimal case.
ARIA is more complex, but that complexity benefits all users, if the markup is
added. The same applies to adding html5 markup and other such roles. It should
be there anyway, even if longdesc is used, as it enhances AT.

For the widest possible support, I'd include longdesc as a legacy/backup, but
expect that the vast majority of ATs support ARIA. Targeting legacy
environments is a chore unto itself.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 16 August 2011 04:57:45 UTC