Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Set the ARIA role of button to elements with the data-role="button" attribute #4698

Closed
cannona opened this Issue · 15 comments

5 participants

@cannona

The role="button" attribute is not being set when the data-role="button" attribute is set on a link.

<a href="http://www.google.com/" data-role="button">Google</a>

The above code results in the link being identified as a link, and not as a button by screen readers.

@cannona

Looks like role="button" isn't getting set on the close button for dialogs either. I haven't had a chance to look into the code to see if that's the same issue or a different one, but just thought I'd mention it.

@scottjehl
@cannona

When you say "generally our link-based "buttons" are
often still playing the role of a link", do you mean other buttons within JQuery Mobile, or just in code that uses the library? Do you by chance have an example of where this might be semantically incorrect? What might one gain by marking something up as a button that isn't really a button?

Sorry, I'm not as familiar with this library as I would like to be.

Thanks for your help!

@jaspermdegroot
Collaborator

@cannona

The JQM data-role="button" means that an element gets button styling. It still can be different things: a link that is used to navigate or a button to control something. Only the latter should have role="button".

See:
http://www.w3.org/TR/wai-aria/roles#button
http://www.w3.org/TR/wai-aria/roles#link

@scottjehl

In the button widget I see a comment "add ARIA role" but I don't actually see it being applied. It seems that we never add it so that is something we could look into.

Edit: Collapsible heading should probably get the button role as well.

@cannona

I would recommend looking into it if you don't mind. I think the button role would be appropriate for back and close buttons at the very least. Back buttons are called buttons when read by screen readers, so the precedent certainly exists to designate them as buttons.

@vick08

The same should be done for back buttons in the dialogs.

@jaspermdegroot
Collaborator

@vick08

For 1.4 we are making changes to generated markup for buttons. We are doing this refactor in branch "next". Before we add the code that sets the ARIA attribute, I wanted to check some things with you.

Anchor elements with data-role="button" (including dynamically injected back buttons) should always get role="button", correct?
Button elements will no longer be wrapped in a div, we will just style the native element. Do we need to add role="button" to the button element?
Input elements of type button, submit or reset get a div wrapper and we make the native element transparent. In this case we should add role="button" to the wrapper I suppose. Is it also important that we remove the ARIA role from the native input element in case the developer has added it in the markup?

There are a few other cases in which I am not sure if we need to add a ARIA role. Those are:

  • Anchors that are an immediate child of list items in a list with data-role="listview" are styled as buttons.
  • For collapsibles we inject an anchor element in the heading element and style it as button.
  • Selects are wrapped in a div that is styled as button. The native select element is made transparent (in case of a native menu) or moved offscreen (custom select menu).
  • For checkboxes and radio buttons we style the label element as button. The native input element is behind that button.

I would really appreciate your input here. Thanks a lot!

Update: I changed aria-role="button" to role="button".

@cannona

Button elements, or submit or reset buttons don't need a role of button, as they automatically get that role assigned by virtue of their type.

The other items you listed sound like they should get the role="button" attribute, except for the last. Checkboxes and radio buttons, and in fact all other form elements should keep their natively assigned roles.

If we can come up with a set of tests for all of these cases, I'd be happy to review them with Voice Over on a Mac, Jaws and NVDA on Windows in various browsers, and with voice over on the iPhone, to insure that these changes have the desired effect.

Thanks, and please let me know if you have any further questions.

Aaron

@cannona

After a bit more consideration, I'm not sure on selects, but it might make sense to leave them alone as well. Again, I'd be happy to test.

Aaron

@vick08

As Aaron already alluded, where native tags are used, eg or , no ARIA roles are necessary as we get all the benefit from the native semantics. However, where an element behaves like a button but is not marked as such, the role of button will be appropriate.
I hope that developers will not insert their own aria roles if the documentation clearly says that they are already there.
Also, just in case the correct way to write this is role=button and not aria-role=button; just wanted to make sure we're on the same page.

@jaspermdegroot
Collaborator

@cannona @vick08

Thanks for your input! I will move on with this.

@vick08 - Yeah, I noticed my aria-role="button" mistake and changed it already here on Github

@gabrielschulhof
Collaborator

I have just added the role="button" attribute to the followings:

  • buttonMarkup
  • dialog close
  • custom select close
  • table column toggle
  • back button resulting from the addBackBtn toolbar option

Is that sufficient to close this bug?

@gabrielschulhof
Collaborator

I guess it is :)

@vick08
@cannona

Sorry to have totally missed this. Looks good to me. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.