|
Purpose: The nature of the internet is that not everyone will
receive JavaScript in the way intended. Therefore JavaScript should be
applied in a way that enhances the page, rather than requiring it.
Use un-obtrusive JavaScript
Type: Maintenance, robustness, accessibility
The three pillars of web development are:
- Content and structure: HTML <h1>Main heading</h1>
- Presentation: CSS h1 {color: black}
- Behaviour: JavaScript getElementsByTagName("h1")
The only required part of that triumvirate is HTML, which has the
content and controls. Both CSS and JavaScript should in essence be
enhancements.
An 'unobtrusive' script will:
- Not make assumptions about what methods browsers support.
- Check that the correct HTML is there to act upon, otherwise do nothing.
- Keep the functionality independent of the input device.
- Keep the scope of the script self contained.
For example, to create a show/hide area with this HTML:
<div id="container">
<h2>Heading</h2>
<p>Some text... </p>
</p>
The script could hide the text, wrap the heading content in a link,
and attach an event to that link that shows the paragraph below.
If the script does not function, the text is shown. Just about any
situation can be dealt with in this way, by planning for the scripts
from the start, but implementing them at the end (i.e. building the
back-end functionality as though there was no JavaScript available).
Once the back-end functionality is in place, layering on the
behaviour (front-end scripts) can greatly enhance pages without
requiring JavaScript. With this technique in place, you can also
provide a mechanism to turn-off scripts where they are causing
difficulties for people with partial JavaScript support.
Further reading:
http://dev.opera.com/articles/view/the-seven-rules-of-unobtrusive-javascrip/
Use standard HTML controls
Type: Accessibility, robustness
It must be possible for assistive technologies to identify the name,
role, state and properties of all user interface components such as
form elements, links and components generated by scripts. The easiest
way to achieve this is to use standard HTML controls for web user
interface components.
Accessibility guideline: WCAG 2 - 4.1.2
Use a library for complex scripts and cross-browser event-handling
Type: Robustness, maintenance
A JavaScript library will not take away the need for cross-browser
testing, however, it will considerably reduce the time required to make
a script cross-browser compatible. For short scripts with limited
functionality a library is not needed, this requirement is aimed at
sites with more extensive JavaScript functionality.
The exact library used is at the discretion of the developer, but it should support unobtrusive JavaScript.
Libraries can impact the download speed of a web site, however following these practices should minimise that impact:
- Make scripts external files, therefore cacheable.
- Put the scripts at the bottom of the HTML page, so that the page loads before the script.
- Minify the scripts (the library probably has a minified version already). http://crockford.com/javascript/jsmin
- Set the server to use Gzip for HTML/CSS/JavaScript files (not image or binary files).
- Use a library that is either small, or does not require a large
initial download. (I.e. some libraries only call the components needed.)
Do not use onchange for navigation
Type: Accessibility
Using "onfocus" or "onchange" events to open a new page can cause a lot
of confusion, so do not initiate a change of page or a pop-up with
those events. This means that a menu using a select drop-down should
have a 'go' button.
Accessibility guideline: WCAG 2 - 3.2.1, 3.2.2
Do not enforce timing in pages
Type: Accessibility
Given the different ways that people use pages, it is impossible to
tell how long someone will take to get to a particular part of the
page. Therefore any time limit set on a page will be too long for some
people, and too short for others.
It is difficult to provide very specific guidance, but the principle is that there should be no time limits unless:
- The user can turn off the limit.
- The user can adjust the limit over a wide range.
- The user is given at least 20 seconds to extend the time limit with a simple action.
- The limit is needed for a real time event, such as an auction.
- The limit is greater than 20 hours.
For HTML and JavaScript, it can help to:
- Prevent session time outs: Provide a checkbox at the beginning of
long forms that allow the user to specify a longer session time limit,
or no limit with a logout link instead.
- Give the user control over scripts with time limits: Allow the
user to turn off a time limit, set it at up to 10 times the original
time, or to pause the time limit.
Accessibility guideline: WCAG 2 - 2.2.1
Avoid movement, blinking or updating pages
Purpose: Prevent distracting people with cognitive disabilities.
Movement in pages can be very distracting for many people, but
particularly for people with learning difficulties, or conditions such
as Dyslexia. Continuous movement can be distracting to the point that
it becomes impossible for some people to carry out the task they have
come to the website to accomplish.
Animation, moving areas of the page, or even video should not start
automatically and continue playing for longer than a few seconds
without giving the user a method of stopping them. An exception is made
for loading indicators where there is limited interaction and it might
appear to be broken if it were not included.
Accessibility guideline: WCAG 2 - 2.2.2
Do not use more than 3 flashes a second
Type: Accessibility
Flashes in pages may also cause seizures in people with photosensitive
epilepsy. Seizures can be triggered by flickering or flashing in the 4
to 59 flashes per second (Hertz) range with a peak sensitivity at 20
flashes per second as well as quick changes from dark to light (such as
strobe lights).
For any area of flashing or blinking content, it should not be:
- More than 341 x 256 pixels (approximately 10% of a 1024 x 768 pixel screen), or
- Flashing more than 3 times per second.
Accessibility guideline: WCAG 2 - 2.3.1
Clearly display errors in form entry
Type: Accessibility, Usability
If client-side (JavaScript) validation is used, it should include a
pop-up saying which fields had errors, and an error indicator in each
label which had an error. Ideally, when the pop-up is dismissed the
focus would be put just above the top error message.
WCAG 2 - 3.3.1, 3.3.3
Ensure inserted code is valid
Type: Accessibility
When HTML is added to a page through JavaScript, the resulting HTML
should be valid. This can be tested with the "View rendered source"
feature in browsers such as Firefox.
Accessibility guideline: WCAG 2 - 4.1.1
Ensure AJAX (partial page updates) is accessible
Type: Accessibility
When part of a page is updated, people using screen readers or screen magnifiers may not be aware that something has changed.
The first issue is that screen readers often use a cached copy of
the page, and unless that is updated the user may not have the updated
area. This can be solved by adding this script, and calling the
function after an update:
http://juicystudio.com/article/improving-ajax-applications-for-jaws-users.php
The second issue is that, even when available, the person may not know about the updated area of the page.
Making sure that someone using a screen reader knows of an update is
tricky. Currently, you can only use content (including a hidden
statement to refresh the page after making a change), or allow people
to select an option where updates cause JavaScript pop-ups, or an
option to turn off scripts.
To make sure people using a screen magnifier can tell something has
updated, it is good practice to make it apparent that something is
happening where they clicked, as their view follows the mouse very
closely.
Use ARIA for custom applications
Type: Accessibility
If custom elements are used, there needs to be a mechanism in the code
that identifies what that element is supposed to do. For example, if a
custom button is created that shows when it is pressed, then access
technology needs know about the name, role, state, properties, and
values of that button.
In both HTML and Flash, the default controls already support this,
but if non-standard controls are being used, this has to be taken into
account.
If there is not an option to 'turn off scripts', then the Accessible
Rich Internet Applications (ARIA) specification should be used:
http://www.w3.org/WAI/intro/aria.php
ARIA provides methods to make the JavaScript and AJAX widgets work with access technologies.
ARIA works by simply adding attributes to HTML elements. For example, you could define a 'tree' menu with:
<ul role="tree" tabindex="0″ >
<li role="treeitem">First item</li>
[... ]
</ul>
The role defines what type of control it is, the tabindex is used to allow keyboard navigation.
There are various roles defined in the spec that should cover most situations, such as menu, toolbar, slider, tooltip, tree etc.
When using ARIA the tabindex attribute can be used, and is used to
add or remove things from the tab order. An un-ordered list cannot
normally be focused on when using a keyboard, but adding tabindex="0"
will mean that you can, and in the normal order. Using a value of -1
(or less) will allow you to remove things from the tab order, and this
can be done dynamically with JavaScript.
You can also say when something has a 'state', such as checked,
expanded, and selected. For things that are not links or traditional
form controls, this will be vital to match the visual representation.
Using the ARIA attributes, updates to the content can be announced
through the 'live' attribute. This can be off, polite, assertive, or
rude. For example, the following section of HTML would have its
updates announced:
<div id="myLiveRegion1″ aria-live="assertive">
[updating content]
</div>
The screen reader software can then decide how to deal with the
update, announcing a polite update when the user stops what they are
doing, or interrupting them with a rude announcement.
NB: Use of ARIA attributes does make the HTML invalid (until HTML5
becomes supported), but it is recommended for the purpose of making a
scripted interface accessible.
Accessibility guideline: WCAG 2 - 4.1.2
|