All above combined

Hello and welcome to the Way Aria week. This is like super technical and this will be a little

bit more like upfront talking about what the different concepts are and then in the live

tutoring session, we are going to go and basically go into the details to look at different stuff and

talk about it, because that makes much more sense than doing it in this, like, you know,

with basically a wall between us. So that's the plan. Let's kick it off with talking about what

is WAI-ARIA. It's one of the longer specifications from W3C and it stands for Web Accessibility

Initiative Accessible Rich Internet Application. Now you might be wondering why does it have the

WAI in front of it? Why isn't it just ARIA? And the reason is that there were like trademark issues

or something like that, so they couldn't use just ARIA.

So they added the way dash before it just to make sure that that works.

So in general, we will just call it ARIA, and I will probably call it ARIA from now on.

And what is ARIA?

That's always the question, of course.

Accessible Rich Internet Application doesn't mean they make you rich.

as much as I would love that this was the case.

It basically means that there are rich interactions with internet applications,

with web applications that you can specify.

So when you have more in-depth interactions with the user interface,

then you can translate those states and properties and roles and names,

I will talk about all of that, to assistive technology more efficiently.

Yeah, so it makes the various elements of the user interface compatible with assistive

technology. So you can basically be more precise than just using HTML. HTML works great and should

always be your default, I will talk about that too, but it allows more nuance for assistive technology.

Now there is a caveat though, and that is that WAI-ARIA is designed to align with the web

interaction with Windows 98 accessibility APIs. Now I don't know if you noticed, but few people

are using Windows 98 these days, mostly because it's 24 years old. And so that's a little bit of

a problem. And the other problem is that this is not only accessibility APIs, but it's specifically

screen reader accessibility APIs. So everything we're talking about is mainly, or was initially

mainly aimed at screen reader users. And that is, of course, a little bit of a problem because

the accessibility is so much broader than just screen reader users. So we have to keep that in

mind. And that means that a lot of things are happening in there. I made a little diagram.

So that shows basically how ARIA helps to make sure that there is a good input and output for assistive technology.

So in the browser, we have HTML and CSS and JavaScript.

HTML and CSS basically build the accessible object model.

That's basically a representation of what's on the screen.

So if something is hidden, gets removed from the accessible object model.

If something is put in, put back in, it's added to the accessible object model and so on.

And JavaScript interacts with the accessible object model, sometimes by changing CSS, sometimes by changing HTML.

And the browser interprets all of that.

And that is basically where ARIA comes in.

Because you can in your HTML, or let's keep it just there.

So the browser interprets that all, then hands it over to an accessibility API.

And that accessibility API hands it over to assistive technology for interpretation, output, and input.

And then it goes back to the accessibility API and back to the browser.

Now where ARIA comes in is that you are basically inside of the Accessible Object Models, you

are defining things for the Accessibility API specifically.

Like you say, this is a button and then the HTML will interpret that as a button.

It will be in the Accessible Object Model and that will be transferred to the Accessibility

API.

And so you have this like more control over what happens.

So ARIA informs the assistive technology how to interpret content and UI.

You can be like normative.

You can say like, yeah, you have to read this as this.

And that means that there is no meaningful error correction or anything like that.

You basically tell ARIA that this is what you do and this is what you want.

And then it does that.

And ARIA can be used in many different technologies.

So ARIA is not just for HTML and CSS, which will be what we're talking about today mostly.

But it is also applicable to like EPUBs or mobile applications.

whole like whatever you have user interfaces, you can use ARIA technology and sometimes ARIA directly

to reveal what is going on there and basically specify more directly what's going on.

So for the specification, we have a couple of different sections. It's a very, very

complicated specification. I will not even click on the link because I think it's like

a little bit too much and we will talk about all the aspects but I will like basically pick out

smaller things that are interesting for you and that you can use. And the current

version is ARIA 1.1 but everyone says like yeah there was a bit of a miss of how it worked out so

So please look at ARIA 1.2, which is a W3C candidate recommendation draft since December 2021.

So about a year and a bit.

And it might get to a recommendation in April 2023.

So that might happen.

