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

Sun Apr 29 18:12:01 PDT 2007

Welcome to microformats-discuss Benjamin!

On 4/29/07 3:14 PM, "Benjamin Hawkes-Lewis" <bhawkeslewis at googlemail.com>
wrote:

> Tantek Çelik wrote:
> 
>> However, I'm against contorting microformats because of bugs or
>> suboptimal behaviors in <1% marketshare browsers.
> 
> On my reading of the HTML 4.01 specification and WCAG 1.0, the title
> attribute was clearly intended to provide additional /human readable/
> information:
> 
> http://www.w3.org/TR/html401/struct/global.html#adef-title
> 
> http://www.w3.org/TR/html401/struct/text.html#edef-ABBR
> 
> http://www.w3.org/TR/WCAG10-HTML-TECHS/#text-abbr

Agreed.

> On this reading, the use of title for information formatted for machines
> not people is a hack.

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*.

Sometimes (as with ISO dates) you get something that is mostly or at least
somewhat human readable, just so that it *can be* machine readable.

One of the microformats principles is humans first, machine second.  That
doesn't mean machines *never*.  It means that microformats *do* still aim to
make machine readable formats.

> So I think it's erroneous to describe reading out
> the ISO date time format from title as a "bug".

Depends on the reading.  Even words *could* be misread/mispronounced.

> I agree having a setting
> to recast ISO dates into a localized, human readable format might be an
> optimal behaviour, but it would be best if such conversion was triggered
> only in contexts where the ISO format was not meant for direct human
> consumption. In this sense, describing it as "suboptimal" behaviour
> presumes screen reader foreknowledge of microformats, which seems to go
> against the already quoted credo of the microformats movement.

Just because microformats are designed to "work" today, that doesn't mean
they are restricted to those solutions where *all* behaviors are expected to
work today.

Microformats work today very simply and immediately for *some* uses, perhaps
only even *one* use today.

However, by expressing semantics, they are specifically designed to enable
and encourage *new* and more intelligent uses.

The "works today" is a minimal bar to be met, not a restriction.

> Your interpretation of the relevant specs may be different, of course. :)
> 
> With regards to the attempt to list screen readers on the microformats
> wiki, I'd like to draw correspondents attention to the list of past and
> present screen readers on Wikipedia:
> 
> http://en.wikipedia.org/wiki/Comparison_of_screen_readers

Thanks very much for providing this reference.

It points out that our goal should NOT be to simply duplicate the work done
elsewhere with a comprhensive list of assistive technologies (including
screen readers).

Rather, since the goal is real world testing of actual microformats content
in the wild, we restrict the technologies on that list to those which those
in the community have access to, or are in direct communication with someone
who has access to.  I've noted this on the wiki page so that we can stay
focused on actionable research:

 http://microformats.org/wiki/assistive-technology

> The current microformats wikipage's emphasis on the latest versions is
> somewhat misplaced.

I just re-read the page and apologize for whatever I wrote that gave that
impression.  To be clear, I think the key focus here is (quoted from the top
of the page)

"currently known accessibility assistive technologies (implementations) that
are being used in the wild"

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).

> It's important to remember that partly because
> popular screen reading software is prohibitively expensive, many screen
> reader users are using older versions. I'm subscribed to several screen
> reader mailing lists. The latest version of Freedom Scientific's JAWS
> (probably the most popular screen reader) is 8. But judging from mailing
> lists dedicated to JAWS and other screen readers, users of 8 are
> outnumbered by users of 7. Many correspondents are still on 6. Some few
> correspondents still use 5 or even 4.51, e.g.:
> 
> http://www.freelists.org/archives/jfw/03-2007/msg00857.html
> 
> http://www.freelists.org/archives/jaws-uk/03-2007/msg00125.html

Thanks for that information.  I have added those specific versions of JAWS
to the wiki:

  http://microformats.org/wiki/assistive-technology#JAWS

If you have additional information such as rough numbers of users, or dates
of when those versions were published, or URLs where they can be published,
PLEASE add that information to the wiki page.

> With web browsers, one might have a moral case for putting the onus on
> users to upgrade to free and technically superior alternatives, though
> taking such a moral position appears not to be a widely viable
> commercial practice. But in the case of screen readers, the free
> solutions still have a long way to go to be very effective replacements
> for their expensive peers, so a similar moral argument is difficult to
> construct.

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.

