OnKeyPress

[Kev]

I need to make some specific alterations to some JavaScript in webpages in
order to comply with government guidelines on accessibility. Apparently,
whenever the OnClick event is used, it must be accompanied by an alternative
OnKeyPress event. The guidelines are very vague and I am not sure what this
means. I have used the following piece of JavaScript inside the cell of a
table:

onclick="window.open('http://www.etc')

Do I need to add the following?

onkeypress="window.open('http://www.etc')


Kev

 

[Steve Karnath]

Try
onclick="javascript:window.open('http://www.etc')"

 

[Ivo]

"Kev" wrote

Those gov. quidelines want you to provide alternative means for people who
don't click, but do everything with their keyboard. An onkeypress event
handler on the table cell alongside the onclick is however a silly
requirement, as keys cannot be pressed over ordinary page elements. You will
need to write function that catches keypresses on the whole document and
make clear on your page which key (combination) does what, regardless of
whether the (mouse) pointer is over a table cell or not.

function KeyPress(e) {
if (document.all){e = window.event; key = e.keyCode;}
if (document.layers){ key = e.which; }
key = String.fromCharCode(key).toLowerCase();
if (e.ctrlKey&&key=="s"){alert("CTRL+S was pressed");return false;}
}
document.onkeydown=KeyPress;

Try
onclick="javascript:window.open('http://www.etc')"

Sorry Steve, but this neither answers the question nor is it any good
advice. By default already, any value of an event handler like onclick is
interpreted as J(ava)script. The "javascript:" pseudoprotocol is for use in
the place of normal url's, such as in href values, although this is not
part of any standard and not recommended.

HTH
Ivo

 

[Richard Cornford]

I need to make some specific alterations to some JavaScript
in webpages in order to comply with government guidelines
on accessibility.

It might have been an idea to mention which government as accessibility
legislation varies across the world.

Apparently, whenever the OnClick event is used, it
must be accompanied by an alternative OnKeyPress event.
The guidelines are very vague and I am not sure what
this means.

This sounds like a requirement to follow the guidelines produced by the
W3C Web Accessibility Initiative: Web Content Accessibility Guidelines
1.0:

<quote>
Guideline 8. Ensure direct accessibility of embedded user interfaces.
....
Checkpoint:
8.1 Make programmatic elements such as scripts and applets
directly accessible or compatible with assistive technologies
[Priority 1 if functionality is important and not presented
elsewhere, otherwise Priority 2.]

Guideline 9. Design for device-independence.

Use features that enable activation of page elements via a variety of
input devices.
Device-independent access means that the user may interact with the user
agent or document with a preferred input (or output) device -- mouse,
keyboard, voice, head wand, or other. If, for example, a form control
can only be activated with a mouse or other pointing device, someone who
is using the page without sight, with voice input, or with a keyboard or
who is using some other non-pointing input device will not be able to
use the form.
....
Generally, pages that allow keyboard interaction are also accessible
through speech input or a command line interface.
....
Checkpoints:
....
9.3 For scripts, specify logical event handlers rather than
device-dependent event handlers. [Priority 2]
....
</quote>

The spirit of these guidelines is that whenever a particular (and
especially an important or even vital) piece of functionality is
triggered with a mouse/pointing device then there should also be a way
of achieving exactly the same using a keyboard. So that the user's
ability to use the resulting page/site/web application does not depend
on the device used to interact with it.

In many cases an onclick handler is already adequate as it can be
triggered with the keyboard. <INPUT type="button|submit|refresh"> and <A
href=" ... "> elements facilitate this, but it works because it is
possible to focus these elements using the keyboard (tabbing to them).

I have used the following piece of
JavaScript inside the cell of a table:

When you say "inside the cell of a table" do you mean an onclick
attribute on the TD/TH cell? If so a keyboard alternative is going to be
problematic as TD/TH elements cannot be navigated to/focused using the
keyboard and are not direct receivers of keypress events. TD/TH elements
could intercept keypress events in the capturing or (more realistically,
as it works with IE) the bubbling phase of event propagation but to do
that they must contain an element that can be focused/tabbed to and
receive keyboard events.

onclick="window.open('http://www.etc')