Let's cross our fingers and hope for the best.

But yeah, so everything I talk about is already ARIA 1.2 because ARIA 1.1 had some things in it that just didn't work as well.

And they have been corrected now.

And all of the browsers and assistive technology, they all look at ARIA 1.2.

So, you know, it doesn't make any sense to look at ARIA 1.1.

And that's good.

You know, it's good that we have this correction.

Now, for ARIA, from an ARIA standpoint, you always have three distinct pieces of information that every interactive UI component needs.

And that is what type it is.

Is it a button? Is it a link? Is it a navigation? Is it a dialog? Something like that.

and the name of that information, of that content.

So if you have a button that closes, you know, the name of that button should be close.

If you have a link that goes to the homepage of Chas, then it should be Chas homepage, the name of the link, stuff like that.

So pretty straightforward, actually.

And then there are different properties of content.

And the properties are mainly there to point at different states and properties.

And that means that you can say, for example, this button is in a pressed state or this link is the current link.

Those are examples we will talk about a little bit really soon.

So, yeah, so that's basically the properties can be and you can have multiple properties on one thing.

So you could, for example, have, thinking of something that is good, a link that is, a button that is pressed.

And also because the website is like getting more information, that button might also be busy.

So it would say like button pressed busy, for example.

so i have talked about the types of content and these are defined as roles so every user interface

component and component is like very vast thing that they are using every user interface component

has its role what it does what is the type of it and there are six roles defined and we go through

all of them and we start with one but we won't do it linearly because that's that's like it's not

not a good order of things so i will i will step you through but the first one is number one is the

abstract roles definition uh yeah and this is the order as it is in the uh specification i wanted to

keep that you know for you so you don't have like any needs to search around let's start with

abstract roles so abstract roles are utility roles that are used in the background you don't need to

know about them really ever i have never used them i don't know really what they do they are mostly for

browser implementers screen readers to have something where they you know don't have to do

everything for every role at once but that they can use to replicate and then like go from there

so as i said as this says basically this is abstract and you don't need to know them

There are a couple of those that you might recognize, like the landmark abstract role or the widget abstract role.

So that's basically where other roles are going to have their foundation on.

But as I said, like how they fit together, it's like for practical creating websites, testing websites, it doesn't matter at all.

Like this is completely irrelevant stuff.

So forget all of this.

Okay, check.

Let's go to the landmark roles next.

Landmark roles are important because they basically give you an overview of the site.

If you are a screen reader user, you can get a list of all the landmark roles.

And these are the landmark roles that exist.

It's only like a handful and a bit.

So there's banner, complementary, content info, form, main, navigation, region, and search.

And you would say like, huh, didn't we talk about those in page structure?

Yes, we actually did.

We did talk about the HTML equivalents.

And this is like an important concept because you, in general, don't want to talk ARIA directly, as I have said.

And a lot of things are actually built into HTML that are then reflected in ARIA.

And let's look at the page structure stuff.

So if you have a banner landmark role, you can just use the header element.

And that is equivalent because the header already has built in the banner role.

So the browser knows that this is what it has to give to the assistive technology, to the API.

The same goes for the content info role.

You can just use a footer.

Main has a main element equivalent, and you can use those only once because that's how it's specified.

It makes only sense to have one main content.

If everything is a main content, nothing is a main content.

And then we have complementary. Complementary is one that can be used as many times as you want.

And you can use the HTML aside element to achieve the same semantics basically.

And there are a couple more. Navigation is reflected in the nav element,

So you can use an infinite number of nav elements, forms, you can use an unlimited number of those,

then use the form element, search is a form with a role search. You can also use, technically,

you can use other elements with the role search, but in general you have a search form, so just

Just put it on the form.

And then region with a section is every section is a region.

And if you put an accessible name on it, for example, using ARIA label or ARIA labeled by, then it becomes a landmark.

It's not a landmark technically if it's only just a section element because people started using sections for everything.

And that's not a good thing because then, as I've said with the main, you then have landmarks everywhere and you can't pick out what really sticks out there.

So these are the landmark roles, just these eight.

And they have direct HTML equivalents that you should use.

