[uf-discuss] RFC: sHTML Video Thumbnailing

[Benjamin Hawkes-Lewis]

Charles Iliya Krempeaux wrote:

>> But I /don't/ accept that. IMHO microformats currently abuse <abbr> and
>> perhaps (more debatably) title for time and location, violating the
>> standards-based credos of the movement with poor consequences for
>> assistive technology which have already been widely discussed on the
>> list.
> 
> Admittantly, I haven't gotten around to reading those threads yet :-(
> 
> Was there a consensus about a solution to the problem you are describing?

My understanding of the limited consensus would be that the community 
needs to do more accessibility testing of alternative solutions (e.g. 
using <span> with title instead of <abbr> with title), since:

1) It's more realistic to fix microformat parsers than upgrade 
everyone's assistive technology.

2) We need to make sure any fix actually has tangible benefits for 
end-users, rather than just looking better from a language lawyer point 
of view.

> I'd say I'm suggesting it be used in a way the designers of it
> probably didn't imagine it would be used.  (It doesn't seem to violate
> the HTML specification though.)

That entirely depends on what we think "quotation" means. The more I 
think about, the less convinced I am that "quotation" can stretch to 
mean "thumbnail".

> Having said that... there isn't a <thumbnail cite="..." src="...">
> element... so what else can we do?

Use the cite element instead of the cite attribute. Or to put that in 
the form of a question: what problem does the cite attribute solve that 
the cite element does not?

> I want to add semantics somehow... but don't want to make
> non-validating HTML (and just make up a new element... even though I'd
> like to).

Sure, but there's no point in adding the wrong semantics. ;)

>> Also, I think "Thumbnail of" will prove harder to internationalize than
>> "Still:" or "Thumbnail:", which would mean parsers would struggle to get
>> at the alternative text proper.
> 
> The <img> "alt" attribute doesn't really seem built for i18n.
> 
> Isn't i18n usually handled with completely different versions of the
> same HTML page.
> 
> Which in that case would make the i18n for the sHTML Video
> Thumbnailing suggestion I made a non-issue.
> 
> (I.e., there would be different version of the "alt" attribute for
> each language supported (in each of those pages)... and it will be a
> worded in a way that makes sense.)

Sorry, I wasn't talking about about localizing individual documents and 
consuming them as a human reader. For that, any sensible phrasing is 
fine. The problem is with localizing the proposed microformat itself and 
consuming it as a microformat parser. I'm assuming such parsers may want 
to extract both the thumbnail and alternative text for the thumbnail. 
Now, prefixes such as "Thumbnail of " and "Still: " are only useful if 
you need to communicate that the thumbnail is in fact a thumbnail; that 
is, they are not part of the text alternative proper but additional 
hints to the user sneaked into the alt attribute. So a microformat 
parser will want to drop those phrases to get to the "real" alternative 
text, "Dorothy encounters the Lion". But in order to drop them, it needs 
to be able to recognize them reliably. Separating the prefix from the 
real alt attribute with some very simple punctuation makes the task of 
writing a microformat parser that can deal with alt attributes in 
multiple languages much simpler. Instead of translating "thumbnail of " 
into every single language, you only need to translate the colon symbol 
into a comparatively small number of equivalents. It's the same reason 
we use a single ISO date format in microformats rather than hundreds of 
more human readable date formats, except in this case "still: " is human 
readable. :)

> But yeah... having "quote" read out does still seem undesired.
> 
> Aren't the aural style sheet or something that can be used to get rid of 
> that?

Short answer: no, not with current technology. :(

Only self-voicing software that has a tiny share in the assistive 
technology market (Emacspeak, Fire Vox, Opera for Windows) supports 
speech styles at all. Safari, Firefox, and Internet Explorer do not 
parse aural CSS and do not expose it to accessibility frameworks for use 
by screen readers; mainstream screen readers do not download the CSS and 
parse it for themselves; and only Orca (which barely counts as 
mainstream) uses CSS internally.

If mainstream screen readers have access to quotation semantics /at 
all/, it's usually in the form of either:

1) Quotation punctuation already (e.g. Orca used with ELinks or Thunder 
used with WebbIE).

2) The abstract notion that a given node is a <q> or <blockquote> (e.g. 
Window-Eyes used with Firefox or JAWS used with Internet Explorer).

What they do with this information varies enormously by screen reader, 
screen reader version, and configuration, but has nothing to do with 
author-specified CSS. For a bit more detail (mainly about how they 
handle the poor old <q> element) see:

http://www.benjaminhawkeslewis.com/www/accessibility/q-element/q-and-screen-readers

"Quote" and "end quote", in my example, aren't added by the browser and 
aren't the screen reader reading out browser-added quotation 
punctuation. Window-Eyes can be configured to announce the beginning and 
end of quotations, and that's roughly what it says when it is so configured.

But, leaving aside the technical problems involved in using speech CSS, 
content should make sense without depending on author-specified styles. 
If you're needing to disguise a presentation suggested by the HTML 
specification for an HTML element in order for your use of it to make 
/sense/ (rather than just look or sound nicer), then you're probably 
misusing it.

Even if you could change how screen readers and talking browsers 
presented <q>, you couldn't fix other automated processing that 
represents <q>'s contents explicitly as a quotation. For instance, I 
wrote a (rather hacky) Firefox extension that provides rapid right-click 
access to the "Quotation Source" when a cite attribute is present:

http://www.benjaminhawkeslewis.com/www/hypertextuality/

Since people don't generally think of thumbnails as quotations, this use 
of <q> could render my extension's UI rather confusing. I could "fix" 
this aspect of my extension, but that's not really the point: the point 
is my extension isn't broken.

--
Benjamin Hawkes-Lewis