Opening pop-up windows is fundamentally not accessible.

Do I need to add the following?

onkeypress="window.open('http://www.etc')

It would be counterproductive to open the pop-up window on *any*
keypress event. The user might be trying to activate some other keyboard
navigation/shortcut. In principle you would only want to be triggering
actions with the same key presses as the user would normally use to
activate input buttons and links (which probably means that using (or at
least including) an input button or link would be a better idea).

I can't imagine many circumstances where accessibility would be achieved
by retroactively adding an event-handling attribute to an existing page.
It is really something that warrants thinking about at the design stage.

Richard.

 

[Kev]

It might have been an idea to mention which government as accessibility

legislation varies across the world.
UK.

This sounds like a requirement to follow the guidelines produced by the
W3C Web Accessibility Initiative: Web Content Accessibility Guidelines
1.0:
Yes.

When you say "inside the cell of a table" do you mean an onclick
attribute on the TD/TH cell?

Yes. Here is the page in question. Check it out.
http://www.darlington.gov.uk/Services/Planning+Services/The+Planning+Service
/OnlinePlanningResources.htm

I have 2 more similar pages from which the JavaScript has been removed, but
I am intending to reinstate it if possible:
http://www.darlington.gov.uk/Services/Planning+Services/Projects+and+Schemes
/Projects%20and%20Schemes.htm
http://www.darlington.gov.uk/Services/Planning+Services/Planning Services.
htm

I should point out that I am only responsible for the content of around 50
pages of a 2000+ site. I have no control over page layouts and no access to
stylesheets. The use of JavaScript is in danger of being outlawed on this
site and I am fighting to save it.

I can't imagine many circumstances where accessibility would be achieved
by retroactively adding an event-handling attribute to an existing page.

There may well be no benefits. It's just for the sake of abiding by the
rules.

Kev

 

[Richard Cornford]

UK.

The UK DDA is currently an unknown quantity when it comes to web sites
as all of the cases that have been bought to date have been settled out
of court. Though I can understand how a local authority might prefer to
comply anyway (and generally approve).


I see. You have a paragraph of text within a TD that you want to
navigate to a URL if clicked upon (and preferably in a new window).
However, that TD is adjacent to a TD containing an image link that
navigates to the same URL. All else being equal (and it is a long way
from being equal as the page stands [1]) that image link would satisfy
the WCAG 1.0 requirement for the necessary functionality to be
accessible through the keyboard. Anyone needing to navigate to the URL
can use that link and view the accompanying text as an explanation of
the link (probably a good idea as some of the images are not
particularly self-explanatory).

Thus you can regard clicking on the text in addition to the link as an
optional extra upon which the viability of the page does not hang.

Those image links could do with some more work; for example the alt text
"ODPM logo: link to ODPM website (new window)" will be of little use to
ordinary members of the UK public as they will not associate the
abbreviation with the Office of the Deputy Prime Minister (and those
reading the alt text will not necessarily be in a position to read the
text from the logo).

My impression of this question (and experience of how web site
accessibility is (miss)handled generally) is that you are trying to get
the page to pass an automated accessibility test. Unfortunately
automated testing is at best a tool that can be used in creating an
accessible web page; passing the tests in no way guarantees that the
results will be accessible, and a completely accessible page can still
fail such a test. Appropriately skilled humans are probably the best
means of achieving accessibility in web pages, and assessing the
results. (Though my judgement would be that retro-fitting accessibility
onto the site as it stands is not viable and it will only really be
achievable through a re-design from the ground up.)

Your own problem demonstrates this admirably because the feature of the
page that is concerning you is not inaccessible to keyboard users (as
such, the pop-up window problem remains). They have the other link to
use when they want to navigate. But your automated testing software will
always see the onclick handler in the TD and can know nothing about what
it does or the fact that it actually does no more than reproduce the
functionality from the adjacent cell.