Check off. The next ones are document structure roles. And now we would say like,

doesn't the landmark role structure documents? Yeah, that's true. But these are like more

detailed. So document structure roles are basically for mostly for text structure. And there are a lot

of them. As a matter of fact, most of them you will never use at all. So I have them listed here,

this is page one of two. So you never want to use application, you never want to use article,

because there's an article element, there's a blockquote HTML element, caption cells,

you know, these are all pretty much reflected in HTML. And one reason that they are in ARIA 1.2

is because some smart people, I guess, have looked at HTML and said like, oh, we need to pick

all of these document structure, text structure things and put them into ARIA as well. So if we

are using a technology that is not HTML like PDF, we can say, oh, for your image, please specify an

IMG role or for your list, specify a list role. Technically, you should never need to use those.

The one thing that I sometimes use or sometimes find useful is role group, where you can just

group things together and it's not a landmark but it can have a name and so have a little bit

of more structure but it's totally not needed. Second page there are others and the two that

are interesting here are none and presentation. These are actually the same thing so if you

define a role none then this will take the role that it had and removes it so for example if you

have um let's say what's a good example uh uh i don't i don't really have a good example let's

say you have um you have a table and you're using it for layout you should never do that stop doing

it. If you do it, don't do it. Then you can use role none or role presentation. Role presentation

is just older and put that on the table and it will remove the semantics of the table so that

the screen reader user is not getting read that this is a table, although it isn't because you're

using it for design. You should never do that, but sometimes you do stuff there.

And some of these like have parent-child relationships.

So for example, table, row needs to be in the table and stuff like that.

List, what did we have here?

List items need to be inside of a list.

And inside of a list, there can only be list items.

So there are constraints there.

in practice if you use html correctly you don't need to think about that these

roles are there if you cannot otherwise edit the html let's say you get your html from a third

party site or you um you know it's like older code and you're just you you want to do the html

write, but you don't have the time, so you quickly jerry-rig something together, then this is something you can do.

And as I have said, most document structure roles have direct HTML equivalents.

And we call that implicit roles, like the image has an implicit role of IMG, and the table has an implicit role of table.

It's pretty straightforward.

So, yeah, and so generally you don't need to use roles at all if you write good HTML.

Checking that off.

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.

It's 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 radio group, which you already know from our radio group examples for forms.

So this is also in here.

You never need that because you just use HTML radio groups.

And then there is tab list and tree and tree grid.

Now, because this is depending on Windows 98 technology, 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 panel, 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. And that

already checks off widget roles. I'm not going to go into detail here. Window roles are super short

because there are only two and we can remember them really easily. One is the dialogue and the

The other one is the alert dialog.

And basically the only way they differentiate between themselves is that the alert dialog is basically in your face and gets read aloud immediately.

And the dialog is just a window on the website.

And we now have the dialog element in HTML that basically works as this dialog role.

At the moment, I think it's good to know that this exists.

But over time, this will be less useful knowledge for sure.

And that's window roles.

Pretty straightforward, right?

Live region roles are part of the user interface that is announced to screen reader users.

And this is a relative complex, like this could be a whole how to do live regions, could

be a whole talk by itself. And actually, I did do a talk about that a year about a year ago.

And I will make sure to link to the slides in the description for this. But it doesn't really,

there's not a lot of value to go to go in there and, and describe all of the life regions

in detail. What live regions do is that they basically you put stuff in there like you have

a div or paragraph or whatever you have and it has a live region role like role

status that would be the most common one and you put in with javascript you put in

text. And that text would be read to the screen reader user without any modification, without any

like navigation possibilities. Like that text is right directly moved to the screen reader user.

And that's super useful for things like, oh, you've got a new chat message or things like

the website has finally loaded, the JavaScript has finally loaded, stuff like that. You want to do

that. There's also an alert role that gives you immediate feedback. So alert will interrupt the

screen reader at that time. So I shouldn't use that. And then there's lock marquee and timer,

which I have never used in practice. They have their use cases, but they are like,

like rare and they also are like, some of them don't even like announce by default. You have to

