#keyboard accessible

[aeldata-usa]

How to Make Your Shopify Website More Accessible?

Shopify stores are working to improve accessibility to reach more customers and build loyalty. However, according to Forbes, only 3% of the…

[dboudreau]

Use redundant keyboard and mouse event handlers

Make sure specific mouse event handlers are duplicated to account for the keyboard

It is not uncommon for images and other active objects to change or be modified in response to a mouse event; images appears to be active or inactive, to change color, to be turned on or off. Links change color, or have their presentation altered. Tooltips, sub menus and tab panels fly out as the users’ mouse hovers over them, etc. Authors often fall into the trap of planning great interactions for the mouse, while failing to replicate the same behaviour for users who only use the keyboard. As a result, a lot of those behaviours are lost to anyone who does not or cannot use a mouse. Any effect achieved or conveyed to users as they roll their mouse over an image, graphic or object needs to be conveyed through other means to be considered accessible: so users who cannot use a mouse can still benefit from the planned interaction as well.

To do so, simply make sure that whenever the onMouseover and onMouseout event handlers are used to change a behaviour (when the mouse moves on top of or away from an element on the page) that the onFocus and onBlur event handlers are also relied upon to change the image when the element receives and loses keyboard focus. This is what is commonly called “device independence” – where a particular effect, activated when an object receives focus, and is being triggered, regardless of the fact that the trigger is caused by the users’ mouse or keyboard. By planning the “on” effect on both onMouseover and onFocus, and planning the “off” effect on both onMouseout and onBlur, authors make sure all users, regardless of the fact that they use a mouse or not, will benefit from the same behaviours.

User Story

As a user using the keyboard to navigate, I want planned behaviours to be both mouse and keyboard accessible, so that I can benefit from all planned interactions, regardless of the fact that I can use a mouse or not.

Simple Code Example

Not Applicable

Testing Methodology

For every behaviour or interaction set to an object can be activated or triggered with a mouse, check that the same behaviour or interaction can also be activated or triggered when keyboard focus is set to the object.

Specification Details

WCAG 2.0: Level A

Principle: Operable

Guideline: 2.1 Keyboard Accessible

Success Criterion: 2.1.1 Keyboard

Related Technique: SCR2

Category: Scripting

[dboudreau]

Ensure keyboard focus does not get trapped in content

no. 036

Make sure keyboard users can freely navigate throughout the page

Whenever users navigate through a page using nothing but their keyboard, there’s a possibility to become trapped in a subset of the content that can only be exited using a mouse or a pointing device. Such roadblocks can quickly make progression through content impossible for users with visual or motor impairments, preventing them from using a mouse. Therefore, it is important to ensure that content does not “trap” keyboard focus within subsections of content on a Web page. As a rule of thumb, users should expect to be able to move into, and away form, any user interface component, simply by using their keyboard.

To do so, simply make sure that keyboard focus can be moved inside every component made available in the page and that users can just as easily navigate out of those components, again, using only the keyboard. Whenever leaving a component requires more than just tabbing out of it using the tabulation key, make sure instructions are conveniently provided, so users can effortlessly do so. This will ensure that users who do not or cannot use a mouse will still be able to fully interact with the page nonetheless.

User Story

As a keyboard only user, I want pages to be devoid of keyboard traps, so that I can navigate efficiently, in and out of every page component made available.

Simple Code Example

Not Applicable

Testing Methodology

Using only the tabulation key from the keyboard, tab through content from start to finish. Make sure keyboard focus does not become trapped in any component. If keyboard focus appears to be trapped at some point, verify that help information is made available to explain how to exit the content and that this help can be accessed via the keyboard.

Specification Details

WCAG 2.0: Level A

Principle: Operable

Guideline: 2.1 Keyboard Accessible

Success Criterion: 2.1.2 No Keyboard Trap

Related Technique: G21

Category: General

[dboudreau]

Ensure pages can be fully controlled without a mouse

no. 005

Make sure all functionality of a page can be used with the keyboard only

Due to disability or other reasons, some users cannot or will not use a mouse to navigate through content. Therefore, it is of critical importance that whenever possible, content that can be operated with a mouse can also be made operable with the keyboard. Whenever an object in the page is only usable with a pointing device, it becomes unusable to those who can only operate a keyboard... or don't have access to a mouse.

To do this, simply determine what functionalities are available on the page and make sure they can be equally operated using the mouse, then the keyboard (tabulation key, arrow keys, enter key, space bar, etc.). Any functionality that cannot be operated without a mouse must be made so. Doing so will enable no-sighted users who have no use of a mouse, but also any user unable to use a mouse to also freely reach, control and activate the various page components made available.

User Story

As a user using the keyboard to navigate, I want planned behaviours to be both mouse and keyboard accessible, so that I can benefit from all planned interactions, regardless of the fact that I can use a mouse or not.

Simple Code Example

Not Applicable

Testing Methodology

Using only the keyboard, make sure every active object of the page, including all hyperlinks, form controls and mouseOver effects can be reached, controlled and acted upon.

Specification Details

WCAG 2.0: Level A

Principle: Operable

Guideline: 2.1 Keyboard Accessible

Success Criterion: 2.1.1 Keyboard

Related Technique: G202

Category: General