Re: Questions about WCAG 6.3

you raise good points, but alternative browsing is on the rise and if they
want to make money, they will find that they will loose an increasing share
of it if they don't accomodate.  However, the good news is that there is new
technology on the way that may make it lest serverly costly but I fear the
retooling curve may be just as expensive.

Greate discussion!

Joel Sanda wrote:
> 
> Wow...some great comments, and late on a Friday
> afternoon!
> 
> I had suspected I was missing the boat <GRIN>. Now
> that I've taken my bath....
> 
> One more question: how many organizations will
> redesign their sites to work with browsers that don't
> have JavaScript enabled?
> 
> ServerSide code can take the place of some client side
> JavaScript - if an IT department has the resources to
> implement more servers and IT people and the necessary
> developers to recode their Internet based
> applications.
> 
> In my opinion, #6.3 will probably be, hands down, the
> largest reason most developers/organizations give up
> on accessible web design - or ignore it for that
> reason.
> 
> It's tough enough to build online Applications that
> work in IE and Netscape. I think it's a little
> unreasonable to assume developers are going to now
> ditch all JavaScript - which means recoding a whole
> lot of stuff - to conform to Level A.
> 
> I know that #6.3 doesn't preclude the use of
> JavaScript, but it means that any site's functionality
> based upon that scripting has to be rebuilt to not use
> the JavaScript. And client side JS is popular for a
> very important reason: money. It costs to add servers
> to support server-side scripting.
> 
> I understand that WAI is about Internet Appliances as
> much as disability, but Internet Appliances are not
> advanced or prolific enough to argue #6.32 is doable.
> I browse the web at home and from my Palm and cell
> phone - I don't think it's reasonable for me to ask
> Amazon.com to rebuild their delivery system to work
> with my Palm browser. It would be nice, but I'm in a
> minority sending and reading email from my Palm and
> Cell Phone.
> 
> Just my two cents, well, maybe ten cents by now.
> 
> Joel Sanda
> joelsanda@yahoo.com
> 
> --- Bruce Bailey <bbailey@clark.net> wrote:
> > Sorry, but you are missing the boat on this one!
> >
> > Adherence to 6.3 is of critical importance.
> > JavaScript dependent web pages
> > are probably the second biggest accessibility
> > obstacle faced by persons with
> > disabilities!  (Missing ALT content has got to be
> > first, but bear in mind
> > that it is disingenuous to rank P1 checkpoints in
> > this fashion.)
> >
> >
> > > -----Original Message-----
> > > From: w3c-wai-ig-request@w3.org
> > [mailto:w3c-wai-ig-request@w3.org]On
> > > Behalf Of Joel Sanda
> > > Sent: Friday, March 24, 2000 4:44 PM
> > > To: W3C/WAI
> > > Subject: Questions about WCAG 6.3
> > >
> > >
> > > Hi;
> > >
> > > I've got some questions (well, alright, problems:)
> > > with WCAG 6.3. Wondering if anyone can shed some
> > light
> > > on that requirement for me.
> > >
> > > 1. Since no browser supports all WCAG
> > requirements,
> > > it's impossible to build a site that is 100%
> > compliant
> > > with all WCAG levels AND functions in all
> > browsers.
> > >
> > > 2. Since the best support for the WCAG lies in
> > > Internet Explorer 4.x, it seems logical most
> > people
> > > looking for an accessible site will hit it in
> > IE4.x.
> > > This is born out by my research of screen readers.
> > > JAWs is the most popular, and that runs with IE4.x
> > or
> > > higher. HomePage Reader requires a 4.x version of
> > > Netscape.
> > >
> > > 3. Give 1. and 2., I argue that the scripting
> > > requirement 6.3 is far too restrictive.
> > >
> > > In my environment, we rely on JavaScript to ensure
> > > forms are filled out correctly and the database
> > > doesn't get cluttered with incorrect information.
> > In
> > > fact, anyone using a database and a form will
> > probably
> > > use JavaScript to ensure forms are filled out
> > > correctly. Imagine the chaos with eCommerce if a
> > site
> > > couldn't ensure it's users entered data correctly.
> > > This site would be accessible, but one mistake and
> > the
> > > user is out of their money, the product, and the
> > > vendor and shopper have to solve a problem that
> > could
> > > have been prevented with JavaScript.
> > >
> > > That in and of itself is an aid to accessibility:
> > it
> > > gives people two chances to fill out forms - their
> > > data entry pass and the verification pass.
> > Usually,
> > > the JavaScript error checking gives more detailed
> > > information to the user if there is an error.
> > >
> > > I know there's the component of "universal
> > > accessibility", but IMHO #6.3 is just far too
> > > restrictive for most companies to consider.
> > >
> > > Thoughts? Am I missing the boat on this one?
> > >
> > > Thanks!
> > >
> > > Joel Sanda
> > > joelsanda@yahoo.com
> >
> >
> 
> =====
> Joel Sanda
> Rocky Mountains | United States
> ---------------------------------
> joelsanda@yahoo.com  |  Yahoo! Messenger: joelsanda
> ---------------------------------
>  Nature is indifferent to our love, but never unfaithful
> - Edward Abbey
> 
> __________________________________________________
> Do You Yahoo!?
> Talk to your friends online with Yahoo! Messenger.
> http://im.yahoo.com

-- 
Hands-On Technolog(eye)s
ftp://ftp.clark.net/pub/poehlman
http://poehlman.clark.net
mailto:poehlman@clark.net
voice 301-949-7599
end sig.

Received on Saturday, 25 March 2000 08:27:10 UTC