Quantcast
Channel: One guideline a day » Principle 2: Operable
Viewing all articles
Browse latest Browse all 4

Guideline 2.1: Don’t forget users without a pointer

0
0

Make all functionality available from a keyboard

When a functionality can be achieved using only the keyboard, other input devices can be used. But, if you use only a mouse or a speech input, assistive technologies will find it difficult to operate it.

Obviously, you can use another input devices to complement the keyboard, and even you are encouraged to do it, but don’t forget that every feature must be operable by a keyboard input.

Criterion 2.1.1 Keyboard

All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user’s movement and not just the endpoints. (Level A)

  • The exception is about the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not.
  • This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.

How to. Mandatory techniques

  • Ensure keyboard control by using HTML form controls and links
  • Provide keyboard-triggered event handlers using both keyboard and other device-specific functions, making actions keyboard accessible by using the onclick event of anchors and buttons, or using redundant keyboard and mouse event handlers

Additional, Advisory Techniques

  • Use XHTML role, state, and value attributes if repurposing static elements as interactive user interface components and add keyboard-accessible actions to static HTML elements
  • Provide keyboard shortcuts to important links and form controls
  • Use unique letter combinations to begin each item of a list
  • Choose the most abstract event handler
  • Use the onactivate event
  • Avoid use of common user-agent keyboard commands for other purposes

Common Failures

  • using only pointing-device-specific event handlers (including gesture) for a function
  • using script to remove focus when focus is received
  • using scripting events to emulate links in a way that is not programmatically determinable

Criterion 2.1.2 No Keyboard Trap

If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away. (Level A)

  • Since any content that does not meet this success criterion can interfere with a user’s ability to use the whole page, all content on the Web page (whether it is used to meet other success criteria or not) must meet this success criterion.

How to. Mandatory techniques

  • Ensure that users are not trapped in content

Common Failures

  • Combining multiple content formats in a way that traps users inside one format type

Criterion 2.1.3 Keyboard (No Exception)

All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes. (Level AAA)

How to. Mandatory techniques

This is the same as Success Criterion 2.1.1, but no exceptions are allowed. Just follow techniques for it. If there is a requirement for analog, time-dependent input, then it is not possible to meet this Criterion.

More info


Viewing all articles
Browse latest Browse all 4

Latest Images

Trending Articles





Latest Images