To placate the machine you would have to lose the onclick handler form
the TD and wrap the text within the cell in a link. Maybe CSS styling
the link into a block element and having it fill the TD (though that
doesn't always work that well on IE browsers) and styling the text to
look like it does now.

Incidentally, it is a mistake to set the cursor for the cell to a hand
using CSS when the functionality is javascript dependent as they are
both optional technologies and independently available and can be
separately disabled/unavailable. A normal javascript design pattern
would add the styling that only made sense in the presence of javascript
using javascript so as not to mislead the user into believing they may
have functionality that they do not have. Also - style="CURSOR: hand" -
is an IE only formulation; using standard CSS would be more in keeping
with the WCAG 1.0 recommendations (and a pragmatic approach is available
to accommodate the older IE versions that do not understand the real CSS
cursorointer. (and don't bother arguing that everyone uses IE
because accessibility *requires* that a site be usable in more uncommon
UAs).

Yes. Here is the page in question. Check it out.
http://www.darlington.gov.uk/ ...

I wonder what it is about UK local authorities that make them incapable
of producing a web site that is anything approaching good? In its
class - www.darlington.gov.uk - appears to be above average, but when
every line of code on a page speaks of total failure to comprehend the
medium or any of the technologies it uses being above average does no
more than reveal how bad UK local authority sites are on average.

The page starts with an incomplete HTML 4.0 transitional DOCTYPE
declaration, putting all of the browsers that switch modes into quirks
mode. The next element is a SCRIPT, lacking the required type attribute
and invalidity situated outside of even the HTML element (let along the
HEAD or BODY). Then the nonsense really kicks in; the whole page is
marked up in a pseudo-XHTML, but not an XHTML 1.0 appendix C HTML
"compatibility" mark-up (which wouldn't make sense with an HTML 4.0
transitional DOCTYPE anyway) but a true nonsense mark-up:-

<LINK rel="stylesheet" type="text/css"
href="/Common/Css/Services.css"/>

- mixed upper and lower case tag names, some contentless elements have
the space before the - /> - and other do not, attributes unknown even in
transitional HTML, etc, etc.

... . The use of JavaScript is in danger of
being outlawed on this site and I am fighting to save it.

Javascript and accessibility are not mutually exclusive. But when the
people responsible for a web site clearly don't even comprehend (x?)HTML
it is difficult to see how they could make a valid judgement about
anything that they do on their site.

There may well be no benefits. It's just for the sake of
abiding by the rules.

If by "the rules" you mean the (UK) DDA then the rules require that the
site *be* accessible (assuming that the DDA does apply to web sites
(pending actual legal precedent)), passing accessibility valeting
software produce X is not complying with either the letter of the DDA or
its spirit.

Richard.

[1] Currently the biggest barrier to keyboard operation of your page is
a 'search' submit button that has been given an onclick handler, and had
that handler doubled-up with an onkeypress handler (presumably motivated
by this goal of "accessibility"). So the user arrives on the page and
starts tabbing through the links and form controls using their keyboard
in an attempt to get to the links that they want to use. They arrive at
this submit button and the onkeypress handler notices that they have not
entered anything in the "search" text field and cancels the default
action, which, for a tab key press, is navigation on to the next
control/link. And shift-tab is also cancelled so they cannot go back
either, not even go back to the "search" text field and to enter
something so that the form validation doesn't cancel their keyboard
navigation attempts. And now they are stuck; end of keyboard
navigation - the page is now fundamentally inaccessible (with an
additional negative impact on the usability of the entire browser).

Of course this has happened because onkeypress has been seen as some
sort of accessibility panacea while the wording of the WCAG 1.0
checkpoint has been disregarded. It says that the event handlers used
should be logical and independent of input device, and forms have an
excellent logical and input device independent event handler that is
ideal for form validation: onsubmit. Unfortunately when web 'developers'
have no comprehension of what they are doing ...

 

[Kev]

My impression of this question (and experience of how web site

accessibility is (miss)handled generally) is that you are trying to get
the page to pass an automated accessibility test.
Exactly.

To placate the machine you would have to lose the onclick handler form
the TD and wrap the text within the cell in a link. Maybe CSS styling
the link into a block element and having it fill the TD (though that
doesn't always work that well on IE browsers) and styling the text to
look like it does now.

I want the whole cell to be the link, not just the text within it. Also,
to change the style of hyperlinked text would be to break another rule.
And stylesheets are off limits.

Incidentally, it is a mistake to set the cursor for the cell to a hand
using CSS when the functionality is javascript dependent as they are
both optional technologies and independently available and can be
separately disabled/unavailable. A normal javascript design pattern
would add the styling that only made sense in the presence of javascript
using javascript so as not to mislead the user into believing they may
have functionality that they do not have. Also - style="CURSOR: hand" -
is an IE only formulation; using standard CSS...

Aside from using CSS, is there any other way to set the cursor? By the
way, I tested it using a different browser and it worked ok.

If by "the rules" you mean the (UK) DDA then the rules require that the
site *be* accessible (assuming that the DDA does apply to web sites
(pending actual legal precedent)), passing accessibility valeting
software produce X is not complying with either the letter of the DDA or
its spirit.

I realise this, but I am primarily concerned about the look and feel of
the webpages for normal users. As long as accessibility is acheieved
suffiently to pass the accreditation, then I don't care if it was
arrived at by the best method or not.

So the user arrives on the page and
starts tabbing through the links and form controls using their keyboard
in an attempt to get to the links that they want to use. They arrive at
this submit button and the onkeypress handler notices that they have not
entered anything in the "search" text field and cancels the default
action, which, for a tab key press, is navigation on to the next
control/link. And shift-tab is also cancelled so they cannot go back
either, not even go back to the "search" text field and to enter
something so that the form validation doesn't cancel their keyboard
navigation attempts. And now they are stuck; end of keyboard
navigation - the page is now fundamentally inaccessible (with an
additional negative impact on the usability of the entire browser).

It seems to tab ok on this page without getting stuck.

Kev

 

[Richard Cornford]

Exactly.

I always end up wondering why. If someone has decided to expose a web
site to an automated accessibility test then they must have had some
purpose/motivation. If the point is to avoid violating the (UK) DDA then
passing an automated test alone will not achieve that. Similarly, if the
point is to create an accessible web site then again automated testing
will not achieve that in itself. If the point is to gain a right to
display some accessibility logo then, without the site actually being
accessible, the result is likely to be public ridicule. Otherwise
automated testing without some sort of goal is a waste of resources.

I want the whole cell to be the link, not just the text within it.
Also, to change the style of hyperlinked text would be to break
another rule. And stylesheets are off limits.

An alternative way of placating the automatic accessibility checker
would be to add the onclick handler with javascript so that the checking
software would not be able to see it:-

// not executed until after the browsers has processed the mark-up
// for the corresponding, and uniquely IDed, TD element.

if(document.getElementById){
var tdElement = document.getElementById("idOfTdElement");
if(tdElement){
tdElement.onclick = function(){ ... };
}
}

Aside from using CSS, is there any other way to set the cursor?

Yes, using javascript to set the corresponding property of the element's
style object, set the className property of the element to a pre-defined
CSS class, or through the document.styleSheets object (where
implemented).

By the way, I tested it using
a different browser and it worked ok.

Which browser? Opera and Mozilla both show the default arrow pointer.

I realise this, but I am primarily concerned about the
look and feel of the webpages for normal users.
As long as accessibility is acheieved suffiently to pass the
accreditation, then I don't care if it was arrived at by the
best method or not.

The method employed does not appear to be facilitating accessibility at
all (that keypress handler on the submit button is already completely
fatal to it, and, as I said, the problem that the automated testing is
highlighting with the TD onclick is not really a problem for
accessibility as the WCAG checkpoint was already satisfied by the
ability to keyboard navigate to the URL using the adjacent link).

There is a strange (irrational) practice that involves using javascript
to write invalid HTML into otherwise valid document. The document pass
the (x)HTML validator and so the valid (x)HTML logos may be used on the
page (and contractual requirements to produce formally valid web pages
are met). The result is validity in name only. It is easy to
deliberately fool a validator because it is just a machine, and your
automated accessibility test is just as easy to fool.

It seems to tab ok on this page without getting stuck.

How many browsers have your tired it with? It doesn't work on Opera or
Mozilla, and the javascript is trying to cancel the default action from
the keypress event so it should be expected to be a barrier to keyboard
navigation on the page because that is what the script has been designed
to do.

Richard.