RE: XHTML Applications and XML Processors [was Re: xhtml 2.0 noscript]

Ian Hickson wrote:
> 
> There is nothing forcing ATs from having to wait for the entire page
> to have completed rendering. If they do, then that is a bug in those
> systems. 

No, it is not a bug, it is the way that those systems *must* operate -
it must capture *everything* so that it can further process the data and
output it to it's "specialized" format - speech.  

Again:

	"To understand the issues behind ensuring that Ajax is
accessible to screen readers, it's essential to have an understanding of
how screen readers work. To allow screen reader users to read and
interact with web content, screen readers take a snapshot of the web
page, and place this content in a virtual buffer. The screen reader uses
the virtual buffer to allow the user to navigate the content. Without
the virtual buffer, the screen reader only has access to the parts of
the page that are focusable by non-assistive user agents, such as
anchors and interface elements. WITHOUT THE VIRTUAL BUFFER, THE USER
CANNOT INTERACT WITH OTHER ELEMENTS AND THEIR CHILD NODES IN THE
CONTENT, SUCH AS IMAGES, LISTS, TABLES, AND SO ON." [Emphasis mine]  
(http://juicystudio.com/article/making-ajax-work-with-screen-readers.php
) This, BTW, should be essential reading for all AJAX developers.

Content authors (and AJAX application developers) are free to understand
and work with this, or ignore it and do whatever they want.  Good luck
selling your AJAX application to any entity that needs to purchase
according to Section 508 requirements, or other legislated equal-access
requirements.  You wanna be cool, or do you want to make money?

To put this thread somewhat back on track (Subject: RE: XHTML
Applications and XML Processors [was Re: xhtml 2.0 noscript]), it's
origins are rooted in a discussion about XHTML2 - the future, not the
here (or near) and now, where all kinds of "nifty" but totally
inaccessible AJAX widgets are emerging, cranked out by developers with
no concept or regard for universal accessibility.  So be it.  Cruft
sinks, quality rises...

But we are looking at the next generation of development language and
models.  56 baud modems are sitting in boxes gathering dust (I mean, who
in their right mind is going to be on 56 dial up and simultaneously
attempting a BitTorrent download, while surfing the web, reading their
email and listening to their internet radio - hey Björn, you forgot that
they were IMing their girlfriend at the same time...).  The micro-blink
delay in pages loading versus partially loading before being
"interactive" is an angels-on-the-head-of-a-pin discussion - in stream
processing vs. full onload processing and any attendant "delay" will be
more due to excessive visual content (images and flash banners) than any
other reason.  But a model that waits for a complete load has the added
advantage of a level playing field, and as Mark has pointed out can be
processed in any manner of way (again to quote him - "..SAX and
DOM-style processing (any style, actually)...").  I then advance the
idea that, hey, by the way, this is also a better model from an
accessible, universal access, point of view.

To counter these points, I am admonished on the "harm" of this model,
with the sum total of this harm being.... Frustration.

I'm frustrated too.

JF

Received on Thursday, 3 August 2006 05:54:50 UTC