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

Closed
cannona opened this Issue Jul 13, 2012 · 15 comments

Comments

Projects
None yet
5 participants
@cannona

cannona commented Jul 13, 2012

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

This comment has been minimized.

Show comment
Hide comment
@cannona

cannona Jul 13, 2012

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.

cannona commented Jul 13, 2012

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

This comment has been minimized.

Show comment
Hide comment
@scottjehl

scottjehl Jul 13, 2012

Contributor

I think we do set it to role=button in cases where it makes sense (maybe within some of our other controls?), but generally our link-based "buttons" are often still playing the role of a link, so I'm not sure this change would make sense broadly. Perhaps it'd be better to do this manually when you have to use anchors in a button-like situation (form controls, widgets, etc).

Thoughts?

On Jul 13, 2012, at 5:01 PM, Aaron Cannon wrote:

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

Google

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


Reply to this email directly or view it on GitHub:
#4698

Contributor

scottjehl commented Jul 13, 2012

I think we do set it to role=button in cases where it makes sense (maybe within some of our other controls?), but generally our link-based "buttons" are often still playing the role of a link, so I'm not sure this change would make sense broadly. Perhaps it'd be better to do this manually when you have to use anchors in a button-like situation (form controls, widgets, etc).

Thoughts?

On Jul 13, 2012, at 5:01 PM, Aaron Cannon wrote:

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

Google

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


Reply to this email directly or view it on GitHub:
#4698

@cannona

This comment has been minimized.

Show comment
Hide comment
@cannona

cannona Jul 14, 2012

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!

cannona commented Jul 14, 2012

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

This comment has been minimized.

Show comment
Hide comment
@jaspermdegroot

jaspermdegroot Jul 14, 2012

Member

@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.

Member

jaspermdegroot commented Jul 14, 2012

@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.

@ghost ghost assigned jaspermdegroot Jul 14, 2012

@cannona

This comment has been minimized.

Show comment
Hide comment
@cannona

cannona Jul 18, 2012

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.

cannona commented Jul 18, 2012

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

This comment has been minimized.

Show comment
Hide comment
@vick08

vick08 Apr 1, 2013

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

vick08 commented Apr 1, 2013

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

@jaspermdegroot

This comment has been minimized.

Show comment
Hide comment
@jaspermdegroot

jaspermdegroot May 2, 2013

Member

@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".

Member

jaspermdegroot commented May 2, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@cannona

cannona May 2, 2013

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 commented May 2, 2013

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

This comment has been minimized.

Show comment
Hide comment
@cannona

cannona May 2, 2013

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

cannona commented May 2, 2013

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

This comment has been minimized.

Show comment
Hide comment
@vick08

vick08 May 2, 2013

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.

vick08 commented May 2, 2013

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

This comment has been minimized.

Show comment
Hide comment
@jaspermdegroot

jaspermdegroot May 2, 2013

Member

@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

Member

jaspermdegroot commented May 2, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof Jul 17, 2013

Contributor

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?

Contributor

gabrielschulhof commented Jul 17, 2013

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

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof Jul 17, 2013

Contributor

I guess it is :)

Contributor

gabrielschulhof commented Jul 17, 2013

I guess it is :)

@vick08

This comment has been minimized.

Show comment
Hide comment
@vick08

vick08 Jul 18, 2013

Sounds about right to me.
Thanks a lot for doing this.


Find me on Twitter http://www.twitter.com/vick08

On Jul 17, 2013, at 7:53 AM, gabrielschulhof notifications@github.com wrote:

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?


Reply to this email directly or view it on GitHub.

vick08 commented Jul 18, 2013

Sounds about right to me.
Thanks a lot for doing this.


Find me on Twitter http://www.twitter.com/vick08

On Jul 17, 2013, at 7:53 AM, gabrielschulhof notifications@github.com wrote:

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?


Reply to this email directly or view it on GitHub.

@cannona

This comment has been minimized.

Show comment
Hide comment
@cannona

cannona Nov 26, 2013

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

cannona commented Nov 26, 2013

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