> I'm afraid asking for estimates of the size of the userbase for each
> version is a bit unrealistic. There's very little public information
> about such matters.

Even very *rough* estimates would be useful.

> The World Health Organization estimated that in 2002, 37 million people
> around the world (0.59%) were blind and an additional 124 million
> (1.99%) had low vision:
> 
> http://www.who.int/gb/ebwha/pdf_files/WHA59/A59_12-en.pdf
> 
> 3.58% is only a little short of estimates of Safari's market share and
> much higher than estimates of Opera's:
> 
> http://marketshare.hitslink.com/report.aspx?qprid=0
> 
> Of course, because people with visual impairments are likely to have
> poorer life opportunities and to be older, I'd guess they are
> under-represented in uptake of new technologies and the internet generally.

And if they're not using the internet already, it's not clear that changes
we make in microformats would help them in that regard, though if you can
find a link between microformats and helping the blind *start* using the
internet, I'd be very interested to hear about it, as that sounds like a
worthy endeavor.

> In 2002, Chris Hofstader of Freedom Scientific testified that "There are
> approximately 80,000 registered users of JAWS":
> 
> http://web.archive.org/web/20021015235548/http://www.microsoft.com/presspass/t
> rial/mswitness/2002/hofstader.asp
> 
> I assume he meant worldwide, but it's hard to be certain.

Thank you. I've added that to the wiki page as well.

> According to a study of screen reader use published in December 2003, a
> spokesperson for the US National Federation of the Blind estimated that
> in the USA, JAWS had 65% of the screen reader market and GW-Micro
> Window-Eyes had 35%; also JAWS was the software most commonly used by
> U.S. federal workers:
> 
> http://www.redish.net/content/papers/interactions.html

Noted on wiki page.

> 
> If these figures held true beyond the US, one could predict around
> 40,000 registered Window-Eyes users worldwide. However, non-US markets
> may favour other screen readers such as the Brazilian screen reader
> MicroPower Virtual Vision.
> 
> In a published interview with Access World in March 2007 that proved
> controversial and has subsequently disappeared from the site, Hofstader
> apparently said that 2,000 copies of screen reader software are sold per
> month:
> 
> http://blogs.sun.com/korn/date/20070309
> 
> Any sale of a Mac is also a sale of VoiceOver, an effective screen
> reader. Any download of Ubuntu Linux or Solaris is also a download of
> Orca, an increasingly competent open source screen reader.

Pure "sales" numbers, especially as part of other products which themselves
may be the primary reason for purchase, are unlikely to be accurate enough
to show actual numbers of *users*. The key here is users rather than
downloads or sales.

> With regards to the particular issue at hand, it's fortunate that many
> screen reader users probably have not configured their software to read
> title automatically since:
> 
> 1) It's not the default behaviour in JAWS or Window-Eyes.

Is this true across versions?  Could you document your per-version knowledge
of defaults for screen readers on the wiki?

  http://microformats.org/wiki/assistive-technology

> 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.

> 3) title is sometimes abused to spam search engines.
> 
> http://juicystudio.com/article/using-title-attribute.php
> 
> Suboptimal UA behaviour and bad authoring practices don't excuse
> additional misuse by the microformats movement, of course.
> 
> But if title must be used, putting human-hostile title attributes on an
> empty element seems a better hack than misusing abbr or acronym,
> /subject to testing with a range of assistive technology/.

Agreed very strongly with that last clause.

> A specialized data attribute is under consideration by WHATWG for use
> with scripts, but it might also help with this problem Š eventually.
> 
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-April/010800.html

Indeed.  microformats has chosen to build upon proper use of valid semantic
(X)HTML AKA POSH:

 http://microformats.org/wiki/posh

For solutions which require adding new attributes or elements, I *strongly*
recommend you work with the WhatWG effort (and W3C's *new* HTML working
group) on getting such additions into HTML5.  In as much as microformats'
real world experience can help, please feel free to cite discussions and
proposals/tests/results here to make your case for any new
attributes/elements.

Thanks for all the info Benjamin, and again, welcome to the list.

Tantek