to set some settings there. So I think alert and status are the most important things here.

And that brings us to the end of our regions. That was pretty straightforward.

Naming user interface elements is super important for accessibility because, I mean, you have, it's great to know that there is a button there, but you also need to know what happens when you press that button, right?

So that's why we need names.

Save, close, all these good button names.

And there are a couple of ways to do that.

There are also descriptions, which are basically like the little brother or sister of the names, which is basically secondary information for the user interface elements.

And we get to that.

And it's important to know that ARIA is not the only way to set the name of an element.

The name of the element can be determined by a variety of things.

And I will not go into all of them.

There's a whole other specification for that.

If you want to read up on the ARIA name calculation, you can do that.

But you should not.

You should not.

So if you have a button that is named save, then the button has the text save on it.

And also the accessible name of the button is save.

So, no aria to be seen here.

But the accessible name can also come from other elements.

For example, if you have two text nodes inside of the button or you have like a span in there or something like that, that all counts and will be combined to the name of the button.

Or if you have an image of a disk inside of the button with the alternative text save, then the save will be used in the accessible name calculation.

Look it up if you want to. Don't do it.

Will be used as the name, as the accessible name of the button too.

And then there's two ways to do it for using ARIA.

And these you can use when you are in a situation where you can't easily change the text inside of the button.

So, for example, if you have just an X or times sign inside of the button as the visual label and you want to name it close for screen reader users, then you can use the ARIA label close and this will work.

And will be announced in the screen reader as close button.

And that's it.

Like there's no indication that there's something else inside of the button.

And then you can also use aria-labeled by with two L's.

That's important.

And that basically references another element.

So in this case, let's assume I have a lot of buttons that have a close label.

and I only want to change it once, if I do, for example, an update or add a second language,

then I can use a span. Actually, the element doesn't really matter here, but use id close

label and say it's close and then button aria-labeled by a close label. And that basically

references this id and takes the text inside of the span and put that as the aria-label.

And so the accessible name of this button is also close. And yeah, there are good use cases for this. But it's not like, like you're doing this all the time. This is actually, especially this example is relatively rare.

The analog goes for description. So in this case, we have a close name. The name is close.

And there's an aria described by closed desk. And then a span with the id closed desk for closed

description. It says back to start. So in this case, this would be announced as close button,

back to start. So there's always a little bit like a pause there. And then at the end,

there is the description and that can help you to give additional information to people using screen readers.

There is a relatively new ARIA described attribute in ARIA 1.2.

But yeah, the support is not super good.

So I didn't put that on its own slide.

Maybe in a couple of months or in a year or something like that, ARIA described is good enough.

And then you can name regions. So in contrast to interactive elements, labels do not overwrite the content when used with regions.

I think that's an important point that I didn't make super clear here. If we go back to here, this label completely replaces the X in here.

There could be anything inside this button.

It could be open.

It could be, I don't know, hello.

It could be anything.

Screen reader users would only see the close label.

So ARIA label in this instance overrides the content.

If you're naming regions, that would be awfully inconvenient because we want to name the region

and then you want to interact with individual things inside of that region.

So in this case, we have a main navigation that is labeled.

And this goes for all landmark roles and most of those grouping roles that I've shown.

really it's not really depending on the type of role when it when this is like overwrite overwriting

or not so this is a little bit harder to figure out but in general for landmarks this is the use

case you have a nav aria label equals main and then you have content inside of that that's

untouched by the ARIA label and then you have closing nav. And what this will be announced as main navigation. And that's basically it. So navigation because of the role and then main because that is the name of the region. And so you can use ARIA label, ARIA label by same way to label those regions pretty easily.

If you don't label landmark regions, they will just show up as navigation and you don't have any specific labeling, which is fine.

And you also don't need to write main navigation because navigation as the role is already read.

So, you know, don't bother with it.

States and properties.

There are a lot of states and properties in ARIA.

If we talk through all of them, we would be here until like, you know, in seven weeks we wouldn't be done.

This is super complex.

And the good thing is once you come across one, you can easily, relatively easily check in the specification if it meets your use case.

So let's start with global states and properties.

