Reputation: 11
The exact confusion I have is the following
On one hand WAI-ARIA provides the 5 rules as a practical guide for authors to use WAI-ARIA (the document isn't a W3C recommendation though), and there according to the first rule one can use the presentation role since the feature is not currently available in html5.
Also, according to the second rule one is allowed to change the native semantics of the elements if one desires, in other words it at least won't be technically incorrect according to the rules.
Lastly, according to fourth rule, the only exception where presentation role shouldn't be used is on a focusable element. And it also provides a clear example that one can make an interactive element unfocusable by using the tabindex attribute with negative value. (last code in section 2.4).
<button {opacity:0}>
<button tabindex="-1" aria-hidden="true">press me</button>
And hence now, according to the rules, the element, although interactive, should be able to be comfortably assigned with a presentation role.
But then there's also this W3C recommendation, ARIA in HTML, which defines the authoring rules (author conformance requirements) for the use of WAI-ARIA attributes in HTML. Now it provides a table which explicitly states what roles any particular element can be assigned, and many elements can only be assigned a few roles, which according to me violates what the five rules of ARIA, as discussed above, imply (which is that any element can be assigned any role, with few minor exceptions). For example this is what the dialog
element can be assigned. We can't assign it a presentation role.
And as expected, even if we try to assign any other role to the dialog
element the Nu html conformance checker throws an error.
My doubt is the following
Is the reason that we can't apply presentation role, even if five rules of ARIA allow us to do that, that the W3C recommendation - ARIA in HTML, is authoritative and have the topmost preference when it comes to aria in html ? if no then what is the actual reason
Also, even if it's a violation to the specification, isn't the aria role attribute of topmost priority to the Assistive technologies when it comes to determining the role of an element? After all, we can assign any role to a reasonably many of the HTML elements having native semantics, as one can see in the table provided in that W3C recommendation spec. And so can't we just assign the role ANYWAY, given that we ensure that the dialog
element is no longer focusable ?
Since the element won't be focusable and its role would be presentation, I personally can't see if ATs should have any ambiguity accessing it, and it also seems semantically correct just nonconforming apparently.
Upvotes: 1
Views: 74
Reputation: 2707
First of all, the following statement in the question is not quite accurate:
according to the second rule one is allowed to change the native semantics of the elements if one desires.
What the second rule of Using ARIA says is the following:
Do not change native semantics, unless you really have to.
In other words, assigning a role or overwriting a native role should only be done if there is a good reason for it. The most common reason is that HTML does not natively provide all the roles you need for custom components such as menus, tooltips, comboboxes etcetera. Another reason is that you sometimes need to suppress an element's native semantics, for example, when you use regular list elements for a menu, you will usually assign role="presentation"
to the li
elements because the buttons or links will serve as the actual menu items (because they are natively keyboard focusable).
HTML's dialog
element natively has the dialog
role. You want role information to be available to assistive technologies (the AT can then still decide whether to announce the "dialog" role or not). This is why it shouldn't get role="presentation"
, i.e. assuming you are using the element for an actual dialog. (And using the role
attribute just to duplicate an element's native role is a waste of time and resources.)
If you think you need role="presentation"
, then you probably aren't implementing a dialog and you shouldn't use the dialog
element to begin with.
Upvotes: 0