Review of Script Techniques for Web Content Accessibility Guidelines 2.0 (part 1.)

[I don't normally like posting to a list I've not lurked on, I've perused
the archives which are extensive and generally outside my area of
interest/knowledge which is scripting though.]

I think removing the "site specific preferences can be stored in cookies"
from the "why scripts?" section, cookies are not a specifically
client-side issue, I can't see cookies themselves employing any web
accessibility issues (other than in some way relying on them of course.)
so feel it's a little misleading, also cookies aren't that a prime
concern - The main uses of script are dynamic updating of content -
either through in page menuing systems, or simple image/multimedia
rotation - and the validation of forms.  Cookies just aren't relevant as
I see it.

"1 Check users browser for plug-ins, screen size, browser type and more."

I don't see that it's possible, or valuable to test for browser type,
I've yet to see any suitable code (there's lots given, in some very well
respected books, none of them actually work though, as they revolve
around the user configurable User Agent String - something that is even
more likely to be "unusual" if access technology is being used.

Screen size - Again, surely this is misleading to know where Access
technology is used, even more so than for others - I may have a 1280x1024
21" screen, yet have 4" fonts, so the authors knowledge of the screen
size is only relevant if they know everything about my situation -
completely impossible.

Plug-ins - there's fallback content anyway, and the problems of getting
it wrong is significant - I have Adobe Acrobat installed, but I will not
use it, unless I have to (I go to the trouble of filtering embedded pdf
files Acrobat I just don't find accessible.) so the existence of a
plug-in does not equate as I see it as a right to use it. (or it could be
a shared use computer for example where one user is able to use a plug-in
but anothers access technology prevents it.  It could be used to present
a suggestion, but like many such content-negotiation techniques on the
web - I think it's generally better to truly leave it up to the user.

In the "To take advantage of these features in HTML" section, I also feel
you need to add "Ensure that your site works with javascript enabled." -
so many sites use incompetent javascript methods which cause errors,
these errors are often a bigger barrier to accessibility (the errors
leave menus hidden, or links unfollowable etc.) than if javascript wasn't
available at all.

In the User Benefits "Ability to turn off javascript if have a slow modem
connection "  seems to be misleading, most well authored scripts improve
bandwidth utilisation, client-side validation for example.

Well this is already long, and only section 1 done, so I think I'll split
the review into parts.

Regards,

Jim Ley.

Received on Wednesday, 5 September 2001 12:24:27 UTC