RE: Screen-reader behaviour

Sander Tekelenburg wrote:
> 
> Why? Why would a HTML UA be unwilling to contribute to HTML5?

Screen Reading technology is not HTML specific: Adaptive Technologies such
as JAWS and WindowEyes (to name only two of a larger number of similar
tools) work as "bridges" between specific OS'es and applications that work
on those OS'es.  JAWS latest version for example can now be used with either
Internet Explorer of Firefox (earlier versions did not have the required
"scripts" to interact with Firefox).  So, while there might be a peripheral
need to follow what is happening with the mark-up language, the developers
are most likely more interested in how the various UAs interpret the
language.

> 
> Sure, but what does authoring HTML (with universality and
> accessibility in 
> mind) have to do with OSs' accessibility APIs? We're trying to
> improve HTML such that it becomes easier and more attractive to
> authors to produce content that provides universality and
> accessibility.  

See above.  It is because the AT tools work with the API's in producing the
alternative output(or other interactions) required for users to actually
process with the authored content.  Without wanting to state the obvious,
this is why standardization is so important.  For users of Adaptive
Technology, there are more "players" involved - it is not simply a web
server handing off a document to a web browser (or other UA).
 

> 
> I am not blaming Jaws. I said that Jaws looks worse than I even
> thought, and that I very much want to know *why* that is; what
> obstacles developers of such tools run into, so that we can start to
> try to remove such obstacles from HTML5.   

There are a number of issues.  One, the development community that produces
these tools is considerably smaller than those that produce the mainstream
web UAs.  Smaller means slower (this sadly is also a 'market forces'
situation).  There is also a cost factor, unlike the mainstream browsers
(which are all free), software such as JAWS can cost upwards of $1,000.00
USD - a considerable amount of money for any, and often an even larger
burden for the very users who require it most, given that often they are
living much closer to the poverty line.  For this reason, upgrading this
type of software is much slower... I know of at least 2 daily-users today
who are using a versions of JAWS that is 2 iterations behind the current
release, simply due to this cost factor. 

Finally, it appears that there is a bit of a "chicken and egg" situation
going on:  it seems that prior to the latest version of JAWS, pages that
included the LONGDESC attribute would "behave badly" (in some instances even
crash the computer), forcing some agencies to actually (sadly) tell authors
to *not* use this potentially useful attribute.  Like many things then, it
sometimes takes longer than anticipated to achieve the desired results -
only now does JAWS actually handled LONGDESC well enough to actually
encourage authors to use it.

Thus one of the biggest obstacles is not the language itself, but rather
adoption and implementation.  This, and remembering that the markup language
is *supposed* to be an agnostic semantic tool, and not a visualization and
rendering language.  

> 
> So I was in fact asking *who/what is to blame*. If we don't know what
> the problems are, how can we fix them? 

It would be easy, and partially true as well, to say that much of the blame
rests with development tools that focus on visual rendering almost
exclusively.  In the late 90's and early 2000's this resulted in WYSIWYG
tools that used nested tables (ad infiniteum) and other equally horrendous
practices.  Today we have many developers who understand the importance of
leaner code and adherence to "standards", but there still remains a certain
level of ignorance (without wishing to offend) coupled with the pressures of
rapid development and break-neck advances in areas such as "Web 2.0"
technologies (whatever that might mean to some) and the emergence and desire
to extend the web beyond information sharing to become an "application
platform" using technologies such as AJAX (which is one of the reasons why
the ARIA work is critical/crucial in the bigger overall picture).  

> 
> And WAI-ARIA looks, at first glance, real useful. But from what I've
> read of it, it appears to be only about intentionally
> javascript-dependant sites (or "DHTML, Ajax, Web 2.0", if you prefer
> fancier terminology). In the mean time, we're still stuck with much
> more basic problems like @alt, @longdesc, @summary, @headers, @scope,
> <img>, <object>, <embed>, aural CSS, etc.   

True, but again, many of the "problems" of the basic elements and attributes
you reference can be traced back to "ignorance" (of the non-intentional
variety, as in lack of understanding/experience).  That sites such as Flickr
and other photo-sharing sites do not allow contributors to add appropriate
alternative text (never mind actually taking the responsibility to try and
explain alt text to their clients) cannot be laid at the feet of the markup
code, but rather at the feet of the developers and businesses themselves. 

This spring I had the opportunity to attend a "Web 2.0" conference in San
Francisco (Silicon Valley).  As I walked the trade show floor, I saw many
new and interesting "Web 2.0" ideas on display, but when I would begin to
ask about "accessibility", I received either blank stares, or vague talk
about Section 508 (with the speaker clearly not fully comprehending what
*that* meant, but it sounded like good buzz words to use at a trade show),
or saddest of all, developers who suggested that those concerns would be
"...addressed in the next release" (I almost cried).  With this kind of
apathetic response rampant at a trade show that is/was supposed to be
showcasing the latest and newest of/on the web, is it any wonder that the
accessibility community cringes at any suggestion to ease off one inch (like
suggesting that alt text be made optional, or abandoning LONGDESC)? Just
because you are creating the next generation hammer does not mean that every
problem should be treated like it's a nail!

I don't know what the answer is to this problem (actually it's education),
but relegating under-used HTML attributes or elements to the trash bin
simply because they are not properly used is to my mind fundamentally wrong.
We cannot blame either the message or the language of the message, but
rather the authors of the message itself.

JF

Received on Tuesday, 4 September 2007 06:09:02 UTC