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

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





--- Comment #5 from John Foliot <jfoliot@stanford.edu>  2010-08-27 20:18:47 ---
Edward,
Are you then suggesting that the user-requirements are not valid? Or that the
engineers cannot solve these problems and deliver on the need?  The needs are
clear and with merit:

1. A programmatic mechanism to reference a specific a structured description,
internal or external to the document.

The ability to link one piece of data to another is the foundation of the web.
Delivering on this feature/function should be simple.


2. A way to inform users and authors that a description is present/available
via user agent (UAs could provide an option to reveal the content of
describedby via a context menu, preference, or switch etc.). This also affords
a practical method for the curious and for developers who want a tool to check
the describedby descriptive content and keep it up to date.

Currently only Opera and (to a lesser extent) Firefox has a way to inform users
of a link to a longer description that exposes this fact to both sighted and
non-sighted users. This was one of the criticisms of @longdesc (that it was not
exposed to sighted users), so here the difference between @longdesc as
supported by the majority of today's browsers, and the 'new' attribute/function
is more clearly articulated *as a requirement*, something that was perhaps not
as clearly stated in HTML 4's @longdesc.


3. A device independent way to access the descriptive content.

Specifically, this feature *must* be accessible to keyboard interaction,
including the ability to activate the link via a keyboard. Currently only Opera
offers this functionality to @longdesc, so the new attribute would require
support in all browsers.


4. An explicit provision that accessing descriptive content, whether internal
or external to the document containing the image, does NOT take the user away
from the user's position in the document containing the image where the verbose
descriptor was invoked.

We have numerous example of this type of functionality on the web today - I can
think of shopping carts that automatically update quantities and totals without
interrupting the 'page-flow' (linearizion of the DOM/page). Today to ensure
this type of functionality we usually need to invoke the aria-live attribute,
however ideally this would be native to the new attribute. 


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' (not to be
confused with <canvas>), so we need to be able to ensure that 'discoverability'
of extended descriptions does not impact on visual design - if we do not ensure
this, content authors will simply not include longer descriptions, or
'style-away' the indicator using @hidden (which the editor has already
confirmed means content that is not relevant to the page), or by using CSS
display:none; which removes the indicator from the page flow for *all* users.
We currently do not have a mechanism in HTML5 today that fits this requirement.


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, especially if they are visiting a page (with an image that has a long
description) more than once. A visual metaphor is the difference between
glancing at an image, and studying an image: if you have studied an image
intently once, you will likely only glance at it the second, third, or multiple
other times. As well features such as JavaScript Light-boxes are specifically
built to not feature text, and instead focus on inserting a larger copy of a
thumbnail image in an "overlay" that deliberately obscures the page's text, in
favor of placing all visual focus on the image. Thus the functional requirement
is to deliver on this need.

So while this bug outlines functionality that was envisioned but not
articulated in @longdesc, it remains open to a new mechanism that can deliver
on the requirements rather than insisting on maintaining an attribute that many
engineers see as fatally flawed. Perhaps we could call it @pheonix ?

-- 
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 Friday, 27 August 2010 20:18:52 UTC