So these can be generally put on anything.

and I want to highlight a few.

ARIA-label, for example, ARIA-labeled-by, we already talked about those.

ARIA-live makes everything, anything a live region.

So if you have a span and you want to make it a live region,

you can use the role, but you can also use ARIA-live.

And there are a couple of others.

ARIA role description defines what is read as the role.

So you might have something that is, let's say, an article, and you use an article element.

But in reality, you want it to be announced as product.

Then you can use ARIA role description equals product.

and it would not be announced as a new phone article.

It would be announced as new phone product, which can help in certain situations.

I think I've never really used it in a practical way.

And then there's ARIA current, which basically means that you can say on a link,

this is the link you're currently on.

So if you're in navigation, you can use ARIA current, and then you can even use CSS to query that ARIA current true or page status, and then apply your CSS that way.

It's pretty neat.

And we have the widget attributes.

Those are like a lot of things as well, but they basically mirror a lot of things that we can do with the input element already.

things like ARIA checked, it's HTML checked basically, but also things like ARIA invalid

or ARIA required. These are, as I have said, only applicable for users with screen readers.

So ARIA required will not trigger the browser's required validation. It will not do anything

to prompt the user to fill out the required. The only thing that aria-required does is to announce

to the screen reader that this is a required field. And depending on your use case, that might

be the better thing to do. So there are a couple of those. aria-level, for example, is if you have

headings, heading level three, you would have role heading, and then aria-level three. So that would

the equivalent. Of course, you can type h3, so why would you do anything else in this case?

Then you have aria-sort for sorted tables and stuff like this.

So there's a lot of information that you can convey.

Then we have the life region attributes. Those are aria-atomic, aria-busy, aria-live,

and aria-relevant. Really quickly as the overview, aria-live switches live regions on and off. So

you can say aria-live, I think it's off, as there's no live region. Then you have aria-live-polite,

which is basically what the status does. It waits until the last announcement and then announces

whatever you have put into the live region. Or you could do aria-live assertive and that would

basically interrupt the current announcement and blurt out whatever you put in there.

aria-busy is used as a true/false for when you cannot interact with something. You can say,

"Oh, the website is busy, wait a second." That can be useful. If you set aria-atomic true,

that means the whole live region is red. And if you set aria-atomic false, which is the default,

then only the changes or added text will be red. And what is red? That is defined by aria-relevant.

So if aria-relevant, you can say edit text, remove text, and stuff like that.

There are also drag-and-drop attributes in aria-1.2, but they're all too deprecated since aria-1.1.

So I will not talk about them.

And then there are a couple of relationship attributes.

So this is basically to make sure that if you have something like a table and you want to announce the row, you can actually use ARIA row index for the current row you're in.

And then row count for the number of the rows.

But this is all built into HTML.

If you use a proper table, you don't need to think about that.

Theoretically, ARIA flow 2 would be nice to say like, hey, go there after this.

But nothing supports that.

So support is a big question mark.

And those are all the attributes and the states and properties.

If you have questions on any of those, if something jumps out at you, feel free to just ask.

And I can explain that further and also explain if it is actually supported in practice or not.

Which is always the question with these ARIA things.

There are a couple of rules of how to use ARIA in HTML.

And I've tried to hit them all during what we talked about, but they are actually in this really nice document called Using ARIA that Steve Faulkner and others are working on.

And it's a really nice summary of what you should and shouldn't do with ARIA when you're using it in HTML.

And so let's go to the first rule of ARIA.

If you can use a native HTML element or attribute with the same semantics and behavior you require, already built in, instead of repurposing an element and adding aria-role, state, or property to make it accessible, then do so.

So, if you need a button, don't use a div with a role button, just use the button element.

That's basically what this says.

Make sure that whenever there is something in HTML that meets your use case, that you use that.

Second rule of ARIA is do not change native semantics unless you really, really have to.

And I would add, and you know what you're doing, because this can go wrong really quickly.

So here's a bad example.

It's an H2 roll button detailed information.

Now I talked about, so the use case would be the programmer wants a heading and when you click the heading it expands and collapses some detailed information.

