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

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

From: <bugzilla@jessica.w3.org>
Date: Tue, 16 Aug 2011 03:17:59 +0000
To: public-html-a11y@w3.org
Message-Id: <E1QtAAB-0001Py-HP@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13461

--- Comment #12 from Suzanne Taylor <SuzanneTaylorLogin@gmail.com> 2011-08-16 03:17:56 UTC ---

> (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>
> 
> Note: The long description here is not visible to users, as it has the css
> display none style applied. This removes it from the rendering tree as well as
> diminishing the ability of elements inside of the tree from receiving events.
> Image content and long description content is typically static.

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

I also personally think improving longdesc is the easiest way to move forward.  

But, I want to clarify that the AAP commentary simply says just that something
at least as good as longdesc is needed and asks that the full user experience
be considered as solutions are considered. That commentary is not for or
against any particular solution. It also suggested that longdesc's
implementation details should be improved.

In finding a solution, the specification-writing community needs to not only
make sure the data is the in page, but also make sure the user experience is
good (from coding, to screen reader use, to browsing without screen readers but
needing the long descriptions). Answering questions like those below is the key
to this: 

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.

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. 

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?

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Tuesday, 16 August 2011 03:18:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:43 GMT