[whatwg] How to render typographic puns in HTML5 -- aside, legend, alt, other?
Jukka K. Korpela
jkorpela at cs.tut.fi
Sun Oct 16 10:51:05 PDT 2011
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:
>> 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
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 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.
More information about the whatwg