Alex, I appreciate all your points -- you can "bake into" the code, as you put it, everything a reader needs to navigate a page and accomplish tasks.
But that isn't my point. It can be done, is done and we've done it. My point is that that means you code to the reader. What if you want to do things for your users that the reader(s) is not capable of doing? Currently, all the reader's capabilities lag behind the leading edge. What if the reader defines the leading edge? There are a lot of implication there. If the courts decide in favor of mandatory compliance, the trade off companies may have to make is that they design middle of the road sites to cater to the needs of the disabled, rather than be able to really pay attention to the needs and wants of the majority of their users. Or they would be faced with building and maintaining two code bases -- a prospect most companies do not want to face. I suspect most of them will develop one code base that supports both groups. We just went through a project where the company had decided to support ADA and 508 guidelines to a limited extent. Even without them deciding on full compliance, we had to pull back from many cool features that we would ordinarily have included. There are a lot of clever people out there and I'm sure if this does become mandatory for a broad number of companies, then very clever solutions will be developed. And hey, we'll probably all get some work out of it :) But I think this challenge isn't met just by establishing standards. I think a better analogy for the impact of this, should the courts make it mandatory, is that it would be similar to the courts saying, "OK, every company's public websites have to be backwardly compatible to IE 4.0, and the person using 4.0 has to be able to accomplish whatever everyone else is able to accomplish using newer versions." I'm sure everyone will be able to trash this analogy in specific ways -- but I think it is a better way of describing the challenge than simply saying we need to come up with agreed upon standards. Joseph Selbie Founder, CEO Tristream Web Application Design http://www.tristream.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Robinson Sent: Saturday, October 06, 2007 1:52 PM To: [EMAIL PROTECTED] Subject: Re: [IxDA Discuss] Target.com Loses Accessibility Law Suit >expanding again within the expanded information -- done in I-frames) that >are made possible through javascript. The sighted can do this easily by >clicking on the expand icon (usually a triangle). This is a really great >user feature. It allows a user to get to information fast. > >Try making that accessible using Jaws. Recent version of JAWS do allow for AJAX stylee interaction - so long as you're careful and know what you're doing - ie. make sure that the screen reader's buffer gets updated if the page content is changes (and no be changing so many different elements that the result is just confusing - but that speaks to more general issues of usability) http://juicystudio.com/article/making-ajax-work-with-screen-readers.php http://juicystudio.com/article/improving-ajax-applications-for-jaws-users.ph p Also, there's no reason you couldn't offer the user the option of interacting without AJAX-style interactions. Unless of course what you've built only works if you've got javascript turned on... The accessibility issues you actually have (in what you've described) a) making the reader click on the disclosure triangle - this doesn't just make it inaccessible for screen readers but also, if not inaccessible, harder to use for people who use their keyboard for in-page navigation. If you set the disclosure triangle to do its business when it receives focus then both sets of people would be accommodated. b) using iframes as your method to load external content rather than a scrollable element within the original page. (Of course, you may be doing something cross-domainy that requires such a sleight of hand) Even so, it should still be possible to inform the user that the page's content has been updated. At 18:39 -0700 5/10/07, Joseph Selbie wrote: >Imagine a reader trying to make sense of a site >built in flex! Or one heavily dependent on widgets! Yes, imagine that! http://www.adobe.com/macromedia/accessibility/features/flex/jaws.html Not ideal (accessibility off by default!), but Macromedia didn't rebuild Flash with advice from Mad Monk Jakob Nielsen for nothing. As for widgets, Dojo and other javascript libraries are taking great care to ensure that they are as accessible as possible eg. http://dojotoolkit.org/book/dojo-book-0-9/part-2-dijit/a11y/dojo-accessibili ty-resources >Here is the core of the challenge: The way the ADA guidelines state it, if >you are compliant, that means any user, even if using assisted technology, >should be able to "accomplish" the same tasks as the non-disabled. Why the quotation marks? You would not be expected to simulate the functionality of a photo-stitching app in a screen reader. But if you're providing means of accessing and updating strings, numbers and lists, why should assited technology users not be able to accomplish the same tasks? Technically I mean. >In practical terms, this means building a separate, simpler website, if you >are trying to do complex transactions. Or else the person would have an >experience with Jaws (or any other reader) that would be so frustrating that >it might as well be inaccessible. Once upon a time we spoke of graceful degradation. These days we talk of progressive enhancement and unobtrusive scripting. Any backend worth its salt should be able to deal with different styles of input and output. You shouldn't need to recreate an entirely different website - rather provide a different view. If you build things in the modern standards-based idiom, accessibility will be something baked into your product rather than some half-arsed afterthought. Doesn't mean it won't require a lot of hard work and testing, but isn't that what we get paid for? ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] List Guidelines ............ http://beta.ixda.org/guidelines List Help .................. http://beta.ixda.org/help Unsubscribe ................ http://beta.ixda.org/unsubscribe Questions .................. [EMAIL PROTECTED] Home ....................... http://beta.ixda.org ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] List Guidelines ............ http://beta.ixda.org/guidelines List Help .................. http://beta.ixda.org/help Unsubscribe ................ http://beta.ixda.org/unsubscribe Questions .................. [EMAIL PROTECTED] Home ....................... http://beta.ixda.org
