- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Fri, 28 Sep 2001 16:49:39 +0200
- To: w3c-wai-gl@w3.org
Hi,
I've been pointed to [1] in a discussion on my "JavaScript and
ECMAScript Media Types" Internet-Draft [2] by Jim Ley, and I have some
comments on this draft...
[1] http://www.learningdifficulty.org/develop/w3c-scripts.html
[2] http://www.ietf.org/internet-drafts/draft-hoehrmann-script-types-00.txt
| 1 Why Scripts?
|
| Scripts react to events generated by the user, they make
| web pages interactive. Site specific user preferences can
| be stored in cookies.
Scripts can be used to manipulate the DOM of a given document, including
the Style DOM, this is not limited to events. 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.
| Separate content, style and interactivity; use html, css
| and script.(JC)
Uppercase HTML and CSS, throughout the document please. These are
initialisms composed of uppercase letters.
| A more detailed analysis is here: Standard Ecma-262 4.1 -
| December 1999
That should probably be
"For a more detailed analysis refer to ECMA-262 Section 4.1."
| 1 Author benefits
|
| * Stickier pages, interactivity encourages users to hang
| around
_May_ encourage them. Sometimes it just bugs them.
| * Provide improved accessibility and usability for some user
| groups
| * Provide universal content and interactivity for a variety
| of i/o devices and browsers
| * Validate forms.
| * Create custom html pages on the fly.
Script should not be used to generate content, Scripts are optional not
mandatory to access content. Requiring scripts to access content always
reduces accessibility.
| * returning visitors can store their preferences in a
| cookie.
| * Client-side scripting is possible for every web author, at
| no extra cost.
They have to learn a certain scripting language. Publishing on the web
in general doesn't cost anything, if you want to go that way.
| To author an accessible page that includes a script:
| * Decide how your site will perform without a script,
| validate the html.
HTML Techniques should be discussed in the HTML Techniques document.
Authors should however insure, that their DOM manipulations yield in
valid HTML.
| * Create a style sheet if needed, validate the css.
Same for CSS Techniques.
| * Ensure that the site works without javascript enabled.
That should be combined with the first item.
| * Understand which aspects of scripting might interfere with
| accessibility.
| * Decide if a script is the only way to create this
| functionality, and is it essential?
| * Create a script that impacts minimally with accessibility.
| * Save the script, and link to it. This will help to
| maintain consistency across your site.
| * 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.
| * 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.
| 1 Accessibility
|
| 6.3 Ensure that pages are usable when scripts, applets, or
| other programmatic objects are turned off or not supported.
| If this is not possible, provide equivalent information on
| an alternative accessible page. [Priority 1]
|
| Be aware that:
| * Not all browsers support javascript
| * Some users may prefer to use their browser with javascript
| turned off
| * Many users will not be aware of the functionality that
| your use of javascript brings
| * Use object detection rather than browser sniffing. Not all
| javascript enabled browsers implement the complete
| ecma262script and w3c standards, and some users 'spoof'.
| An article by Jim Ley
Make this
An article by Jim Ley discusses <a>how to use object detection</a>
| 2 Use device-independent event handlers
|
| A complete description of the W3C Document Object Model
| Events.
|
| 2.1 input devices
|
| Please consider:
| * Some users have problems reproducing a double click.
| * others prefer not to use a mouse.
| * Some mice have no right clicker.
| * Not all mice have a wheel, or a middle clicker.
s/clicker/button/
| * Not all keyboards have every key.
| * Some users prefer to use the tab key to navigate
| * Touchscreens
| * tablet pens
| * voice input
|
| from NCI:
What's "NCI"?
| * Onmousedown with onkeydown
Eventnames should be all-lowercase.
| * Onmouseup with onkeyup
| * Onclick with onkeypress -- it may be possible to provide
| onclick alone, for many users, as it can be accessed from
| the keyboard, but this implementation would require
| careful testing.
| * Onmouseover -- must be paired with onfocus (and onblur
| added to Onmouseout) to allow for keyboard-only input.
| This is a jerry-rigged solution and may require the
| addition of TABINDEX. It will certainly require careful
| testing, and the code will look a little dicey to a
| validator. See this discussion of event handler issues for
| examples of implementation.
|
| It is necessary to capture keyboard events as well as mouse
| events, so that keyboard users can navigate your site. Ensure
| that where an onMouseover event is captured an onFocus event
| handler is provided for keyboard users; these should both
| point to the same function. If you use separate functions, it
| is possible that some user agents will run both functions.
Add some link to HTML Techniques on the 'accesskey' attribute.
| 2.2 Accesskeys
|
| A brief explanation of some attempts at correct usage by
| Charles Munat.
Make this link
<a>explanation of some attempts at correct usage</a>
| 3 Images
|
| 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"
| There are at least three methods, visibility, hiding and
| displacement. Each has its own benefits.... and unfortunately
| still remains unresolved, An in depth elaboration should
| follow.
|
| In theory the following should work:
| You'll need 2 or 3 CSS stylesheets. Use one style sheet
| for non-javascript visitors. Then use javascript to
| swap css and hide images whilst loading, then use final
| style sheet to show content.
| However, one can sometimes see the content before the
| javascript kicks in.
| Displacement is a possible alternative.
There is the Style DOM, use the Style DOM if you want to change the
visibility of certain elements.
| 4 Sound
|
| The w3c 'object' tag is not supported by all current browsers.
It's HTML4's 'object' _element_.
| In the meantime a workaround which is not HTML4.1 compliant,
It's HTML 4.01.
| but does work for many browsers is to provide a bgsound tag in
| the head and an embed tag in the body. 2.2 provides an
| example.
Please do not recommend usage of invalid markup, conforming user agents
can't deal with it. If it doesn't work, it doesn't work. Those are by
the way again _elements_ not tags. There are only three types of tags in
XML, start-tags, end-tags and empty-element tags.
| 5 Forms
|
| 1 Tutorial
|
| NCI have published a tutorial on publishing accessible forms.
Make this
<a>a tutorial on publishing accessible forms</a>
| 8 Consider avoiding
"Consider avoiding ..."
| If you use any of the following, people with javascript
| disabled browsers will not benefit. Screen readers and other
| applications even when used in conjunction with a javascript
| enabled browser may not perform as you expect.
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. The advice should
be to avoid things if they would be critical, or authors should provide
alternatives not relying on scripting if possible and necessary.
| 8.1 document.write
|
| Screen readers such as jaws will not be able to read text
| updated document.write. Browsers such as Lynx will not be
| updated. Consider if there is another way to design your site.
document.write() is harmful as any kind of DOM manipulation in this
context. Either avoid all of them or use only to give some users
enhancement while ensuring proper accessibilty for others.
| 8.2 window.status
|
| Browsers such as Lynx will not be able to read text updated or
| created using window.status. Instead ensure that all links
| have suitable content for their alt, and title tags.
Don't use window.status. Users expect a certain functionality for their
status bar (e.g. showing the URL some link points at). alt and title are
attrbutes. Reference HTML Techniques for proper alt and title attributes
and proper link context.
| 8.3 href="javascript:...."
|
| Only users with javascript enabled browsers will be able to
| access this link. Remember separate the interactivity from the
| HTML, HTML already provides a linking method. See following
| example for what not to do
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
javascript:void(0)
i.e. noop constructs. If authors want to add functionality to links,
they should use the onclick and other event handlers. An alternative
would be to insert such links only using scripting, e.g.
document.write("<a href='javascript:...")
but the above statement would still apply. This is a general technique,
if something relies on scripting, insert these portions using scripting.
| 8.4 pop up windows
|
| Try to avoid using pop up windows, and do not use more than
| necessary.
| * It can be very confusing to try and navigate when there
| are many windows open.
| * This is made worse, if some windows have reduced
| functionality.
| * The user should be able to open a new window, if, and when
| they wish.
| * 'shift' + 'click' or 'shift' + 'enter' works in some
| browsers, each one should have a suitable method.
* not all devices and envoirements support the "window" concept.
Don't use window.focus() to make popups appear in the front. Note that
the window object in general is proprietary and authors should not rely
on it.
| Click on the logo to open a new window.
Avoid saying "click" yourself :)
| 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
<a title="WAI Home"
href="http://www.w3.org/wai/"
onclick='javascript:open("http://www.w3.org/wai/"); return false;'
target='_blank'>...
instead. Note that the target attribute is only available in HTML 4
transitional.
| 8.5 Cursor position
|
| If you use a script that relies on the co-ordinates of the
| cursor, consider how keyboard users will emulate this
| activity. If they cannot, try to find another route
"coordinates", no?
| 8.6 onchange
|
| 8.7 noscript
|
| The noscript tag attribute enables one to provide alternative
| content for users choosing not to use javascript. However it
| is easier to design and maintain a site, whilst ensuring that
| all users get similar access to information if the use of
| noscript is avoided.
It's the noscript element. Authors should note that this element is only
available in the body, not the head section of the document. Reference
HTML 4 techniques.
| 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.
--
Björn Höhrmann { mailto:bjoern@hoehrmann.de } http://www.bjoernsworld.de
am Badedeich 7 } Telefon: +49(0)4667/981028 { http://bjoern.hoehrmann.de
25899 Dagebüll { PGP Pub. KeyID: 0xA4357E78 } http://www.learn.to/quote/
Received on Friday, 28 September 2001 10:50:21 UTC