Re: [Scripts-TECHS] Comments on Script Techniques for WCAG20

> Cookies, and this should
>clearly be stated, are an HTTP feature and HTTP should be used to store
>cookies, otherwise functionality depending on Cookies is limited to
>Scripting enabled browsers. Scripts may be deactivated for security
>reasons, thus authors should be strongly encouraged not to rely on
>Scripts for Cookies. Dicussions on Cookies should reference P3P
>Activity.

I'm not sure I understand this discussion of cookies, cookies whether
created by script or through HTTP methods, are used identically using
cookies in scripting does not prevent their use in HTTP, use cookies
client side does not modify how they are used serverside.

>That should probably be
>
>  "For a more detailed analysis refer to ECMA-262 Section 4.1."

ECMA-262 Edition 3. Section 4.1

Edition 4 is due sometime, and we don't know if 4.1 will exist the same.

>Script should not be used to generate content, Scripts are optional not
>mandatory to access content. Requiring scripts to access content always
>reduces accessibility.

Naturally, but script can still generate content, perhaps an alternative
view that adds accessibility or otherwise.

>|      * Check your script for typo's, and internal logic. There is
>|        no validator, this is a manual job.
>
>The parser of the scripting language checks for typos, internal logic
>hasn't much to do with accessibility.

Of course it does, if the logic is flawed resulting in some
<indeterminate> result of the script then it's inaccessible.

>|      * Make sure that your script works well with a variety of
>|        user agents.
>
>No, instead authors should code against standards. If your script uses
>DOM Level 1, you can't expect it to run in e.g. Netscape Navigator 4.

No, If your script causes non DOM level 1 browsers to hide the content or
produce script errors or other problems, then your script is not
accessible, the same as how content must be available when script is not
enabled/available, it also has to be available with UA's which choose not
to implement DOM Level 1 (or whatever).   In any case, as there are no
DOM Level 1 conformant browsers in existence, the  script techniques
document has to be realistic.

>|        An article by Jim Ley
>Make this
>
>  An article by Jim Ley discusses <a>how to use object detection</a>

It's also not by me, I gave a rough draft of some of it to Ian Oeschager
who actually created it, I was not aware that my name was even on it!
Other parts are written by other authors aswell.

>|      * Onmousedown with onkeydown
>
>Eventnames should be all-lowercase.

Why?  in the DOM yes, in xhtml yes, but so, this is neither, and I see no
reason for the rules of English to be broken.

>|    Very large numbers of images may make your page slow to load,
>|    and can make navigation hard in a non-graphical environment.
>|
>|     3.1 Hiding whilst loading
>
>"Don't do that"

Why?  there are legitimate requests from people to, you need to advance
reasons why not. (Incidently I've argued the same as you, and have also
produced an example where there's not obviously an accessibility issue by
doing it.)

>Please do not recommend usage of invalid markup, conforming user agents
>can't deal with it.

In Accessibility terms, conforming user agents accept anything and give a
best rendering, there is no justification for a conforming (to the
Accessibility recommendations) UA to reject anything, giving best effort
is essential.

There's rarely a reason to suggest invalid markup though. (I don't think
the example here is one.)

>If one uses Scripts, users without scripting enabled browsers (please
>do not refer to javascript directly, there is the preferred ECMAScript
>language and JScript and others) won't ever benefit.

We have issues of accessibility here, (and this touches on our
discussions in relation to the MIME proposal of yours.)  "javascript" is
understood to mean ECMAScript by most developer, javascript is understood
to mean jscript when it's being executed in IE.  JavaScript strictly is
only supported by 2 browser families (Netscape/Mozilla and AvantGo.)  For
maximum developer comprehension javascript is the only option IMO, or
"ECMAScript languages such as javascript" each time, which is a mouthful.

>The javascript: URL scheme is unregistered and unspecified. Using it is
>harmful, e.g. if the user tries to open a link in a new window, most
>actions performed with such links fail. Authors should especially avoid

http://jibbering.com/techniques/#t1

>|    Example.
>|    Web Accessibility Initiative logo
>|
>| < a title="WAI Home" href="javascript:open('http://www.w3.org/wai/')"
>
>|
>| < img alt="Web Accessibility Initiative logo" border="0"
src="http://ww
>| w.w3.org/Icons/wai" / > < /a >
>
>As you can see, the example is not valid. This is a deprecated example,
>authors should use

It's intended to be incorrect.

><a title="WAI Home"
>   href="http://www.w3.org/wai/"
>   onclick='javascript:open("http://www.w3.org/wai/"); return false;'
>   target='_blank'>...

This is also sub-optimal (consider what happens where you have a browser
which doesn't have a concept of windows...)

http://jibbering.com/techniques/#t1

>|   9 Script validators
>
>What's a script validator? What do they do? Note that it requires
>ActiveX and maybe therefore not available for many companies.

I have no idea, I don't use the term, in any case, it's a tool, obviously
the tool is limited in which enviroments it can be run it, I am looking
at providing a hosted service, but have neither the bandwidth  nor
currently the expertise to provide such a service until then the tool is
surely still useful if limited to one platform. (The fact it requires
ActiveX in irrelevant, what's relevant is that it is Microsoft Windows
specific.)
It makes suggestions based on how scripts are executed in the page, much
like  Bobby does on the manual checks when it sees things which are
potentiall bad, you've obviously seen the sample report.

Jim.

Received on Friday, 28 September 2001 11:32:30 UTC