[whatwg] How to render typographic puns in HTML5 -- aside, legend, alt, other?

16.10.2011 2:26, Tab Atkins Jr. wrote:

> On Sat, Oct 15, 2011 at 2:26 PM, David Dailey<ddailey at zoominternet.net>  wrote:
>> I know that there are a variety of accessibility things in HTML5. Take a
>> look at this small collection of simple typographic puns, currently rendered
>> in SVG:
>>
>> http://cs.sru.edu/~ddailey/svg/2011/simplePuns.svg
>>
>> I've added <title>  and <desc>  to these in a way to explain the sometimes
>> visual effects to audiences that might not be reached by ordinary assistive
>> technology. The use of the mouse or examination of the source should reveal
>> what I'm up to.

In HTML as currently implemented in browsers, one could use <span> with 
title="...". This is far from ideal but would at least imply the 
mouseover behavior (on most browsers) and might give access to the 
explanatory information via assistive software, too.

By the way, I would not call these puns typographic, as they mostly do 
not depend on any particular visual appearance, as per fonts and other 
typographic measures, but orthographic - or just "puns of writing".

>> Question: how would you folks advise doing this in HTML5. Legend was the
>> thing that came to mind, but it looks as though it's not usable everywhere.
>> Aside seems to have slightly different semantics, since it is not so much an
>> aside as an explanation.  Maybe this is where a micro-format is appropriate?
>
> <figure> and <figcaption>  are likely the semantic you're looking for.

The <figure> element has been defined rather liberally (or vaguely, if 
you want to put it that way), so that in addition to the obvious case of 
images, it may also include diagrams (perhaps Ascii graphics?), code 
listings, parts of poems, and videos - on the basis of explanations and 
examples in the HMTML5 draft. Along such lines, a pun of writing, where 
the written (and often intentionally mis-written) form of a word is 
essential, could be marked up as <figure> and the explanation as 
<figcaption>.

However, one might ask what's the point of a <figure> element when it 
has been defined so broadly. What could browsers, assistive software, 
indexing robots, and other relevant software do with it? Surely they 
could know that the <figcaption> element, if present, is supposed to 
provide a caption for the <figure>, but is this really that different 
from the title attribute that we have now (and actually supported by 
software to some extent)?

Let's get back (well, not really back) to the basic _definition_ of 
<figure>: "The figure element represents some flow content, optionally 
with a caption, that is self-contained and is typically referenced as a 
single unit from the main flow of the document."

The string UNNNECESSARY is in some sense "self-contained" as a pun (and 
a funny one at that), and technically it's flow content and may have a 
caption, but it is hardly "referenced as a single unit from the main 
flow of the document". Rather, it's a standalone pun, and referencing it 
would be... well, na?ve.

If we think that "typically referenced as a single unit from the main 
flow" is non-essential, what's left in the definition? Just the 
"self-contained" part. Almost anything would quality as a <figure>, 
given that "self-contained" is a very relative concept (most figures, 
for example, aren't really that self-contained but require both context 
and explanations).

And if you use <figcaption> to explain a pun, that's like putting a joke 
in <figure> and its explanation in a <figcaption>. Not that funny, is 
it? But I would expect browsers to render <figcaption> contents by default.

The bottom line is that I would use <span class=pun title="...">. It has 
the advantage of being usable right now, and HTML5 doesn't seem to offer 
anything more suitable. Of course, I'm a Purist of a sort: it is better 
to use semantically empty markup (like <span>) than semantically wrong 
or even semantically questionable markup.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

Received on Sunday, 16 October 2011 10:51:05 UTC