Scripting

Public Article

Article is certified Certified Article

The content of this article is certified for accuracy by the Digital Accessibility Centre.


Scripts and applets

Example of test image using scripting

Requirements

  • All scripted content can be accessed via assistive technologies or alternative content is offered.

Full explanation

Scripts can be used to enhance user experience as long as they are accessible to assistive technologies.

To ensure accessibility, use either a device-independent event handler (one that works with both the mouse and the keyboard) or use both mouse-dependent and keyboard-dependent event handlers.

onMouseOver, onMouseOut, and onDblClick rely upon the use of a mouse. onKeyDown, onKeyUp is dependent upon the use of the keyboard

Multiple device-dependent event handlers can be used together to allow both mouse and keyboard activation of JavaScript, but this requires testing across different browsers and assistive technologies to ensure that accessibility is not limited in any way.

 

Use...

...with

mousedown

keydown

mouseup

keyup

click

keypress [2]

mouseover

focus

mouseout

blur

Note: Some mouse-specific functions (such as dblclick and mousemove) do not have a corresponding keyboard-specific function. This means that some functions may need to be implemented differently for each device (for example, including a series of buttons to execute, via keyboard, the equivalent mouse-specific functions implemented).


On Focus

3.2.1  On Focus (A)

When any user-interface component receives focus, this must not trigger an automatic change of context (which is not the same thing as a change of content). People get disoriented when the context changes unexpectedly; for example, a new web page opens when the focus moves to a certain bit of content. This test reduces the chance of an involuntary change of context.

Test at the same time

How to test

  1. Open the web page to be tested. Check that a new window or browser Tab does not open when you load the page.
  2. Start with focus at the top of the page (in the address bar) and use the Tab key to move through the page from focusable element to focusable element, e.g. button, link, form field, etc. With each stop in the Tab order, check that nothing unexpected happens, e.g. no new windows, browser tabs or pop-ups appear; focus doesn’t jump somewhere else on the page.
  3. If there is a form on the page, use the Tab key to move focus through all its inputs and controls. If a drop-down list gets focus, change the currently selected option, then move focus out of the drop-down. Check that no pop-ups or new pages load, or that focus moves unexpectedly, simply when moving focus to or from a form control. Correctly fill in the form and change the value of the last control, and then use the Tab key to move focus away from that control. Check that the form does not automatically submit. Note that if anything changes when filling in a form (e.g. more fields appear because you selected a country), this is not a change of context because it extends the content of the page, but does not change the meaning of the page overall.

Potential access issues

  • Removing the focus from an element as soon as it gets focus.
  • Simply moving focus to or from an element on the page causes an unexpected change of context.

On Input

On Input (A)

Changing the setting of a user interface component (e.g. selecting a radio button) must not automatically cause a change of context unless the user is warned that the change will occur.

Note that while links, buttons, or tabs in a tabbed interface are considered user interface components, activating (e.g. clicking on) such a component is not considered to be changing its setting to ensure that simply changing the setting of a component (e.g. checking a checkbox, selecting a value from a drop-down list or entering text in a field) does not cause an unpredictable effect such as launching a new web page.

Unexpected changes in context can disorient users.

Test at the same time

How to test

  1. Open the web page to be tested.
  2. If the page has a form, fill it in. Enter data in each field. Select all radio buttons and checkboxes. Open each drop-down list and select a value. Check that at no point is the form automatically submitted or a change in context occurs without warning.
  3. With any other user interface component on the page, change its setting and check that no change of context occurs without warning.
  4. If there is a change in context upon changing the setting of a user interface component, check that instructions or a warning about the change of context are provided before the component or such that a user can find it before interacting with the component.

Potential access issues

  • A form is submitted as a consequence of entering text into an input, checking a checkbox or radio button, or selecting a value from a list.
  • A new window is launched without prior warning when someone selects a radio button or checkbox.
  • Instructional material or warnings about changes in context are located after the component that triggers the change in context when its setting is changed or is located such that a user won’t come across it before interacting with the component.

Scripting was posted on 06/02/2023 @ 15:29