Discussion in 'Javascript' started by Kev, Jul 15, 2004.

  1. Kev

    Kev Guest

    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


    Do I need to add the following?


    Kev, Jul 15, 2004
    1. Advertisements

  2. Steve Karnath, Jul 15, 2004
    1. Advertisements

  3. Kev

    Ivo Guest

    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;}

    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.

    Ivo, Jul 15, 2004
  4. It might have been an idea to mention which government as accessibility
    legislation varies across the world.
    This sounds like a requirement to follow the guidelines produced by the
    W3C Web Accessibility Initiative: Web Content Accessibility Guidelines

    Guideline 8. Ensure direct accessibility of embedded user interfaces.
    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.
    9.3 For scripts, specify logical event handlers rather than
    device-dependent event handlers. [Priority 2]

    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).
    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.
    Opening pop-up windows is fundamentally not accessible.
    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 Cornford, Jul 15, 2004
  5. Kev

    Kev Guest

    It might have been an idea to mention which government as accessibility
    Yes. Here is the page in question. Check it out.

    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/Planning Services.

    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.
    There may well be no benefits. It's just for the sake of abiding by the

    Kev, Jul 16, 2004
  6. 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
    cursor:pointer;). (and don't bother arguing that everyone uses IE
    because accessibility *requires* that a site be usable in more uncommon
    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"

    - 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.

    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.
    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.


    [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 ...
    Richard Cornford, Jul 16, 2004
  7. Kev

    Kev Guest

    My impression of this question (and experience of how web site
    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.
    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.
    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.
    It seems to tab ok on this page without getting stuck.

    Kev, Jul 18, 2004
  8. 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.
    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.

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

    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
    Which browser? Opera and Mozilla both show the default arrow pointer.
    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.
    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 Cornford, Jul 18, 2004
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.