A question on "implied" roles

27 views
Skip to first unread message

Rick Brown

unread,
Jul 27, 2014, 8:34:41 PM7/27/14
to free...@googlegroups.com
I'm looking for an answer - hoping someone here can help.

0 points for opinion.
1 points for reference to W3C documentation.
Infinity plus one points for a normative spec reference.

The fundamental question is "can aria attributes (states and properties) be used on elements with no aria role"?
Global attributes, obviously yes.
aria-required, yes in some cases.

To illustrate my question take the role of button as an example:

A stateless button should not be implemented like this because one should "use the host language feature" when available
<button role="button">Click to do stuff</button><!-- This is definitely wrong -->

That said, the HTML button is a good choice for a toggle button because we should use "a host language feature that is as similar as possible to the WAI-ARIA feature".

But how should a stateful button (toggle button) be implemented???

Option #1
<button role="button" aria-pressed="false">Click to toggle</button><!-- Some may argue the role attribute is wrong because the host language feature implies it already -->

Option #2
<button aria-pressed="false">Click to toggle</button><!-- Some may argue the aria-pressed attribute is illegal without a button role -->

Personally I think Option #1 is the correct implementation but I can find no way to prove this conclusively in the spec. Nowhere does it say anything like "aria states and properties must only be used on elements with a role attribute".

Rick Brown

unread,
Jul 27, 2014, 9:13:15 PM7/27/14
to free...@googlegroups.com
BTW the spec nearly says not to use non-global states and properties on elements without an explicit role: "Use of a given state or property is not defined when used on roles other than those listed."

Bryan Garaventa

unread,
Jul 27, 2014, 10:26:01 PM7/27/14
to free...@googlegroups.com

I believe what you are looking for is this:

http://www.w3.org/TR/wai-aria/host_languages#implicit_semantics

 

Yes, the native control type is sufficient, because the native Role matches that of the ARIA Role, so using the ARIA Role at the same time is superfluous.

 

For example, I took the following code:

 

<button aria-pressed="true">

Test

</button>

 

And checked the Accessibility Tree object for this control in IE11 and in Firefox, and it shows correctly as a “push button” that has a state of “PRESSED”.

 

If it helps, the following guide may help if you would like to perform the same test:

http://whatsock.com/training

 

Best wishes,

Bryan

--
You received this message because you are subscribed to the Google Groups "Free ARIA Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to free-aria+...@googlegroups.com.
To post to this group, send email to free...@googlegroups.com.
Visit this group at http://groups.google.com/group/free-aria.
For more options, visit https://groups.google.com/d/optout.

Rick Brown

unread,
Jul 28, 2014, 5:43:58 PM7/28/14
to free...@googlegroups.com
Thanks Bryan, that is very helpful and thanks for doing the experiment - sometimes I wonder if the theory and the practice align, good to hear they do in this case at least.
It does mean I need to go do some more work on my validator project because it currently insists on explicit roles.
You get infinity plus one points from me.
RB

Bryan Garaventa

unread,
Jul 28, 2014, 7:14:39 PM7/28/14
to free...@googlegroups.com
No problem :)

One thing to keep in mind for interactive ARIA widgets, is the placement of focus, and supporting attributes. For instance, if the parent Role such as role=menu has focus and the arrow keys change selection, then aria-activedescendant is required for pointing to the relevant selected role, but if focus is moved between the elements with role=menuitem, then aria-activedescendant should not be included. This is true for all of the interactive widget types that support aria-activedescendant with their child roles.

Basically, if this is ignored, you will have a bunch of widgets that have the correct roles, but are still inaccessible when used by ATs.

Rick Brown

unread,
Jul 29, 2014, 11:12:23 PM7/29/14
to free...@googlegroups.com
Good point Bryan, thanks.
I'll think about whether or not I can get the validator to check that once I've fixed the whole implicit role thing.
In my own work I tend to move focus 99% of the time - it tends to make development easier in my experience.

Bryan Garaventa

unread,
Jul 30, 2014, 5:22:33 PM7/30/14
to free...@googlegroups.com

No worries, I know it is complicated.

 

One possible way to do this is to identify the interactive widget types and the associated parent/child roles, check whether tabindex is equal or greater than 0 on the parent role element, if yes, verify if aria-activedescendant is present and points to a valid child role element. Then, if tabindex is also set to a value equal to or greater than 0 on a child role at the same time, this would be flagged since it shouldn’t.

 

Also, if there is no tabindex on a parent widget role element, check if there is one child role element that includes a tabindex value equal to or greater than 0, which is necessary to ensure keyboard accessibility. This can also be extended to check that other child role elements include tabindex=”-1” to ensure that the widget has one tab stop.

 

Unfortunately there is no way to make this bullet proof, since it’s impossible to guarantee that other active elements besides those with valid child role attributes are not also present, or that other focusable elements are not also included as part of the widget functionality but have no valid child roles, etc.

 

This is one of the biggest problems with automating interactive widget validation, paring the correct scripting functionality with the correct role mappings on the correct elements, and ensuring that other elements in the structure aren’t skewing the results unpredictably.

 

I’m not trying to be a downer or anything, but like I said, I know it’s complicated J

Reply all
Reply to author
Forward
0 new messages