HTML5 Accessibility Chops: Just use a (native HTML) button

Many User interface widgets can be developed using HTML, CSS and JavaScript, in some cases developers build custom versions of native HTML controls because they cannot achieve the exact look and feel or behaviour they desire with a native control.
Where ever possible it is recommended that native HTML controls be used over custom controls as their accessibility support is likely to be more robust and it’s much less work.

However, if you do have a need to develop a custom control there are a number of steps you will have to take to ensure it is accessible. In HTML5 it is conforming to use ARIA to help in the creation of an accessible custom control.

A standard button (input type=”button”)

code:

<input type="button" value="search" onclick="alert('submitted');">

Example requirements for creating an accessible custom control

Note: The following is a demonstration of the steps to create an accessible custom button. It is not recommended that:

  • a custom button is created using an image.
  • a custom control be used instead of a native HTML control (unless accessibility support is not implemented for a particular control.)
  • event attributes are added inline.

Starting with an image

NOTE: the use of an image is for demonstrating the steps required to make a non interactive HTML element into an accessible interactive element. If you want to create an image based control use input type=image.

The image below looks and acts like a button for mouse users who can see, you can click it and something happens and  it has a label.

For other users there are problems:

  1. it only has a visual label.
  2. it’s identified in the code as an image not a button.
  3. it cannot be used with the keyboard
    1. it is not focusable
    2. it does not respond to the expected keys for activating a button

code:

<img src="button.gif" onclick="alert('submitted');">

1. Adding an accessible label

An accessible label can be added to the image using the alt attribute.

search

Code:

<img src="button.gif" alt="search" onclick="alert('submitted');">

Reference:

HTML5: Techniques for providing useful text alternatives

2. Adding a role to identify the control

To provide the correct identity for the element so users of assistive technology are aware they are dealing with a user interface element that has the behaviour of a button, not an image the WAI-ARIA button role can be used.

Note:adding a button role does not make the element operable as a button for assistive technology or keyboard users. It only identifies the element as a button and AT may provide some usage instructions. For example, when the element receives focus (see step 3.A. below) a screen reader such as JAWS will announce “search button, press spacebar to press.” Unless you add the required keyboard behaviour (step 4.B. below) it will not be usable!

search

Code:

<img src="button.gif" alt="search" role="button" onclick="alert('submitted');">

3. A. Navigation via the keyboard

To provide access to the control for  keyboard users, it must be focusable and in the tab order of the page. To do this tabindex with a value of “0” can be  added. This puts the element in the default tab order of the page.

search

Code:

<img src="button.gif" alt="search" role="button" tabindex="0" onclick="alert('submitted');">

Reference:

Using Tabindex to Manage Focus among Widgets (WAI-ARIA)

3. B. expected keyboard behaviour for buttons

A native HTML button has 2 keys associated with it that will operate it: The enter key and the space. You will need to add scripting that listens for these keys being pressed and activates the custom button action.

search

Code:

<img src="button.gif" alt="search" role="button" tabindex="0" onkeypress="if(event.keyCode==32||event.keyCode==13){alert('submitted')};" onclick="alert('submitted');">

Reference:

Button design pattern (WAI-ARIA)

Other considerations:

Categories: Technical
Tags:

About Steve Faulkner

Steve was the Chief Accessibility Officer at TPGi before he left in October 2023. He joined TPGi in 2006 and was previously a Senior Web Accessibility Consultant at vision australia. Steve is a member of several groups, including the W3C Web Platforms Working Group and the W3C ARIA Working Group. He is an editor of several specifications at the W3C including ARIA in HTML and HTML Accessibility API Mappings 1.0. He also develops and maintains HTML5accessibility and the JAWS bug tracker/standards support.

Comments

Hi Steve,

The heading “Creating a custom button” scares me a little as I’m afraid some people could look at this as a “tutorial” to create accessible custom buttons when in fact it is a technique to make legacy custom buttons accessible.

I don’t see this article as a DEMONSTRATION, but rather as a tutorial about how to make legacy code more accessible while reducing the risk of breakage – since the enhancement is done via attributes and does not require a change of element in the markup.

Steve Faulkner says:

Hi Thierry, I have changed the wording a bit, see what you think?

Anything that keeps people from thinking that’s the way to build something from scratch is good 😉

As a side note, I think you have a couple of typos: “creationg” and “steps to create to an accessible”.

Thanks Steve!

Steve Faulkner says:

Thierry wrote:
“As a side note, I think you have a couple of typos: “creationg” and “steps to create to an accessible”.

Fixed!