Re: [w3c-wai-gl] <none>

> THE PROBLEM
>
> Browsers vary in their ability to handle different technologies,
> including style sheets, scripting languages, etc.

StyleSheets are suggestions and I don't see how they can make inaccessible
content accessible, as a user stylesheet would do the same, as you note
Lynx is accessible.

>  Often, browsers which
> are accessible (such as LYNX) do not support technologies such as
> scripting.

This is only a problem, if you decide that Script is a valid and
reasonable method of making a site accessible, I've yet to see an example
of scripting making an inaccessible site accessible. (Yes Alan, I've seen
it in the client, but that's where the author has chosen to make an
inaccessible site - or to enhance the accessibility from a personal
perspective.)

> How do we handle writing guidelines so that pages that are written today
> will be accessible with the browsers available today without creating
> rules that perpetuate restrictions that will not be needed in the
> future?

Why should browsers in the future support Scripting?  Scripting is
dangerous, without scripting you should be pretty safe, with it, your
personal information leaks, your machine is susceptible to virus's etc.
You have to very much keep on top of patches, of course if you're tied to
the browser version that works with your access technology then there's
little you can do.

I've been trying to create an accessible pop-up menu system,
http://jibbering.com/accessibility/menu.html and I thought I was quite
close, the fallback situation (no scripting) works well, and the popup
works well in IE5 with both keyboard and mouse navigation, Mozilla has a
bug which prevents it working, but it will soon also be fine.  I'd had
reports that it worked okay in Jaws 3.3, so things were looking good, then
I try it in Jaws 3.7 and find you can't access any of the popup menu
links.  So here I am with the sole aim of an accessible menu, and testing
on the first access technology I use it fails, I can't believe I can solve
it without knowledge of which access technology is being used - something
that is just not available to script.

I do not believe script is an accessibility solution, and there are no
examples, so I can't see how the Working Group can believe it either.

> A) Continue to use "until user agent" language to identify when there is
> a guideline or checkpoint which is required today but which may go away
> as technologies evolve.

Which technologies?

Jim.
> THE PROBLEM
>
> Browsers vary in their ability to handle different technologies,
> including style sheets, scripting languages, etc.

StyleSheets are suggestions and I don't see how they can make inaccessible
content accessible, as a user stylesheet would do the same.

>  Often, browsers which
> are accessible (such as LYNX) do not support technologies such as
> scripting.

This is only a problem, if you decide that Script is a valid and
reasonable method of making a site accessible, I've yet to see an example
of scripting making an inaccessible site accessible. (Yes Alan, I've seen
it in the client, but that's where the author has chosen to make an
inaccessible site - or to enhance the accessibility from a personal
perspective.)

> How do we handle writing guidelines so that pages that are written today
> will be accessible with the browsers available today without creating
> rules that perpetuate restrictions that will not be needed in the
> future?

Why should browsers in the future support Scripting?  Scripting is
dangerous, without scripting you should be pretty safe, with it, your
personal information leaks, your machine is susceptible to virus's etc.
You have to very much keep on top of patches, of course if you're tied to
the browser version that works with your access technology then there's
little you can do.

I've been trying to create an accessible pop-up menu system,
http://jibbering.com/accessibility/menu.html and I thought I was quite
close, the fallback situation (no scripting) works well, and the popup
works well in IE5 with both keyboard and mouse navigation, Mozilla has a
bug which prevents it working, but it will soon also be fine.  I'd had
reports that it worked okay in Jaws 3.3, so things were looking good, then
I try it in Jaws 3.7 and find you can't access any of the popup menu
links.  So here I am with the sole aim of an accessible menu, and testing
on the first access technology I use it fails, I can't believe I can solve
it without knowledge of which access technology is being used - something
that is just not available to script.

I do not believe script is an accessibility solution, and there are no
examples, so I can't see how the Working Group can believe it either.

> A) Continue to use "until user agent" language to identify when there is
> a guideline or checkpoint which is required today but which may go away
> as technologies evolve.

Which technologies?

Jim.

Received on Sunday, 23 September 2001 08:43:52 UTC