W3C home > Mailing lists > Public > public-html@w3.org > September 2008

Long fallback. A problem description.

From: Leif Halvard Silli <lhs@malform.no>
Date: Mon, 08 Sep 2008 19:52:24 +0200
Message-ID: <48C56658.7030102@malform.no>
To: Ian Hickson <ian@hixie.ch>
CC: public-html@w3.org

Ian Hickson 2008-09-07 11.36:

> [...] never been any feedback sent that described a problem
> for which longdesc="" was even remotely considered as a solution.
> [...] establishing a problem to solve, and then coming up with
> the best solutions to address the problem. [...]

Problem: HTML 5 is lacking a feature for/spesificicatin of

1. what authors should do to reference a full HTML fallback for an 
embedded resource of a void element when @alt is too limited to 
represent what is needed;
2. how users, in such cases, can choose between a short @alt 
fallback (for reference) and a complete HTML fallback (for 
understanding what the graphic says);
3. how especially AT users can access the longer fallback "without 
even having to leave the host <img> elements focus" [1].

On the table:  <img longdesc>, <a rel=fallback><img></a>, using 
<object> instead or allowing incomplete fallback.

Notes to the above:
2nd pont: For <object>, author requirements are needed. E.g. 
demand a header which could serve the role of "short reference".
3rd point: Most longdesc supporting UAs open the longdesc in a new 
window. Closing the window brings focus back to the host <img>.

Of/In various importance/conflict with other things, the feature:

* has enough backing from the accessibility community that we may 
recommend authors to use this method - and no nother. (To e.g. use 
both [D]-link + @longdesc simultaneouslly is considered harmful.)
* is semantically clear = it is only fallback for the embedded 
resource, and not fallback for the entire element;
* can be implemented so that the semantics are underlined: For a 
link/@longdesc implementation, one must avoid confusion with 
regular links; Also see point 3 above.
* is simple for authors (technical and conseptual simplicity);
* is free from embedding troubles (<object> currently isn't);
* doesn't require authors to switch from one element to another 
(I.e. authors should not be required to use <object>);
* allows - on one side - authors to place the fallback in a 
logical place: inside or outside the document/the element? Only 
<object> offers full freedom: fallback can inside the element, 
including in the form of a link to another place.
* ensures - OTOH - fallback for one resource from being confused 
with fallback for another resource. Options: using <object>, 
keeping each fallback in a dedicated page - or in a new, dedicated 
"fallback element" [in a transparent <object> element?].
* can serve the purpose of a reusable data version (that e.g may 
be pasted into a graphics free e-mail message).
* can be tested by authors without AT software. (How to easily 
check <object> fallback, how to make @longdesc (easy) clickable.)
* is accessible for all: (same issues as with author testing.) 
Possible @longdesc improvements: Special "visit fallback" tooltip; 
clickable symbol which signals "has longdesc fallback"; (The same 
  improvements could be thinkable for <object> and rel=fallback.)
* enables authors to avoid duplicating information, so that 
neither AT users nor majority users are unecessarily bothered, 
bored or confused by different versions of the same 
material/resource/link. (A rel=fallback has no current AT support 
and would therefore be taken for regular links by AT users.)
* is separable from a possible image link (if implemented as a 
link/@longdesc). In that regard, what about this?:
	<a href=link><object data=image>
	<a href=about>image fallback</a></object></a>

[1] http://lists.w3.org/Archives/Public/public-html/2008Sep/0254.html
leif halvard silli
Received on Monday, 8 September 2008 17:53:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:23 GMT