[Bug 10455] Mint a describedby attribute for the img element

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





--- Comment #21 from Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>  2010-08-30 10:56:16 ---
(In reply to comment #16)

On 29 Aug 2010, at 19:21, John Foliot <jfoliot@stanford.edu> wrote:
> Benjamin Hawkes-Lewis wrote:

> > We can reference descriptions internal to the document:

[snip]

> > We can transclude long descriptions:

[snip]

> Both of these techniques fail to satisfy requirement 6

Those two techniques were intended to satisfy Requirement 1 not Requirement 6.

I don't see why those Requirements need to be satisfied by the same
features/techniques, *but* the RDFa approach does satisfy both 1 and 6.

> > We can indicate a link points to a long description for an image:

> 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.["]

No it doesn't, since user agents are free to hide links designated as long
descriptions and provide a context menu item on the image to follow the link -
if they agree with you that would be the best user interface for their users.

> as examples from the wild show us, the hiding technique is alive and
> well, but now uses CSS to place the link off-screen.

Indeed.

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

Note, even if you hide the link normally to satisfy art directors, you could
style the link visible when the picture is hovered or when the link receives
focus. This still leaves speech recognition users out in the cold, but I guess
they could reject your art director-ordered styles or use a link list (such as
Opera provides).

In any case, with the link annotation technique I suggested, a user agent could
(for example) change the cursor over the image to indicate a long description
is present, expose a context menu item on the image pointing to the link
destination, and maybe provide some mechanism for listing available long
description
links for speech recognition users - all regardless of how the link was styled.

> how does 'resource' and 'longdesc' differ? (answer: longdesc has some
> user-agent support today: most screen readers and Opera)

Doesn't seem like a relevant question to whether we introduce "describedby".

> 'Resource' here certainly intimates a link, but how would user-agents a)
> expose that link, b) allow activation of that link?

That's up to user agents.

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

I'm not sure what you mean by "no programmatic way": there *is* programmatic
access via the accessibility API and the DOM.

Firefox's built-in "longdesc" UI is unhelpful to the point of uselessness and I
believe is going to be removed along with the rest of the Properties dialog.
Fortunately, Firefox supports an add-on architecture, and there are addons
providing less useless UIs for "longdesc" access. Given we don't expect Firefox
to be self-voicing (for example), I guess this isn't totally unreasonable even
though I would prefer built-in UI. The bug remains open:

https://bugzilla.mozilla.org/show_bug.cgi?id=1996

(Incidentally, the fact that it may take a whole ecosystem of collaborating
hardware and software (switch devices, browsers, browser addons, platform
accessibility APIs, other applications like screen readers, search engines) to
produce an accessible user experience is one more reason to be sceptical about
requiring "user agents" to expose any particular UI. It over-simplifies the
conformance class.)

> 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

Is there such a category as "overly pedantic" among us markup geeks? ;)

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

Sometimes, a document will use a term that is defined or further explained in a
self-contained capsule somewhere else on the page. This is a reasonably common
style in print newspapers/magazines and I guess allows readers who already know
the term to easily skip the explanation.

The premise of using an /optional/ long description is that the full-blown text
equivalent is tangential, and therefore needs to be hidden away. Sometimes
users access this tangential content to explain the image. "aria-describedby"
provides a programmatic link between the image and its explanatory capsule, and
allows user agents to expose that capsule by request, configuration, or design
according to their users' needs.

> Another issue is that 'aria-describedby' lacks the ability for the
> screen-reader user to choose to access the text or not

What in the ARIA specification forbids giving the user this choice?

I don't see any such restriction at:

http://www.w3.org/WAI/PF/aria/states_and_properties#aria-describedby

Indeed, the specification stresses the optionality of the description:
"additional detail that some users might need".

And if there is a such a restriction, why have PFWG imposed this limitation?

Or if this is only how user agents have actually implemented
"aria-describedby", why have they implemented it that way rather than in the
way you suggest?

This sounds like a case where, before rushing to introduce a differently
designed long description feature in HTML5, we should fix ARIA, provide better
guidance to ARIA implementors, and fully understand why implementors are
making the decisions they are on behalf of their users.

> 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

This fits reasonably well with my capsule analogy.

> 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?

Whenever an image is the subject in its own right, rather than (say) a link to
the same image in a lightbox view, its long description should be present as
well. Whether that implies 15 "aside" elements in the document at once depends
on whether all full-scale images are simultaneously present in the document or
not, which likely differs between lightbox implementations.

> what impact does this have on those with cognitive challenges?

Well, I imagine some people will want images presented with their long
descriptions, some people will want to optionally access the long descriptions,
some people will want only the long descriptions, etc. The great thing about
not mandating a UI is people are free to develop user agents (or user agent
configurations) that suit any of these preferences.

> And how will this "look"?

If their user agents do their jobs, how users want.

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

Well, both the title and description explicitly request minting a "describedby"
attribute.

I assume if Laura wants something else, she'll clarify. 

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

No, that was deliberate.

If I was designing long text equivalents for "img" from scratch and didn't need
to think about "longdesc" or ARIA, I'd be tempted to create some sort of
element bound to "img" by "for" and "id". Elements have a good backwards
compatibility story (i.e. you can at least see the text inside!), accept other
elements as content (e.g. to indicate changes of language or link elsewhere),
keep alternate text close to the image for hand authors, and can trivially be
restyled to bypass the diktats of art directors. "for" and "id" reuses an
existing association mechanism. Authors commonly fail to use it successfully,
but it's better than inventing yet another association mechanism for them to
break.

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

That's like waiting for HTML6! ;) Why the delay?

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

[snip]

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

The chain should never have existed.

ARIA *must* not rely on any HTML features given it has an explicit and
long-standing design goal of providing bolt-on accessibility across a range of
host languages. See for example this paragraph from the editor's draft:

"Some host languages exist to create semantics for features other than the user
interface. For example, SVG expresses the semantics behind production of
graphical objects, not of user interface components that those objects may
represent; XForms provides semantics for form controls and does not provide
wider user interface features. Host languages such as these might, by design,
not provide native semantics that map to WAI-ARIA features. In these cases,
WAI-ARIA could be adopted as a long-term approach to add semantic information
to user interface components, without the obsolescence that might be expected
when used in a more generic language."

http://www.w3.org/WAI/PF/aria/introduction#co-evolution

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

You speak of "a future version of ARIA", but aren't both HTML5 and ARIA Working
Drafts? If this omission is valid and is serious enough to delay taking HTML5
to Last Call, then isn't it enough to delay taking ARIA back to Last Call also?

-- 
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 Monday, 30 August 2010 10:56:19 UTC