Widget Roles
The next type of content is widget roles. And widget roles are basically more complicated components. And there are two types of widget roles, or two types of widgets actually. One is composite widgets and the other one is standalone widgets.
Composite widgets generally consist of multiple standalone widgets. So for example, if you have a menu, you have menu items inside of that. And so the menu can't exist on its own. It has to have a menu bar in it. It has to have menu items in it.
And just FYI, menu here means file menu, edit menu, view menu.
It does not mean navigation like you have it on a normal website.
You don't need to use any of these roles for that.
Just use navigation, nav element, and then just a list inside of it and you're good.
But these are really like more complicated widgets.
Like a combo box would be if you have a search and that has like recommendation underneath it.
Grid is something like Calendar where you can basically two-dimensionally interact with the individual grid items.
Yeah, and then there's RadioGroup, which you already know from our RadioGroup examples for forms.
So this is also in here.
You never need that because you just use HTML radio groups.
And then there is TabList and Tree and TreeGrid.
Um, now, because this is depending on Windows 98 technology, um, one of the things that happens is that newer operating systems or different operating systems might not have concepts for some of the things in these APIs.
So this is especially true for tree and tree grid.
On macOS or iOS, tree and tree grid basically do not exist at all.
It's just not a concept that is in the language of these operating systems.
So that means if you specify that using ARIA, it might not come out to the user as a useful information.
And indeed, like the trees and tree grids, they are basically useless on non-Windows 98 type operating systems.
I think modern Windows has tree grids occasionally, but it's for sure less of a concern as it was.
There are many more standalone widgets, things like buttons, radio, progress bar, slider, tabs, tab panels, stuff like that.
So these are standalone widgets that can be inside of composite widget, but they don't have to be.
Some of them need to, some of them do not.
For example, a button can exist outside of a composite widget, but a menu item cannot.
Many widget items also have direct HTML equivalents.
These implicit roles are, for example, a button has the implicit role of button, an input
type radio has an implicit role of radio, and so on and so forth.
So it's not that you have to know about those widget roles as much as long as you keep using
good HTML.
I wonder if my plea for using good HTML crosses over.
That already checks off widget roles.
I'm not going to go into detail here.