RE: Making ARIA and native HTML play better together

From: Steve Faulkner [mailto:faulkner.steve@gmail.com] 
Sent: 07 May 2015 06:42

On another thread recent thread, leonie and chaals [3] talked about adding behaviours to ARIA. Here are a few ideas:

1. When a role is used that matches the default implicit semantics of labelable HTML elements [1] use of the label element will result in the same behaviour as the native element and a <label>.

Example:

<span role="checkbox" id="customcheck"></span> <label for="customcheck">i like this idea</label>


User able to click on label to check/uncheck 

 

If we did attempt to break the fourth wall of ARIA, this would be a good first step. I don’t think it would cause backwards compatibility issues, but it could improve the usability of such controls for keyboard users.

2. roles that match the default implicit semantics of interactive elements are focusable (without need to explicitly set tabindex)

Example:

<div role="button">press me</div>

will be included in the focus order.

 

3. roles that match the default implicit semantics of interactive elements [2] inherit the interaction behaviour of the native elements

example: 

<div role=button>press me</div>

can be activated the same way a html <button> element can be:.

via space, enter ,click , touch or whatever.

 

This is where things start to get more complex. If we could get the browser to throw in keyboard support for free, it might be a step in the right direction though.

 

With a custom button it’s necessary to provide both mouse and keyboard event handlers/listeners. If you use a native <button>, the browser automatically provides the keyboard support.

 

What if the browser provided the equivalent keyboard behaviour based on the presence of role=”button”, and the behaviour defined by the mouse handler?

 

 

Léonie.

 

 

-- 

Léonie Watson Senior accessibility engineer, TPG

@LeonieWatson @PacielloGroup PacielloGroup.com