And the thing is twofold.

So first just putting row button on the H2 does not make the H2 interactive.

It just gets announced differently to screen readers, but actually tabbing to the H2 or doing anything with that, that doesn't work because it's not defined.

It's just a different role.

And the other thing is that this H2 now ceases to be a heading level 2.

Those roles are only like replacing, you can't add them to each other.

That would be neat, but that's not how they work.

So if you put H2RollButton, this heading is not a heading anymore.

It's now a button only.

So if you're using heading navigation, for example, you would skip right over it.

And even in this case, if you use tab navigation and want to activate it, it won't work because you can't actually move your focus on the button.

A much better way is to just use the H2 as you did before and then use the button element

inside it and boom, your expand collapse is more accessible.

It's really simple.

And so you should always, you know, always thinking about like, oh, can I do this through

nesting or can I do that in a better way?

A third rule of ARIA use is all interactive ARIA controls must be usable with a keyboard.

So we just talked about that, like this pseudo button was not a keyboard usable.

And if you use a roll button, then you need to make sure that the button can receive focus

and that a user must be able to activate it both with the enter or return key or with

the space key, because that's how a user assumes that those buttons will work.

And that's super important also for the different like widget roles and other things.

There is, we see that in a couple, I will point you at the documentation for that.

Basically, all these like more complicated user interface components, they have their own requirements on how they must be used with the keyboard.

Because basically, you're making a promise with the role on how this would work.

And if you don't keep that promise, then it will be much, much harder for a user to interact with the widget.

Fourth rule of ARIA, do not use role presentation or ARIA hidden true on a focusable element.

And as I said, role none is the same as role presentation.

And when you use either of those, it might result that users are focusing on nothing.

So basically you tap to a button and has a role presentation on it.

It will just read the text inside of the button like it would be a text field.

But there's no announcement that it is a button because you removed the role.

That happens when you use role presentation or role none.

If you use aria-hidden-true, that hides the element completely from the accessibility tree.

So in that case, you could tap to it, but there will be just no announcement.

It will be just silence.

And obviously, that's not a good interaction.

So this is not allowed.

Don't do it.

And this, by the way, also applies to stuff that is inside of elements that have those, that have aria-hidden set, for example.

So I do have examples.

So if I have an aria-hidden true and a button inside of that, then that button is also hidden.

And you can tap to it or you can move to it using the screen reader and you would have no announcement at all.

And the final rule, rule number five, is all interactive elements must have an accessible name.

We talked about accessible names.

And yeah, that's just the rule.

Don't do, yeah, use accessible names.

Make sure that they have them.

All right.

I know that this is a lot.

So I want to leave you with some further reading and information.

You don't have to read all of this because I think it's like 7 million pages of things.

But just so you have an impression and if you have more questions, go there.

And if you have any questions further from that, please bring them up and ask so we can talk them through because that's always most useful.

As I said, this is like super complicated and it's mostly for developer type.

And as testers, we just need to know what to find where and what is like the rough structure.

And then once you come across something that doesn't work in your screen reader or on an ongoing basis, you go and you look up what's going on.

And to look up what's going on, there's this way ARIA overview page, which introduces the whole standard.

They say it's a suite of web standards, which is probably true.

That includes using ARIA in HTML.

That also includes things like how does native HTML map to ARIA and stuff like that.

So there's a lot of good information there on the standard and how it works and for different use cases.

And then the next one is the ARIA authoring practices guide.

Now, the authoring practices guide, that looks like a list of patterns.

And we will go through that one in the live session.

And the purpose of the ARIA practice guide is not to give developers practical information.

The purpose is to illustrate appropriate use of ARIA as defined in the specification.

So you see in there your diff roll button with like terrible complicated constructs

to make it an actual clickable and tappable and keyboard operatable button.

But you should not do that.

Like, this is what the authoring practice guide does.

And it's mostly to test ARIA and make sure that that works.

Yeah, and the other thing is that the ARIA examples also generally do not have any touch or mobile considerations with it,

which makes them pretty, like, medium useful in my point of view.

but it's a good way to see how some of the roles and states and properties can interact with each other.