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.benjaminhawkeslewi
s.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
microformats-discuss microformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss
|