<button role="button">Click to do stuff</button><!-- This is definitely wrong -->
<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 -->
<button aria-pressed="false">Click to toggle</button><!-- Some may argue the aria-pressed attribute is illegal without a button role -->
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:
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.
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