Overview
WAI ARIA global attributes(states and properties) are the attributes that can be defined for any host language element whether role is applied or not. Let me explain this with simple example. Aria-label(property) is the global attribute as per the specification. Since aria-label is global attribute, author can define this attribute for any host language element(such as <div>, <span>, <a>, <button>, and so on..). Apart from that, global attributes are also applicable for any base roles (such as role=”link”, role=”button” and so on..). To put it in the technical terms, global attributes inherits into any host language elements as well as any ARIA roles. The following are the list of the global states and properties’ that are applicable for any base markup and any role. This list is based on the aria 1.1 specification and this list may subject to change depending on the future versions of aria
- aria-atomic
- aria-busy (state)
- aria-controls
- aria-current (state)
- aria-describedby
- aria-details
- aria-disabled (state)
- aria-dropeffect
- aria-errormessage
- aria-flowto
- aria-grabbed (state)
- aria-haspopup
- aria-hidden (state)
- aria-invalid (state)
- aria-keyshortcuts
- aria-label
- aria-labelledby
- aria-live
- aria-owns
- aria-relevant
- aria-roledescription
Complementary info on the aria global attributes versus presentational role
As discussed in the none role/presentational role blog post, presentational role negates the element semantics. However, there is an exception to this. The exception is that When presentational role(role=”presentation”) is defined on the element that has implicit native semantics as well as the global attributes then assistive technologies ignore the presentational role and exposes the element’s role/semantics. Let us look into this with sample code snippets.
Sample code snippet
<!—1. [Role=”presentation”] is ignored due to the global aria-haspopup property and as a result, assistive technologies expose the heading semantics. –>
<h1 role=”presentation” aria-haspopup=”true”> Sample Content </h1>
<!– 2. [Role=”presentation”] negates the both the implicit ‘heading’ and the non-global level as there are no global attributes. –>
<h1 role=”presentation” aria-level=”2″> Sample Content </h1>
Sample Content
Isn’t this example wrong? The role=heading is not provided & providing role=presentation without the role=heading with aria-level doesn’t work… Am not sure how role=presentation is making any differentiation here on the example.
Sample Content
Even this example seems wrong… Why do we provide haspopup for a heading tag?
Hello Jeremy,
Thank you for your feedback.
Please see my comments in the inline below
your question: Sample Content
Isn’t this example wrong? The role=heading is not provided & providing role=presentation without the role=heading with aria-level doesn’t work… Am not sure how role=presentation is making any differentiation here on the example.
Suman: Great question. As per the specification, we can use the non global attributes(ex: aria-level) if it have corresponding HTML implicit semantics too. here, the tag
has the implicit semantics of heading and we can absolutely use aria-level without using of role=”heading”. hope it is clear
your question: Sample Content
Even this example seems wrong… Why do we provide haspopup for a heading tag?
Suman: As mentioned in this blog post, aria-haspopup is global attribute which means we can use for any kind of base markup. only the condition is the element that has aria-haspopup must be focusible. There might be situations in the rich applications where element may act as both heading and submenus. in fact, i have seen these kind of implementations in my experience.
Please let me know if you may have any other queries.
Thank you.
I just commented on your query and please see my comments on the blog post in the comments section. you would have not got notification for some reason.
Just want to add some important details here.
aria-label and aria-labelledby are prohibited for some roles/element types.
If you put them on a span (or most inline elements) or a div (or anything with an implicit “generic” role), they probably wont work, and strictly speaking, it would be invalid use of aria. (Therefore a possible violation of WCAG SC 4.1.1 Parsing).
More complete details about constraints on these naming attributes here:
https://html5accessibility.com/stuff/2020/11/07/not-so-short-note-on-aria-label-usage-big-table-edition/
aria-flowto has very poor (almost non-existent) support from browsers and assistive tech. There has been talk of deprecating this attribute, although it has a genuine use case, unmet by any other attribute or standard. The real problem is that it is does not have a proper spec which could guide browser/AT vendors and content creators.
aria-owns is not (yet) supported by Safari/VoiceOver. This attribute is fundamental to the accessibility of the pdf.js library (so far, this is the only pdf viewer which supports PDF/UA semantic tags).
aria-controls and aria-haspopup are encumbered by a various limitations, constraints and both have underspecified behavior.
Finally, global use of the following attributes is deprecated since ARIA 1.2
aria-disabled
aria-errormessage
aria-haspopup
aria-invalid
… so you’ll need to read up on those to discover where you may use them, and where they are forbidden.
Thank you for this information. will update the things as per the latest specification aria 1.2