E-mail List Archives
Thread: javascript and webapps
Number of posts in this thread: 4 (In chronological order)
From: Sam Foster
Date: Tue, Mar 21 2006 11:30PM
Subject: javascript and webapps
No previous message | Next message →
Another question - not too groan-worthy I hope.
Is there any point at which a javascript-dependant application can be
deemed accessible, or are the 2 mutually exclusive? My experience says
that you want progressive enhancement - add the bells and whistles, but
add them on top of a functioning application where javascript (and css
etc.) aren't available. But.. I'm now with a team were there's been a
working assumption that requiring javascript is acceptable for an
application vs. a web page, and the cost of rebuilding to a more
progressive enhancement model may simply be too great.
What then? There's lots I can do to improve accessibility while
maintaining this assumption, and lots of assisted browsing scenarios
will work just fine with javascript. And some is surely better than none.
I've done work where accessibilty trumped all (like the AIR events), but
in a comercial environment it jostles with a host of other priorities.
We'd all like to do the right thing, but some compromise is inevitable.
Should I let the javascript thing go and focus efforts where I can, or
is this a untenable position that will land us in court (or lose
government clients) eventually??
Sam
From: Kynn Bartlett
Date: Tue, Mar 21 2006 11:40PM
Subject: Re: javascript and webapps
← Previous message | Next message →
On 3/21/06, Sam Foster < = EMAIL ADDRESS REMOVED = > wrote:
>
> I've done work where accessibilty trumped all (like the AIR events), but
> in a comercial environment it jostles with a host of other priorities.
> We'd all like to do the right thing, but some compromise is inevitable.
> Should I let the javascript thing go and focus efforts where I can, or
> is this a untenable position that will land us in court (or lose
> government clients) eventually??
Sounds like a business decision. Is it worth it to your business to lose
government clients and fight off potential lawsuits?
For some businesses, it apparently is.
I'm not convinced that there's the dichotomy of EITHER JavaScript OR
accessibility, though. But it may take some work, and if your company
decides it's not the worth the time and effort to do it, then they just take
on the risk that it may cost them later on.
Are you the person who makes these types of business decisions? If not, then
you should make a presentation to them.
--Kynn
From: Christian Heilmann
Date: Wed, Mar 22 2006 12:00AM
Subject: Re: javascript and webapps
← Previous message | Next message →
> Another question - not too groan-worthy I hope.
>
> Is there any point at which a javascript-dependant application can be
> deemed accessible, or are the 2 mutually exclusive? My experience says
> that you want progressive enhancement - add the bells and whistles, but
> add them on top of a functioning application where javascript (and css
> etc.) aren't available. But.. I'm now with a team were there's been a
> working assumption that requiring javascript is acceptable for an
> application vs. a web page, and the cost of rebuilding to a more
> progressive enhancement model may simply be too great.
> What then? There's lots I can do to improve accessibility while
> maintaining this assumption, and lots of assisted browsing scenarios
> will work just fine with javascript. And some is surely better than none.
> I've done work where accessibilty trumped all (like the AIR events), but
> in a comercial environment it jostles with a host of other priorities.
> We'd all like to do the right thing, but some compromise is inevitable.
> Should I let the javascript thing go and focus efforts where I can, or
> is this a untenable position that will land us in court (or lose
> government clients) eventually??
Big discussion topic there. Personally I am with you that a JS
dependent app is just not accessible, but I do understand the business
/ development time aspect as well, especially when it comes to
retrofitting an already existing application.
Especially in .NET2 it is far too tempting to simply drag and drop an
application together and use the original grid control that creates
"javascript:" links.
Funnily enough the 508 guidelines seem OK with that from a legal point
of view, WCAG isn't though (prove me wrong, this is how I read it).
IBM and Mozilla worked together on an accessible set of DHTML controls
and it seems quite handy what they have come up with:
http://www.mozilla.org/access/dhtml/
Sitepoint's new JavaScript Anthology has a chapter on JavaScript and
accessibility that features a lot of test results with different
screen readers, but personally I don't see that as much more use than
a DHTML script that was tested in 1999 on Netscape and IE - by making
your DHTML accessibility dependent on the user agent - regardless of
screen reader or browser - you make it easily outdated.
The problem is not only users of assistive technology, it is about
availability aswell. What if I work in a high security environment
where my employer turns off JavaScript or filters it out via a proxy
by default? What if I am somewhere without internet access on the
ground and want to use my mobile or satellite phone to reach an app?
My personal approach that I try to do any time the project allows for it:
- make it work without JS
- add event handlers or even an AJAX layer to make it work more smoothly
- give the user the option to use one interface or the other - as most
web apps require login and have a defined user journey this is a lot
easier, as visitors are not likely to enter in any of the pages like
they do in a web site.
The latter is always a feasible option as the legal threat might give
you enough leverage to warrant a lighter non-JavaScript interface
version.
HTH
Chris
--
Chris Heilmann
Blog: http://www.wait-till-i.com
Writing: http://icant.co.uk/
Binaries: http://www.onlinetools.org/
From: Sam Foster
Date: Wed, Mar 22 2006 7:50AM
Subject: Re: javascript and webapps
← Previous message | No next message
>Funnily enough the 508 guidelines seem OK with that from a legal point
>of view, WCAG isn't though (prove me wrong, this is how I read it).
>
>
>
that was my take too .. section 508 is more permissive. Dont know about
the equivalent european / APAC laws though.
WCAG seems a better bet in a global market.
>IBM and Mozilla worked together on an accessible set of DHTML controls
>and it seems quite handy what they have come up with:
>http://www.mozilla.org/access/dhtml/
>
>
>
I'll take a look at those.
>Sitepoint's new JavaScript Anthology has a chapter on JavaScript and
>accessibility that features a lot of test results with different
>screen readers, but personally I don't see that as much more use than
>a DHTML script that was tested in 1999 on Netscape and IE - by making
>your DHTML accessibility dependent on the user agent - regardless of
>screen reader or browser - you make it easily outdated.
>
>
Right, though this attitude is pervasive - and certainly built into the
products at the moment. However, to keep QA remotely manageable, you do
eventually have to define a list of UAs and configurations that your
product supports.
>The problem is not only users of assistive technology, it is about
>availability aswell. What if I work in a high security environment
>where my employer turns off JavaScript or filters it out via a proxy
>by default? What if I am somewhere without internet access on the
>ground and want to use my mobile or satellite phone to reach an app?
>
>
Understood. The response would be that the product comes with some
prerequisites, and simply doesnt support some of these scenarios. When a
client comes along who explicitly requests and wants to pay for them,
then they'll reopen the matter. Of course, at that point if javascript
is built in inextricably, working it out is not at all trivial.
>The latter is always a feasible option as the legal threat might give
>you enough leverage to warrant a lighter non-JavaScript interface
>version.
>
>
>
I believe in some products this is a configure-time option. There is a
fallback, "accessible" version available when you install. This grates
badly with me, and is something I want to fix.
thanks
Sam