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
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
