- From: <bugzilla@jessica.w3.org>
- Date: Sun, 29 Aug 2010 18:21:32 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10455
--- Comment #16 from John Foliot <jfoliot@stanford.edu> 2010-08-29 18:21:31 ---
(In reply to comment #12)
Benjamin Hawkes-Lewis wrote:
>
> We can reference descriptions internal to the document:
>
> <img src="foo.jpg" alt="{Short alternative}" aria-
> describedby="long">
> <p id="long">{Long description}</p>
>
> We can transclude long descriptions:
>
> <img src="foo.jpg" alt="{Short alternative}" aria-
> describedby="long">
> <iframe id="#long" href="long-description.html" seamless></iframe>
Both of these techniques fail to satisfy requirement 6:
"6. A method to reference a longer description of an image, without including
the content in the main flow of a page.
Delivering a longer description of an image must be a user-choice function:
non-sighted users will likely not *always* want to hear a long description of
an image"
>
> We can indicate a link points to a long description for an image:
>
> <img src="foo.jpg" id="image" alt="{Short alternative}"
> resource="long-description.html">
> <p>
> <a xmlns:dc="http://purl.org/dc/elements/1.1/" about="#image"
> href="long-description.html"
> rel="http://purl.org/dc/elements/1.1/description">
> Long description
> </a>
> </p>
This fails to satisfy requirement 5:
"5. A way to provide user control over exposition of the descriptor so that
rendering of the image and its description is not an either/or proposition. A
visual indicator of the description should NOT be a forced visual encumbrance
on sighted users by default.
Inserting an obtrusive native indicator on a web-page has serious negative
design impacts: web art directors on large web projects in particular will
simply resist obtrusive mechanisms inside their view-port 'canvas'"
This was indeed an early technique that the web accessibility community used in
the late 90's, most often as an anchor element around 'd' or 'd-link'. The
'visual' intrusion of a link associated to an image was an issue then, and so
we had a situation where authors created 'invisible' (actually hidden) d-links
that were targeted to screen reading technology. The use of d-links was
deprecated in favor of using longdesc with the release of WCAG 1.
(http://www.w3.org/TR/WCAG10-TECHS/#def-d-link /
http://www.w3.org/TR/WCAG10-HTML-TECHS/#img-dlink-invis)
There is no indication that we will not see a return to this type of behaviour:
in fact, as examples from the wild show us, the hiding technique is alive and
well, but now uses CSS to place the link off-screen. As a result, these types
of techniques then impact on requirement 2:
" 2. A way to inform users and authors that a description is present/available
via user agent ... a way to inform users
of a link to a longer description that exposes this fact to both sighted and
non-sighted users."
>
> We can reference an external resource as the long description with
> invisible
> metadata:
>
> <img id="image"
> src="foo.jpg"
> xmlns:dc="http://purl.org/dc/elements/1.1/"
> alt="{Short alternative}"
> about="#image"
> rel="dc:description"
> resource="long-description.html">
This is an interesting thought exercise. While this does certainly better
describe what it is we have, it does not address how we provide the long
description to the end user(s). In this regard, how does 'resource' and
'longdesc' differ? (answer: longdesc has some user-agent support today: most
screen readers and Opera)
'Resource' here certainly intimates a link, but how would user-agents a) expose
that link, b) allow activation of that link? For example, in Firefox today,
right-clicking on an image with a longdesc value will render in the contextual
menu the fact that the longdesc exists, and even provide the full URL of the
text, but there is no programmatic way of actually accessing that link short of
noting it and then entering the URL into the address bar - and 'copy and paste'
of text in the context menu is not achievable, making the process extremely
onerous for the end user.
< aside>
Regarding meta-data,see also:
http://microformats.org/wiki/rel-longdesc
http://microformats.org/wiki/existing-rel-values#POSH_usage
< /aside>
>
> > 6. A method to reference a longer description of an image, without
> including
> > the content in the main flow of a page.
>
> "aside" designates content that is not part of the "main flow". This
> could be
> combined with "aria-describedby" like so:
>
> <img alt="Short alternative" aria-describedby="long">
> <aside id="#long">Long alternative</aside>
At the risk of being overly pedantic, <aside> is defined as: "... content that
is tangentially related to the content that forms the main textual flow of a
document." http://dev.w3.org/html5/markup/aside.html#aside
However, a sophisticated image in a document will likely rarely be tangential -
in fact more often than not it is likely the primary focus/intent of the
containing document, so a textual explanation of the visual asset is not
tangential at all.
Another issue is that 'aria-describedby' lacks the ability for the
screen-reader user to choose to access the text or not, (Requirement 6):
"Delivering a longer description of an image must be a user-choice function:
non-sighted users will likely not *always* want to hear a long description of
an image, especially if they are visiting a page (with an image that has a long
description) more than once."
Aria-describedby (at least in WAI-ARIA 1.0) is an 'always-on' association, it
cannot be toggled on or off.
Finally, this does not address the need to not have the text visible to end
users at all times: often the critical text description of the image is only
required by a significantly smaller percentage of the total users, and for
'artistic' considerations the text on the same page as the image is counter to
the artistic requirements of the page: CSSquirrel articulates this in his
blog-post
(http://www.cssquirrel.com/2010/08/16/comic-update-alone-in-the-pitch-black-dark/),
and I have previously asked how this would work in image gallery pages that use
tools such as JavaScript Lightbox? If we have 15 thumbnails on one page, will
we have 15 asides as well? (and what impact does this have on those with
cognitive challenges?) And how will this "look"?
>
> I've no objection to including non-normative suggestions for UI in
> these
> drafts, or other documents such as the ARIA User Agent Implementation
> Guide 1.0
> or UAAG 2.0 Techniques. But, in general, ARIA, HTML5, and HTML-RDFa do
> not
> *mandate* any particular UI, and I don't think that they should make an
> exception for long descriptions. I've no particular reason to think
> user agents
> *will* adopt the described behaviour, but I've little confidence in the
> magic
> power of the spec to force them too either, or any reason to believe
> such ex
> cathedra mandates would be ideal for all users in all circumstances.
Others (notably Shelly) have already pointed out that HTML5 does in fact go
down this route ("...For reference see progress, noscript, and others.") I've
already stated that I am less adamant of this, as I believe that different
platforms and agents will need some UI flexibility: again for example a mobile
version of a browser might interact slightly differently than the same desktop
browser. I don't think tying the hands too tightly achieves any progress: I am
more interested in seeing that browsers expose the full functionality required,
and less so on how they achieve that.
>
> However, I've argued elsewhere that HTML5 should maintain a *native*
> facility
> for designating long alternatives for "img" elements, and that on
> balance
> keeping "longdesc" is the best choice:
>
> http://www.w3.org/2002/09/wbs/40318/issue-30-objection-poll/results
Thumbs up!
>
> If we do mint a new feature and it differs significantly from
> "aria-describedby" (for example, by taking a URI as a value rather than
> an
> IDREF), then it should be called something *other* than "describedby"
> to reduce
> confusion on the part of authors (e.g. a "longdescriptionhref"
> attribute or a
> "longdescription" element).
I agree. The choice of term on this bug's title is slightly confusing, as we
already have aria-describedby which *does not* achieve all of the user
requirements. But as I have stated often, the name is less important than the
functionality. (It's also interesting that you are here suggesting the creation
of an element rather than an attribute, or was this just a slip of the pen?)
>
> But if we mint a new feature because "aria-describedby" is *not*
> sufficient for
> image long descriptions - for example, if being able to reference
> external
> documents as long descriptions is critical - then we should also be
> trying to
> fix ARIA (the generic level).
This has already been noted as a potential action item for WAI-ARIA 2
(searching for reference). This has been discussed extensively before in the
HTML a11y Task Force, notably at their face-to-face meeting in Birmingham
earlier this year.
>
> Looking at the above, the key reason proposed for minting a new
> attribute
> differing from "aria-describedby" is in order to designate external
> documents
> as long descriptions. Why do users need this? Why hasn't PFWG expressed
> this
> requirement in ARIA?
When WAI-ARIA was being written, we had @longdesc that natively achieved this
function. Further both WCAG 1
(http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-text-equivalent) and WCAG 2
(http://www.w3.org/WAI/GL/2010/WD-WCAG20-TECHS-20100708/H45.html) presumed that
@longdesc was (and would remain) a valid technique to achieve the required
functionality.
(It is perhaps also worth noting that WAI has a long history of stating that
ARIA is intended to be a bridging technology, but would prefer to see native
semantics, and @longdesc was a native semantic mechanism. See:
http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements#The_use_of_semantically_rich_elements_is_an_expressed_desire_of_the_W3C_Accessibility_.28WAI.29_community)
However, since HTML5 has no qualms of establishing 'willful violations' of
current existing specs outside of HTML5, it breaks the chain of functionality
that had been previously established. Whether or not we can address this in a
future version of ARIA is not under question, but if or until such time as we
do, the willful violation removes an important accessibility function, and does
not offer any credible alternative to date. Thus we must re-instate @longdesc
(for backwards compatibility) or mint a new attribute that delivers on the
functionality required.
Thus this bug.
--
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 Sunday, 29 August 2010 18:21:35 UTC