[uf-discuss] changing abbr-design-pattern to title-design-pattern?

[Patrick H. Lauke]

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.com
______________________________________________________________
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/
______________________________________________________________