'

[Irl-dean] Creating accessible javascript

Gez Lemon gez.lemon at gmail.com
Wed Sep 27 19:45:21 IST 2006


Hi Dónal,

On 27/09/06, drice at nda.ie <drice at nda.ie> wrote:
> our view on AJAX as per our guidelines:
<snip>
> Reliance on JavaScript is an accessibility issue in itself and so
> a non-JavaScript dependent alternative (in fact equivalent) should
> also be provided.

That's an interesting view. I consider reliance on JavaScript to be
more of a device independence issue that an accessibility issue, as it
depends on a script capable and enabled user agent. JavaScript in and
of itself does not create accessibility barriers when used correctly.
If it's used incorrectly, then like any technology (including HTML),
the result is likely to be inaccessible.

Accessibility isn't solely the responsibility of the web developer.
Developers, user agent (including AT) vendors, and users themselves
all have a role to play. The User Agent Accessibility Guidelines
(UAAG) requires that an accessible user agent provides programmatic
access to the content [1]. I completely agree that reliance on
JavaScript is not a good practice; I just disagree that it's an
accessibility issue.

There are three distinct areas of responsibility (developers, user
agents, users), and those committed to accessibility will want to play
their role as well as they are able. The danger of one of the
stakeholders overplaying their part is that the resulting advice can
end up conflicting, so the final result isn't accessible at all. This
can be seen on the NDA guidelines page where this advice originates
[2] in the section on advocating that event handlers must be device
independent. This is a requirement from WCAG 1.0 checkpoint 6.4
(priority 2) [3]. A couple of years after WCAG 1.0 became a
recommendation, UAAG recommended that user agents allowed event
handlers to be operated by the keyboard alone (priority 1) [4]. This
means that advice that advocates doubling up on event handlers now
results in them being executed twice when activated with the keyboard,
as the click activated version must also be able to be activated by
the keyboard, as per the UAAG requirement  (there are workarounds to
this contradictory advice, but the advice and example on the NDA page
makes no mention of them).

On the subject of not relying on JavaScript, I'm also surprised to see
you advocate the noscript tag, as it's such a clumsy mechanism that's
more often than not inadequate for providing an alternative;
particularly considering that scripting is behavioural in nature,
whereas the noscript element assumes that scripting will be used
purely for creating content. When content is created with scripting,
progressive enhancement (destroying the non-JavaScript mechanism if
present, and recreating the scripting alternative with scripting
itself) is far more efficient than the clumsy noscript method. The
noscript example provided on the NDA page suggests that a choice of
red, green, or blue is an equivalent for a colour picker, whereas a
typical 8-bit RGB colour picker will typically offer 16,777,216
different colours rather than a choice of one colour from three
alternatives.

> The following is an example of a page that we developed for the Oasis
> website that uses Javascript in a form in an accessible way:
> http://www.oasis.gov.ie/service_finder/

The town form control in this example is added using progressive
enhancement, which is very good, but the prompt should be
programmatically associated with its form control before it could be
considered accessible. The prompt "town" is not marked up in a label
element, and is not associated with its form control, so should be far
from being considered accessible. It's exactly these types of
considerations that must be included before scripting solutions can be
considered accessible.

Regards,

Gez


-- 
_____________________________
Supplement your vitamins
http://juicystudio.com




More information about the CEUD-ICT mailing list