[uf-discuss] changing abbr-design-pattern to title-design-pattern?
Patrick H. Lauke
redux at splintered.co.uk
Sun Apr 29 18:34:27 PDT 2007
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).
> 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
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
Co-lead, Web Standards Project (WaSP) Accessibility Task Force
Take it to the streets ... join the WaSP Street Team
More information about the microformats-discuss