- From: Ben Boyle <benjamins.boyle@gmail.com>
- Date: Fri, 6 Jul 2007 00:58:09 +1000
- To: "Philip Taylor (Webmaster)" <P.Taylor@rhul.ac.uk>
- Cc: public-html@w3.org, "Robert Burns" <rob@robburns.com>
Authors have struggled very hard to have richer fallback. A good place to look for these struggles is the various "image replacement" techniques that are around. They don't generate the buzz today that they did a few years back. Here is a place to start: http://www.stopdesign.com/articles/replace_text/ The concept of "image replacement" is to have (potentially rich) HTML (fallback), and use CSS to replace this with image. A typical case is pretty headings. One could (and perhaps should) argue that such cases point to limitations with fonts/typography online, rather than a particular issue with image fallbacks. They can also be handled with existing HTML: <h1><img src="welcome.png" alt="Welcome"></h1> This is not a strong use case for richer image fallbacks (imo), but the techniques can be applied to richer HTML than "<h1>". Mostly I want to highlight the difficulties that authors went through trying to implement "image replacement", which was a kind of inverted "html fallback for images" using CSS (because HTML could not solve the problem). I still see a much broader issue (beyond images): associating information with embedded content. There are a few scenarios. "Fallback" is one, and is served by @alt, @longdesc, and the object/video/audio/... models. "Rich fallback" is a particular case of fallback, cannot be served by @alt but can be by @longdesc, object/video/audio/... There is confusion about "fallback". Scenarios (in my mind are): 1. fallback for UAs that don't understand HTML 5 2. fallback for UAs that don't support a particular plugin/media type used within a document 3. fallback for accessibility (a need to access alternatives instead of the embedded content) please note this last option is completely different to making embedded content accessible. I assume all can be served by the same fallback mechanism(s) and this may be incorrect? Another case is not a fallback, but dealing with related content in the page (and a way to express the semantics of that relationship through markup), figure/legend is an example of this, and @longdesc can also support this. There is no markup for other situations, and in those situations, if this relationship were clear, it could also serve as the fallback content, which would boost accessibility (or is accessibility just fine without it? I do not have the answer). It is at the author's discretion which method is best, for example, whether I should use alt="Portrait of George Washington" or alt="" because there is a heading/caption (i.e. context) that already clarifies this. Far more eloquent explanation available in four examples (in the section "Context is Everything") from WebAIM's article on appropriate use of alt text. These make excellent use cases. Please read: http://www.webaim.org/techniques/alttext/#context They do describe techniques that are effective today (HTML 4). It would be nice have better semantics in HTML 5 to capture these relationships. figure/legend is a good addition to HTML. I think working through the webaim examples using HTML 5 markup might be productive, to see how far we get and tease out where the (perceived) gaps truly are. I also think this same issue — "associating information with embedded content" — applies to table@summary (except tables aren't "embedded content"). Sometimes an author wishes to "summarise" a table explicitly in the document, outside the <table>. This practice is endorsed by WCAG Samurai: http://wcagsamurai.org/errata/intro.html, where they state: "You have more than one way to explain the purpose of data tables (including the use of plain-text explanations), so there is no reason to require the use of the summary attribute, which, by specification, is hidden from anyone who can see, including persons with disabilities." This same issue can be oberved on <abbr>. Use case: Three letter abbreviation (TLA) Here it is used badly (redundant): Three letter abbreviation (<abbr title="Three letter abbreviation">TLA</abbr>) Here's a thought for making the association: <dfn id="dfn-tla">Three letter abbreviation (<abbr longdesc="#dfn-tla">TLA</abbr>)</dfn> Personally I'm pretty comfortable with "Three letter abbreviation (TLA)" and no <abbr> tags anywhere. Just as I am happy using punctuation characters rather than <q>. Is that a bad thing? Maybe we don't need markup to capture these associations. Maybe we do. Maybe we need to provide authors with a language that supports implementation of informed choices. That last statement is *the* killer argument for image with fallback, imo. And it is because of the design principle: 3.2. Priority of Constituencies http://dev.w3.org/cvsweb/~checkout~/html5/html-design-principles/Overview.html#priority-of-constituencies Some authors can and will make use of this, if it's able to further improve accessibility. It will require support from UA and AT vendors, and the accessibility field (WAI, webaim etc.) Now read the webaim article about context again :) http://www.webaim.org/techniques/alttext/#context I apologise for the lengthy post. ps: fight the melancholy Philip! On 7/5/07, Philip Taylor (Webmaster) <P.Taylor@rhul.ac.uk> wrote: > > > > Henri Sivonen wrote: > > [all snipped, too depressing] > > wall.against.beat (head) > > > >
Received on Thursday, 5 July 2007 14:58:15 UTC