Tantek Çelik wrote:
> Certainly formatted for machines and *unreadable* to
people would be yes,
> e.g. a datetime in pure binary, or even just an integer
such as seconds
> since 1970-01-01T00:00Z.
>
> ISO8601 dates (and datetimes) are actually quite
readable for many people
> (e.g. it might have taken you a second or two, but I'm
sure you were able to
> parse the previous sentenc) even though they are
clearly intended to be
> easier for machines to read.
>
> The point is that human readability and machine
readability are not
> necessarily in opposition/conflict. Often you can get
*both*.
I may interject here that there is potentially a distinction
to be made
between readability and "hearability". If
assistive technology such as
screen readers doesn't know what a certain piece of
text/numbers is, it
will (and yes, we're organising thorough testing and
documentation among
WaSP ATF members as we speak) read it out character by
character, digit
by digit. Imagine if the text of this email was read out to
you, not as
words, but letter by letter...how much more difficult would
it be for
you to then understand it? Sure, it's certainly not
impossible (you just
need to keep mental track of all the characters being read
out to you,
then mentally form them into words again), but certainly far
from ideal
in the here and now.
> The "works today" is a minimal bar to be met,
not a restriction.
So then that bar isn't met for screen reader users for the
case
presented in the WaSP article.
> In other words, obsolete implementations that are not
being used are not
> worth documenting for our purposes (or certainly doing
so should be the
> lowest priority).
Agree completely.
> But not entirely impossible nor unreasonable. The
reality is that software
> *does* get improved over time. Just the fact that JAWS
is up to version 8
> demonstrates this, and demonstrates sufficient demand
for new versions JAWS
> that the publishers keep updating it. Therefore there
is a case to be made
> for both encouraging improvements (since history has
shown that software
> does get improved), and clearly there is demand for
better software
> (sufficient to support the market), for encouraging the
consumers of such
> software to demand even better software.
However (pending the testing results), in the context of
screen readers
and the abbr pattern this would be exactly like saying
"we're going to
use object, even though we know safari doesn't play ball
with it...as
once we demonstrate sufficient demand etc etc safari team
will be
compelled to update their software".
>> 2) Current screen readers do not (AFAIK)
discriminate between familiar
>> and unfamiliar, or even first-occurrence and
repeated, abbreviations and
>> acronyms when reading title attributes.
>
> Please indicate which specific screen readers and
versions you know that
> about on the wiki page.
No screen reader does this sort of thing, to my knowledge.
Again, we'll
try to get some testing done (geez, this is turning into a
testing
marathon...I understand this whole "burden of
proof" thing is on us, but
still...)
P
--
Patrick H. Lauke
____________________________________________________________
__
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]
www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.c
om
____________________________________________________________
__
Co-lead, Web Standards Project (WaSP) Accessibility Task
Force
http://webstandards.org/
____________________________________________________________
__
Take it to the streets ... join the WaSP Street Team
http://streetteam
.webstandards.org/
____________________________________________________________
__
_______________________________________________
microformats-discuss mailing list
microformats-discuss microformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss
|
