Opened 4 years ago

Closed 4 years ago

Last modified 3 years ago

#18547 closed defect (fixed)

With new W3C standards, violation on Buttons with presentation role

Reported by: mikeb Owned by: mikeb
Priority: undecided Milestone: 1.7.9
Component: Accessibility Version: 1.10.4
Keywords: Cc:
Blocked By: Blocking:

Description

Check the Implicit ARIA Semantics and their Restrictions in the table [​http://www.w3.org/TR/html5/dom.html#sec-implicit-aria-semantics] As per the new rules, Button type input control role must be one of the following: button, link, menuitem, menuitemcheckbox, menuitemradio or radio. The generated html for the dojo button control has the following markup (pulled from theme tester [​http://archive.dojotoolkit.org/nightly/checkout/dijit/themes/themeTester.html]

<input type="button" data-dojo-attach-point="valueNode" aria-hidden="true" role="presentation" tabindex="-1" data-dojo-attach-event="onclick:_onClick" class="dijitOffScreen" value=""> having presentation role to the button control would occur violation.

Change History (13)

comment:1 Changed 4 years ago by dylan

Unfortunately I'm not sure if it's that simple, because this input element is actually hidden and is intended to be ignored by ARIA intentionally. The hidden input field is simply where the form value is stored so that we can rely on using the browser's built in abilities to get and set all form fields, when really we're making a button from a series of span elements.

When we get to a point with Dojo 2 where we can fully drop IE 8 and earlier support, it will be easy to clean up this markup as we won't have to deal with legacy support, but I don't think making this update is going to provide any immediate benefit, and at worst risks breaking existing behavior. Though perhaps Bill can review and come up with a solution that conforms to the current spec and doesn't break existing behavior?

Also, this role as defined would result in the markup having two ARIA roles for the button, the input field as well as the span:

<span id="dijit_form_Button_2" class="dijitReset dijitStretch dijitButtonContents" aria-labelledby="dijit_form_Button_2_label" role="button" data-dojo-attach-point="titleNode,focusNode" tabindex="0" style="-moz-user-select: none;"> <span class="dijitReset dijitInline dijitIcon dijitIconTask" data-dojo-attach-point="iconNode"></span> <span class="dijitReset dijitToggleButtonIconChar">●</span> <span id="dijit_form_Button_2_label" class="dijitReset dijitInline dijitButtonText" data-dojo-attach-point="containerNode">Simple</span> </span>

I would probably argue that the spec should be changed, as this means you cannot efficiently hide a form field and tell ARIA to ignore it by specifying that it only exists for presentation.

comment:2 Changed 4 years ago by bill

I agree it seems overly picky for the rules to complain about a node with aria-hidden=true.

This is fallout from [21894] and also #11003. Now that we (and Microsoft) no longer support IE6 and IE7, maybe we can replace the outer <span> with a <button>, and get rid of the hidden inner <input type=button> completely.

PS: Oh, but the problem is that rolling back [21894] would also break quirks mode on IE8 and IE9.

Last edited 4 years ago by bill (previous) (diff)

comment:3 Changed 4 years ago by bill

this <input> element is actually hidden and is intended to be ignored by ARIA intentionally.

That's true, and that's presumably why we set role=presentation... but since it also has aria-hidden=true, maybe we can just remove the role=presentation, and fix the violation?

... would result in the markup having two ARIA roles for the button, the input field as well as the span

That's true too, but maybe it's OK. Again, because one of them has aria-hidden=true. So it would end up like:

<span role=button>...</span>
<input type=button aria-hidden=true>

comment:4 Changed 4 years ago by bill

OK, yes, that seems to work fine, at least for JAWS 15 against FF and iOS 8.3 VoiceOver?. I filed a PR at https://github.com/dojo/dijit/pull/88. Mike, do you want to check it before I commit it?

comment:5 Changed 4 years ago by Bill Keese <bill@…>

Resolution: fixed
Status: newclosed

In 464af005d56cdd0286087a325c4887fcc4d993bc/dijit:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

comment:6 Changed 4 years ago by bill

Note that this change rolls back #14397, but that change is no longer needed after #17629.

comment:7 Changed 4 years ago by bill

Milestone: tbd1.7.9

I'll push backports to 1.7 ~ 1.10 next.

comment:8 Changed 4 years ago by Bill Keese <bill@…>

In 111823e90e31fffd4180835c9e2b2ed1d21a1b84/dijit:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

comment:9 Changed 4 years ago by Bill Keese <bill@…>

In 551f4d8525f258a5c1b4b71cffae895fa1df5ae9/dijit:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

comment:10 Changed 4 years ago by Bill Keese <bill@…>

In 05c68059a154930a824e8e92749c07e023ffd112/dijit:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

comment:11 Changed 3 years ago by tomjiang

Hi,

I download the dijit 1.10.4 source code from https://download.dojotoolkit.org/release-1.10.4/, and checked the source code for dijit/form/Button, in the template Button.html, the role="presentation" is still there.

Can you please help to check?

Best regards, Tom

comment:12 Changed 3 years ago by tomjiang

Hi,

From https://github.com/dojo/dijit/commits/master/form/templates/Button.html, I find this defect was actually fixed, and code of the template Button.html for dijit/form/Button was committed on Apr 9, 2015. so this ticket was closed earlier than it's really fixed.

This bug was not fixed in dojo 1.10.4, but fixed in dojo 1.10.6. Please check.

Thanks & Best regards, Tom Jiang, from IBM OpenPages? development team

Last edited 3 years ago by tomjiang (previous) (diff)

comment:13 Changed 3 years ago by bill

Actually, when a ticket is marked as "fixed in 1.7.9", that doesn't mean that it's fixed in 1.8.0, but rather that it's fixed in 1.8.x (and similarly 1.9.y etc.). Unfortunately there's no easy way to know what "x" and "y" are unless I wrote it in a comment in the ticket.

Note: See TracTickets for help on using tickets.