Live Session (2024)

Hello and welcome back to this second tutoring session. This is, as always, open for everyone. If you're looking at this in the future, I hope it's better there than it is here. That's how progress should work.

And if you have any questions, feel free to put them into Slack so we can reply to them and give you, like, your help if you need it.

But, you know, maybe we also answer stuff in this meeting, in this tutoring session right now.

Yeah, so I think I want to just do the quick open, like open the floodgates and say any questions, any specifics you want to know.

And just as a general overview, what I'm going to do in the videos, I talked about what you should do.

And now in this live sessions, I will talk a little bit about how you figure out if it's done correctly.

So the testing aspect of stuff.

And I think I showed a little bit in the videos as well.

But it's always good to see that in a live thing.

And then you can also have questions in between.

So any questions, and feel free to put your hand up or put a note into chat or just speak up.

Soma and Misael?

Is that?

Yeah.

Now it's me.

Yeah, I actually had like four different questions.

Okay, start with one.

Yeah.

Let's see if the camera.

The thing is that, for example, on the first example,

when we went through, you went through X-Labs,

I can't really see it anyway.

You had two H1s, and I think his name was Claudio when we had a meeting.

He also said that it's okay to have two H1s or multiples.

And how should you think?

And we were looking at Google.com.

They don't have any H1, for example.

is there like a standard you should follow or yeah so this is a great question um because

there's basically uh there's basically multiple things that are going on so the first one is like

you know some people uh look at like purity in like what they teach or what they tell people to

do um and then there's just practicality uh and you know if you if you look at it from a pure

purity type of thing uh you technically only want to have like one h1 uh and and stuff like that

people and some people are very strict about that um which i don't think is like um the most useful

thing honestly to be so on the access lab side I have one h1 and then we have an h2 here I don't

know if there are other h1s because when I recorded the video that is a long time ago

I can show the headings here oh yeah there's a heading here h1 here and h1 there the most

important thing is that you have headings everything that looks like a heading is also a

heading so you can explore the page and find different sections on the page.

And then the second, like,

lower, much lower ranked issue is like, does this make sense in the page structure?

So, you know, here we have H1, H1 and then H2, H3,

and then H2 back again, which that makes all sense.

Like these are different, different things.

So this is equivalent for someone who is using a screen reader, for example, with someone seeing the page.

And it doesn't really matter if there are two H1s here at the top because they are basically very similar from what you want to do.

So I think the most important thing is that there are headings, that everything that looks like a heading is a heading.

And then, like, if you have headings, just make sure that the structure is good.

And that's also mostly for, like, the main content.

Like, if you had, like, you know, if there was an H2 here that said, like, navigation, and then you also have an H2 here at the bottom that says footer, you could do that, even though, like, you know, the other headings here wouldn't then make a lot of sense.

But like, you can be like a little bit like, you know, there's not, it's, let's say, let's say it's not worth like being super strict about it, because most screen reader users will just jump to the next heading.

So they would go access lab, services, accessibility.

And that would be like the first, the first three headings.

And like, the levels are more like additional information.

And what about when you open, like, modals? Should you think about it, like, a completely new separate page? Like, since you aren't able to go to anything in the background, should you have a new H1?

That's usually what I do. So I have here a model on my own page, and I think this is an H1. If it's not, that's super embarrassing, I guess. It's not. But it doesn't really matter because you're in such a constrained way.

If this was a very in-detail complicated model, then I would say, oh, having a really rigid structure might be more important.

But for this, yeah, just start with another H1.

Because basically what a screen reader will do is they will hide everything in the back.

So this is basically a new page for them if it's implemented correctly.

So I would generally try to start with an H1, and that makes it easy to handle.

Okay, and then continuing.

You mentioned there are different content, what's it called?

You had side nav and main and footer.

But then I was thinking about, you mentioned that in the X-Labs blog,

You had different sections and they were together.

But you also have the section or article HTML element.

Do they do anything for accessibility or is it most for other stuff?

Good question.

So, yeah.

So there is a difference between landmarks and then general like region type of containers.

So section and article are just general containers.

And they are usually not announced.

And this is all individual for the screen reader user.

They can make those be announced if they want to.

So if I, as a screen reader user, say, oh, it's super important for me on this specific page even to have sections and articles announced, then I can set my settings like that.

So there's a lot of customization in it, but by default, screen readers do not announce sections or articles unless they have an accessible name.

So if you put ARIA label on it or use ARIA labeled by, those are the common ways to label sections and articles, then they would be announced as a container.

And that can be useful in a couple of instances.

If you don't do that, then they will be basically treated like a div, like a presentational element.

And the reason is that a lot of people are overusing sections because they have heard that like, oh, divs are bad.

And then they look at like, oh, what's like a div, but not a div.

And they go like, oh, I could use a section.

And then they have overused it.

And now it's like, it's basically burned for all of us.

So, only if there's an ARIA label, ARIA labeled by, then the section and article gets announced for sure.

Oh, and then they also can show up in the landmark overview.

Like if you have a screen reader and you say show all landmarks, but that depends on the screen reader.

Okay. Thank you.

But that was all the questions I had.

I know some have some questions also,

but I don't know if you want to go with someone else first.

Sure.

Does anyone else have a question, hands up, or chat?

Going, going.

I have a question.

Yeah, go ahead.

I'm not seeing who wants to go first.

I was a little bit curious about the resources or information about this,

if it differs when you are creating a single page app or a mobile app and not the web page.

So in terms of navigation and the structure of an app.

It's a good question.

Generally, you try to use the same basic concepts.

But of course, if you only change part of the site,

you have to do all the information yourself that the browser usually does give you for free. If you

reload a page in a browser, screen readers will just announce, "Oh, there's pages loading," and

also tells you once the page is loaded, and then you are automatically with your focus at the top

of the page. So you get all of that for free with a classical multi-page application.

If you change stuff, like let's say the Access Lab site would be a single page application,

and let's say we click on Accessibility Review, and instead of loading a new page,

it would just replace this pinkish main content. That would be like a single page application

would do it then you would say so first uh you would you would need to like manage the focus

yourself so you want to like put the focus at the top um and uh or on the main uh container uh that

depends on like you know what what ui you want to have uh but that's that's usually what you want

to do like you know maybe only like put it on top where stuff has changed um and then like the rest

is basically the same like you want to have like every section you want to have like your headings

you want to make sure that you have like a good way uh in terms of landmarks to navigate between

sections especially important uh with applications like if you have multiple sections like a dashboard

or something like that, going from one to the other is super useful.

So, yeah, I think the same stuff applies.

You just have to make sure that you are reacting to, like,

or that you are fulfilling the role of the browser as well to a certain degree.

So you have to manage focus.

You have to be sure, like, let's say I'm here and I press the back button.

You should, like, support that.

And then, like, the focus should be on the button where you left maybe.

you know, there are like different UI things that you should be thinking about. But for like putting structure in, I think it's pretty much the same.

Thank you.

Awesome. Karin.

Yeah, hello. I wonder, because you said in the video that you need to be consequent in the way you're going down between H2.

You gave an example, H2, you cannot jump from H2 to H5. When you go up, you said you're allowed to go up two levels. Can you clarify that a little bit?

Yeah, sure. It's a good question because I think this is also a bit hard, difficult to understand concept. Let's take this as an example. So we have here a heading one, and then we have a heading two, and then we have a heading three here.

And then here, because we are getting like back a level, we're going to a level two again.

Let's say there was more content under related activities.

Like let's say it says like live activities or like in-person meetings or remote meetings.

So you have a couple of headings, level four underneath it.

Then you can go back to level H2 because you don't need to like basically cancel out of this related activities header.

so you know if you go if you go down and that's just where you end up you don't need to like

to then have another heading there that you know that that would not provide any any information

so it's just like it's just so so basically you'd always try to nest your content if if it fits

you try to nest your content underneath like the previous heading and then for the next heading

you try to figure out like on what level does this fit instead of like do I need to get back

a level or not so in this case monitor websites and engage with stakeholders they are levels

that are like on this they are on the same level so whatever happens in here doesn't matter for

where you end up at the bottom.

I hope this was a little bit clearer.

And if not, I can try to explain it again.

I think I need to digest it.

I don't know.

It makes sense what you're saying.

Yeah.

Let's say, usually I try to explain it like that.

If you have a book, it has a title,

and then every chapter has a heading.

And inside of those chapters, you might have subchapters.

So you might have subchapter one, subchapter two.

And then in subchapter two, you might have subchapter three.

But then the next chapter starts.

You don't need to go back up to subchapters.

No, no, no.

You go to the next chapter directly.

And this is the same thing.

All right.

So those chapters are on one level,

and then you can go as deep as you want inside of the individual chapters.

Okay. Thank you.

Books. I never think of books.

Okay. Any other questions?

If not, there has been one in chat.

Jakob.

Hello. Yes.

Okay, hear me out.

I might have misunderstood this,

but I just wanted to hear your thoughts on it.

So I come from a design background, and from day to day,

I work with developers.

And I've been thinking, because we had this discussion

on the workshop as well, and I was just thinking,

regarding like when I design, for example, let's say a start page,

and then the developer would say, well, this is H1, this is H2,

this is H3, and so on.

And we're going through now from accessibility standpoint,

like best practice.

And I think for me, it's pretty easy to understand.

But I was just thinking, do you have any ideas on this, like the text styles?

Because usually you end up with pretty descriptive text styles.

And I was just thinking, is there a better way of handling text styles so the developer can match it?

Do you understand what I mean?

Yeah, this is like one of the big, like, this is actually like a bigger problem than you would think it is.

Because usually, so as a design developer who does everything myself, I just go and say, this is my H1, this is my H2, and I style them like that.

If you are a visual designer, you sometimes get into these situations where you have an H3 that should look like an H2 or like an H4 that should look like an H5, stuff like that.

And that's totally okay.

You can do that.

There's nothing that prevents you from doing that as long as the underlying structure is good.

And the easiest way that most people do it is to have classes for the headings.

So you have your H1 style, your H2 style, your H3 style, and then you have looks like H1, looks like H2, looks like H3.

I mean, wording, naming, whatever you want, but that's usually what is done.

So the developer can say, oh, this is in my mind thinking about this structurally.

It's an H3, but visually, my visual layout that I got is an H2.

So I will say H3 looks like H2 and be done with it.

So that's usually what I say.

define the looks and then also be aware that like the looks don't need to match the...

Well, they should, but they don't need to. Exactly, because that's what's not colliding

for me, whatever you call it, but like for example, when we work with color styles,

it's like the background is a background, but then when it comes to working together with

developers the h1 is not necessarily h1 in the style so i just was thinking is there like a

maintainable way of handling this i guess your answer is like well it's going to be in the code

what color and what text style they use for each heading and i can just settle with that i guess

yes that's usually usually how it's done i mean if you if you create like um a styling

from ground up.

And I don't think a lot of people are doing this anymore.

Back when I was a web developer and web designer 10 years ago,

what we did, we designed all the templates from the ground up ourselves.

So what I would do in such situations, instead of saying,

in this case, it's an H2 that looks like an H1,

I would go and would put a class on the body or on the main element and would say, oh, this is this template.

And then I can just use the H1s.

Because if you have a CMS, for example, then you don't want users putting classes on stuff because they are terrible.

Users are terrible at doing content structure.

So you want to restrict that.

So you can say like, oh, in this container, you know, all headings level one looks like headings level two, but that can quickly spiral out of control.

And I guess it's now better with like, you know, new CSS selectors because you can say like, you know, you can group them better.

And so it might not be as big of a thing.

But like, I know that for one of our clients, we had like, every section was color coded.

And they had like very different styles on each color coded section.

And we had these like long CSS selectors that tried to like match all of the different possibilities.

And it wasn't a nightmare, but it worked.

Like, you know, that was the other thing.

And they could just concentrate on like, oh, I direct this page to this section.

and it would just magically change the colors and change the font styles and stuff.

That was pretty neat.

But yeah, it needs planning.

That's the other thing.

If you plan it well, then it's usually doable.

Okay, thank you.

Sure.

Let me quickly use the question from the chat.

Would you mind telling a little bit about hidden headings, like examples, or when it's nice to use them, and the general opinion about them, accessibility-wise?

That's from Soma, I guess.

And so, the first thing is, like, I'm not a big fan.

I don't like them, because you can't see them.

That's the biggest pet peeve.

That means often they get forgotten or get doubled up.

It's just like if you work with people who do not use assistive technologies and you use hidden stuff, it just gets overlooked and you get accessibility issues with that.

And so that's why I'm not a big fan.

But pragmatically, they are useful and you can and should use them if you feel the need for them.

So, for example, on the WAI website, I don't think we have any hidden headings, actually.

Let me go on to one that I know better.

So here at the Nobility website, I think there's a hidden header that says, welcome here.

Headings.

Go.

Oh, is it completely hidden?

I programmed this like four years ago.

So yes, there is the visual hidden heading.

And it just says Nobility.

Okay, that's also totally fine.

Let's delete the link.

And that's a good way to do it, you know, to make sure that your heading levels are good.

And you can use them if it's visually clear what a section or part of your website is.

So let's say you have a page where you have like a carousel of recipes at the bottom and it's a recipe website.

You know, you might not want to put in there like here are more recipes as a heading visually.

But you might want to have that in your structure to make it easier for people who are blind, who are using screen readers to like get an overview.

because that's essentially the goal of having headings,

is that you can skim the site.

Like a visual user, I can skim, oh, this is this heading,

this is that heading, here's a heading, there's a heading.

That's really easy.

And for screen reader users, having that list of headings

and help to navigate similar to landmarks is a good way to get that overview

and just be able to slice the page in its components and get to there.

So yeah, I'm actually not the biggest fan of hidden stuff,

but if you feel you need to use it, then just go ahead and use it.

It's totally fine.

Just be aware that it happens.

and if you make changes, be aware that you need to change it as well. Okay, more questions in chat.

Do you have a good summary of good tools to use when checking accessibility issues? I don't have

a good overview, but I will show some later today. Especially for pages and stuff. That was by Hannah

And Alicia says, how do you solve accessibility content that are rendered conditionally?

You can have a skeleton visually before content is ready.

For example, we render a page with a login feature.

The user visits the site, it has login here.

Once you log in it, it should change to a high name.

But we need to talk to a database and add a skeleton design whilst it is loading.

What should the screen reader say before the high name is rendered?

just generic area label loading or is there a better way um so this is one of the other things

where you have um uh where you decide to not use page reloads so uh again the burden of like oh i

now have to emulate a browser is on you. And how you do that, you know, you can be pretty,

pretty flexible with how you do that. So if you decide to use a skeleton

loading screen, and this is for those who don't know, because that's a bit jargony,

it's basically you have gray boxes where content would be, and then you replace those gray

boxes with the content once it's loaded from the server. If you decide to do that, then you should

look into like making the page busy. So that's ARIA busy. And we get into ARIA stuff in like 10

weeks or so. More like eight weeks. But that's usually a way that you can say like, oh, this

page is doing something and I'm busy and leave me alone. Visual text that says loading is always

good. You can also have a little loading spinner, also not a problem. And then you can load the

content in and then you just have to make sure that the user knows once the content has loaded.

So you want to do that by setting the focus onto the newly loaded content, because then it will be announced automatically in screen readers.

And then, you know, a user who uses screen reader knows like, oh, this has changed and I can now interact with it.

But yeah, there's a lot of steps when you do loading, when you take that on for yourself that you have to think about and make sure that it works.

And as always, testing stuff is important.

Any other questions?

Follow up on that one, unless someone else has something.

Yeah, Jessica asks, do you mean that you have a loader on top of the skeleton?

Yeah, I mean, often you have these skeletons.

I'm not the biggest fan of skeleton things because I think like, try to pretend that something is loaded, which it isn't. But like, if you have it, and there is like an animation on the skeleton, which some people do, you know, it might be a bit distracting.

I like to have a separate loading thing because a lot of people with cognitive disabilities, for example, might not pick up that this is loading, that having a skeleton means it's loading.

They might think like, oh, this is stuck somehow.

So I think it's always good to be very clear in what's happening.

And a little loading spinner or the text loading or fetching data or something like that can really help there.

A follow-up, how does a non-sighted user or a screen reader user get information that we get from the browser?

For example, there is a loading, there's a bar usually under the...

There's information about if something is broken.

So how does that work in terms of screen reader in relation to the content?

Yeah. The screen reader will announce that. It will say, like, 80% loaded, 100% loaded.

Oh, it announces how much it's loaded.

Yeah, and then it will just start from the top.

Okay.

So, yeah. And it will not start from the top. It starts reading from the top. It will put the focus on the top of the page.

So basically-- and usually you also get audio queue.

I think on Mac OS, it's like a little bing that says, oh,

the loading has completed.

Especially if it's close to other announcements,

then it does it that way.

OK.

Yeah.

And there's no way as a website to trigger that,

because people would totally abuse that.

Yeah.

I think on a side note, I think the reasoning behind doing skeleton loading is that there's research shown that it's perceived to be faster.

Like even if it takes the same time as a loading bar, the perception of the human mind is that it's faster.

So it's a business thing.

I know that, like, I think Facebook showed that this was the case.

And then I think there was a lot of other research that showed like, yeah, it works for Facebook, but it doesn't work for like normal pages.

Because people have, because people like, and this is dependent on your use case.

Like if you have more of an application like website, I think they work better than if you have like, you know, and I've seen them on like, oh, this is a restaurant webpage.

Let's have a skeleton loader.

And I'm like, this is not how this should work.

And then, you know, you're in the train and you lose, like, your JavaScript and, like, the whole website is forever in the skeleton until you realize and reload the page.

So, yeah, I think it also depends on the data.

Like, and this is, like, you know, for a normal login page.

Personally, I would advise to just not use a skeleton.

I would say have a little loader.

Just keep them waiting.

Because the expectation is that your web page either reloads

or you get just logged in.

It just happens.

But if you like loading three megabytes of, I don't know,

data into display in a chart, then you have different considerations.

Yeah.

Or work on your loading times.

Yeah.

Performance is an accessibility feature.

Yeah, definitely.

Especially if you have ADHD or something. Oh, yeah. No. And these are like -- this

is also why it's difficult to talk about some of these accessibility issues in the abstract.

Like, you know, I'm happy to do that here because, like, this is more academic than

usual. But, like, it's really hard to, like, say, oh, this is the blanket, like, one way

to do it for you because there are so many different ways and that's actually like one

of the strengths of like especially web accessibility that you have like different ways to fix stuff

yeah and i guess also like in larger organizations there's always the politics and you know the

business side of things and the the pretty like you said the in the beginning that the pragmatics

and the the actual like pure puritan so you always have to be sort of like pragmatic especially if

in a larger organization, I think, navigating everything.

Yeah, for sure.

And I mean, I did show the WeCare quick reference last time.

I'll show it again, because why not?

And I built this.

And technically, if you look at it, it's a single-page application, right?

It has all the trappings of one.

You click on blinking, and it updates.

And it's really a single-page application because it loads like three megabytes of HTML into your browser.

And then you can interact with it, which means it has like a long load time at the front.

Just normal HTTP load times because I did not care about doing anything else.

But then once you have it, like you have it, you know, it doesn't communicate with the backend at all because there is no backend.

It's just an HTML file with JavaScript showing and hiding stuff.

So it's not super complicated.

But it's like, how do you do that?

In this case, once you make a change, that needs obviously to be communicated to screen readers.

And here we're using ARIA Live Region.

This is something we're going to talk about in the future, but this has an ARIA live polite.

So this basically means announce everything that is in the span, in this case, once the screen reader has time for it.

And ARIA atomic true means always read the whole thing, because otherwise it only reads stuff that has changed.

so you know you can communicate and make the screen reader announce certain things and and

use that as like your your thing so when you are using single page application and you load

something you know and you have your loading spinner up or even like the uh the uh skeleton

animation uh you can say oh here's my aria live uh region and i say i put loading in it and then

And once it's loaded, I say, like, you know, you're ready or something like that.

And those are, like, there are always different ways to do it.

All right.

Any other questions?

Those are good questions, by the way.

and yeah i mean the time spent on building skeleton loading could be spent doing

accessibility fixes instead i mean that's that's like it's always easier to say than done i mean

we're currently working with like big online shop on making their stuff accessible and like i think

most of the issues that they have is like really simple fixes but then they have like this

intricate like layers of like deployment and business stuff and we have to like think about

like we have to talk with stakeholders and then they have like a like framework like react stuff

and they're using a ui library and it's like makes it there's often so many layers between like

oh just fix this and the actual fix that's really hard to do um and there are some people

in accessibility who say like oh we come in and we will fix your stuff um you know and i could do

that like i could go to like a company and could say like oh yeah just fix it fix it fix it um but

that only like fixes the symptoms not the reasons why they are there so uh not the biggest fan of

that um but yeah it's a it's it really depends on like what you can do um and sometimes it's just

like you know it's it's baby steps and a lot of baby steps also amount into like uh walking the

way eventually it's just slow and takes time that's the business we're in all right let's

take another five minutes to just show a couple of testing tools. Testing tools was the question,

and I've seen that Hannah has put in the W3C Way testing tools list, which I worked on many,

many moons ago, probably eight years ago or something like that. It did look much,

much worse when i worked on it because i'm not a designer and there are good good things in there

and it's certainly a thing a list where you can find tests that are that are good for you

and i like to point out things here at the type of tool

selection because you can basically say i only want bookmarklets or i want and i will explain

bookmarklets in a second or i only want browser plugins so if you have like restrictions from your

it and stuff like that you can find good things there online tools um would be uh would be

something that you want to to look at um yeah and then you can also sort by like do they support

WCAG 2.2 and stuff like that. So it's a good resource to get an overview and then you just

have to find something that you're comfortable with. And that's always what I tell people when

they ask me about testing tools is figure out what you're comfortable with. It doesn't really matter.

Accessibility rules are so simple that as long as you find what you're searching for,

it doesn't really matter what tools you're using. And that's how I see it.

And I just want to show those two bookmarklets here. And it's actually pages of bookmarklets. So

for those who don't know, bookmarklets are little JavaScript applications that you can drag into

your favorites bar so uh here i have this like wheelchair symbol and then access lab and then

wick hack and this is my favorites bar and it looks a little bit different in in every browser

but you can show it uh like view favorites bar is um you uh show favorites bar is the way to do it

in Safari and like every browser has that. And basically what you can then do is like

scroll to the bottom and let's say here we have check headings because that you know relates to

what this week is about and then you can take this bookmarklet and you drag it up into your

favorites bar and then you add it to here then it doesn't work for some

reason don't even know if you can see that I'm dragging stuff around why

doesn't this work did Safari lose the ability to do this it used to be I used

to be able to do this. Then you have to go into your bookmarks folder and do it that way.

This is weird. So you can also do the right click, copy link, and then you can create a

bookmark, add bookmark.

and then you put it into your favorites where is it bookmarks menu i don't even know how this

works here uh so this is the um thing and then i do check headings i had to copy it

no it doesn't put it there it's just somehow broken

huh interesting so tab group favorites this week check headings there it is

oh i can drag it in here uh that works and now i just have to edit address and put the

address that I copied in there. That's just JavaScript. So this was weird. So you should

be able to drag and drop it. It's probably a problem on my side. And then this check headings

checks the page for WCAG failures and best practices, highlights problems on the area.

It works in your Safari. Yeah, it should also work in my Safari. I'm like,

I have done this hundreds of times.

So that's always fun.

Technology.

And provides an outline in the console.

So if we look at, like, let's take my website.

Because if it's wrong, then it's embarrassing for me.

This does not have...

Yeah, this has headings.

And here we have, like, H2s and H3s.

it's like really nicely organized. And then you can click "Check headings" and you have

"First H1 on the page content not present in the page title". So this is the best practice.

And the reason is because I have four reasons of using like previews on LinkedIn and stuff.

I have WCAG in the page title. I don't have that in the title on the website because it doesn't

make any sense. And there's some styling that I'm not responsible for, like having styling H2.

People don't like it, so this bookmarklet shows that.

This is a long heading, yeah, but that's on purpose. It doesn't show the outline here,

But those are also headings, I hope.

Because if not, that would be super embarrassing.

So I don't know why it's not...

Oh, now it's showing.

Oh no, for this.

This is a great demonstration.

Let's go to the Access Lab website and click it again.

Here it does nothing. That's also fun.

Maybe I have to restart my Safari.

Let me quickly do that.

weird weird in germany we call this uh uh i've forgotten how we call this

for fear effect that's how we call it the effect that you have when you show something

and then it doesn't work so restarted this check headings

Sometimes it's also because of JavaScript not working. It doesn't want to show the... Oh, because it's not wrong. Because this only shows them for... So this is the problem if you're using different tools.

Everyone does it differently and as I said, it doesn't really matter which one you use, but you have to know how they work and sometimes they do not work how you would expect that.

So, this check heading actually only shows issues. And also, if I go into the inspector, here in the console, which is over here, console, it shows the outline of the headings here.

So you have the h1 here, my brief, table of contents, what are in brief sections, what is the goal and so on. So you get these and the little pointers are the errors that are also shown like here inside of the page.

So this basically gives you a nice outline. What this also does, it finds this H1 that is in the dialogue that we talked about, which technically it shouldn't because it's hidden from view and also from assistive technology. But this one does find that.

So this is one of the heading bookmarklets you can use, but you can also use one from here.

This is the Paul J. Adam bookmarklet, and let's see if now it works again.

There we go. Dragging, dropping, done. Oh, so such a relief.

It's a weird thing to be annoyed by, but it's how it is.

So this, I showed this before, like this puts the little tags before and after the heading.

So you can basically just scroll through and say like, oh yeah, this is the heading I would expect.

This is, you know, and then see how that works.

And it gives you nice heading markers.

And there are countless of these bookmarklets.

And you can write them yourself because they're only JavaScript.

If you're a programmer, if you're not a programmer, you cannot do it.

But if you want to, you can get someone to write them for you because they're really, really simple.

And yeah, and it's a good way to get like this overview of different things.

And there are many of those.

And I will show a little bit more in terms of like how do we find landmarks and stuff like that after the break.

Because I think now Safari did restart and had its break.

Now we all need a break.

So let's meet in 10 minutes at 5 past 2.

No, what is that?

5 past 2.

What's my brain doing today?

And yeah, and then we see each other.

And then I will also look into if there's anything new in chat.

So see you around in 10 minutes.

Bye.

And we're back.

Question in the chat.

which tool did you use to get the heading label next to the heading?

It was easy to understand.

That was from Paul J. Adams' JavaScript bookmarklets for accessibility testing.

I will release the link to that in the canvas as well.

And Paul did these multiple bookmarklets a couple of years ago now.

And it's pretty nice.

And for every thing, like tables or headings here, there's a demo page and also an installing.

So you want to take the installing, drag that over into your favorites bar, which always works, especially in Safari.

It's never failing, never happened, especially not for me.

By the way, if you want to get rid of it, you can drag it out and at some point it poofs out of existence.

So that's nice. And you can also put them into a folder.

So that's what I have done here. So this is not a tool, just a list of bookmarks.

But yeah, you can just drag and drop it to the top and then go to, for example, the headings page.

there are all the different headings and it looks like this. And this is actually a nice

way to also double check, like okay, how should this look in different situations? Like here at

the bottom we have an empty H1 and an empty H4. So you can see, oh, this is how, you know, if there's

empty headings. This is how that looks and that can be useful for just verifying, oh this is what

I should see. Same goes for these types of ARIA headings. You usually don't want to see them,

but this is how they get revealed. And this works for a couple of other structure elements as well,

like here we have a landmarks bookmarklet. Again, just dragging it up, putting it on the bookmarks

bar like nobody's business. And then we can here get onto the testing page, clicking on landmarks.

And here we have role navigation, role search, you know, role main, banner. And these, the nice thing

about bookmarklets is that they work in every browser on every operating system. So you can,

if you sync your bookmarks between like the Mac and iOS, for example, or even if you have an

Android phone, you can put them into your bookmarks. It might be a little bit more complicated than

just dragging and dropping them, but it's possible. And then you even can do it on mobile if you want

too. So yeah, they are very versatile because they're just little, sweet little JavaScripts.

And I like those very much and also the ones from Lloyd here. And he has several here,

live region watcher. So this might actually be interesting for the future, putting that on my to-do list. But I think there's also an outliner, isolator, no, none for landmarks. If you want landmarks, I can recommend the Andy.

bookmarklet. So let's reload my page

and start Andy. There it is.

And Andy basically gives you several

different things including focusable elements, graphics images,

links, buttons, but also structures. And that's what we're looking at

today. But Andy is really cool.

So let me

put that link into the chat as well. I think that's the right link. And yeah, so in this case,

I just press structures here at the top and tells me that there are 20 headings. So now I click

the 20 headings, I see the headings here and I can jump through them one by one. And here we have

the accessibility component one in our text, and then also the ND output. So this is basically

where it says like, I'm simulating being a screen reader, which, you know, sometimes better,

sometimes it's different. Also depends on the screen reader. You can look at the headings list

here and it will also helpfully like put like little um purple pinkish uh arrows to the to

the headings uh which i find like super useful so you know table of contents is here um and uh

and so you have the headings and it's also a little bit like indented but only by one space

This could be a little bit more pronounced for my personal taste.

And as you can see, it does not have the heading from the preferences dialog box in there.

So I can click that.

Oh, this is now behind it because new dialogs work that way.

So I can't show it.

But it's really nice to be able to also go through the headings.

So if I start with the first one, I have H2, H2, H2, H2, and then H3 here

the header. It's now underneath this border which is a little bit unfortunate. I don't know, I think you can

click "mini mode" and then it goes like a little bit... oh, no, that's not what I wanted.

And then you can see a little bit more, but here we have the header

And then we go to the navigation and it says, ARIA-label main.

And any output should be main, comma, navigation in here.

That's usually how that works.

So this is not 100%.

Then we have the main element.

Then we have the header of the main element, which technically not a landmark.

So I think I need to have to give feedback on that.

but you can now go through the different navigations and footers and stuff like that. So it's really useful to be able to go through the landmarks as well here.

And this also has a list view, which lists are great as an accessibility person. You always want to use lists because they are nice to structure and group things. It's the,

It's just the element that we have where we can group things together. So we often use that for like anything, not only if it looks like a list like in here.

Brief and then we have a sub list inside of a list item. But even for stuff like here at the...

Jump a little bit more. Where are we?

And this is a normal list item and then we have at the bottom another list. I have a lot of lists. As I said, like as a... Is this now repeating? No. Here are the footnotes. They are in the list. This update is one bullet point list, which you can do.

And then here we have lists for the feeds and for the other pages.

So yeah, you put stuff in lists.

That's usually what you do.

And there's a question, Manfred.

Yes, I was just a little bit curious about your process.

Like when you want to find usability and especially accessibility issues,

in what order do you usually do it?

Do you talk to real users first and then discover the most critical problems and then use tools?

Or do you use the tools and automate the tests first?

It's a good question.

And so my first advice is never do things that I do for the reason is that I'm doing this for a long time.

And I'm doing stuff differently than other people.

I tell you shortly what I'm doing, and then I tell you what I think you should be doing.

Because I think it's interesting.

So for me, when I get to a page that has accessibility issues, because all have, I'm first scanning the page.

And that means visually with the keyboard, with the mouse, I try to get a feeling for all the interactions that are happening on the page.

And then I know because of my experience, what can be problematic for accessibility?

Like what are the big issues?

And then I test them.

And usually I go roughly in WCAG order, but also from like the big picture to the small picture.

So I usually look at like, okay, can I get everywhere with the keyboard?

That's like one of the first things that I do just to like.

get a feeling for like is this like a terrible website where I can't like even test everything

because I can't get everywhere or is this like is this like a normal website where I can get

everywhere with the keyboard and then there are a little bit oddities and that's how I approach it

and then I use polypane which I will talk about in a bit and basically use that and those are

basically also like bookmarklets and other testing tools to go through. I use automated testing as a

thing to verify my findings. So I will go through and have a mental model and then I will do the

automated test and see if there's anything that I've missed because that sometimes happens.

And then I will go through and will go through WCAG after I've like written up everything that

I've just found, I will go through every WCAG success criteria that I haven't looked at,

and will double check that I haven't missed anything. Because sometimes it's like,

oh, there is no, let's say video on the page. So I haven't tested that. But one thing that is,

that always eludes me is language of parts. And I often like skip over that when I do my

general testing and so having that reminder that oh this is a thing that I should test

it's a good thing it's just best practice to like make sure you have checked everything um

for those so that's my my general process it's very brute force it's very like shooting from

the hips uh don't do this it's terrible um I think if you if you're starting out with web

accessibility if you're a developer from developer perspective you want to start with the automated

tools and make sure that you fix all the things now the automated tools have the additional

problem that their suggestions are often hard to understand and sometimes they find stuff that

doesn't need fixing because it's you know it's okay enough and sometimes they

lead you to things that are not really necessary. And you should just make sure that you don't look

at best practices, just look at real failure. So if we switch over to Polypane, this case,

and I can put my website again. It's only embarrassing to me. So in the sidebar, I can

use the X testing, which is like the most widely used tool. It's AXE from Deque. I don't have a

link, but you can Google it. And this is built in Google Lighthouse subsection. And then like

a lot of other tools, they use X because it's open source. And I can really recommend it. It

a lot of issues. And you can analyze that and if you don't include best practices,

then you can celebrate because yay, this works. But if you include best practices,

oh, it also doesn't find issues because I'm great. But if you have like a lesser website, let's take,

oh this did not work out as i wanted amazon.de

yeah yeah

so let's say uh we're opening this and then we're going to accessibility again

and we analyze it for accessibility issues it takes a little time and only shows two

which is like probably not true the animation here at the top uh alone is probably like an issue but

like links must have discernible text clear work hack uh issue so if i click on it uh here is like

this dortmund celtic lascaux i guess um uh i'm i'm not a football person um especially not dortmund

Oh, letting you look deep into my soul. And this has an ARIA label and it's empty. So this overrides everything that is in there. So this link does not have a label. So it will just be announced as link in a screen reader. And this is easy to find with automated tools, right?

So links must have discernible text.

So this thing and then here at the bottom, there is an empty link somewhere here to audible.

So that's just missing.

Probably an image with alternative text doesn't really matter.

But this one at the top, I think this is a major issue.

Like this is a major advertisement thing.

And they just put an empty ARIA label on it.

And these things you can find really easily with automated tools. So I would always start here. Oh, sorry for the scrolling.

Were there only two issues then on this page?

The automated test did only find two issues, which is, you would think that's surprising, but you have to understand that automated testing can only find, in the best case, like 50% of the test cases.

That's why I think it's good to start with them, just to knock out the easy-to-find things.

No need to pay a very expensive expert to tell you, oh, this link is empty.

This link has no text.

When a tool can do that.

What a tool can't do is, is this a good alternative text for this image?

So let's see.

Oh, yeah, here it says Celtic.

Hey, I know my...

Does the one with the text in the image have alternative text for the discounts there?

Here on the left?

Yeah.

This is actually, I think, this is real text.

This is real text.

It's real text.

Okay, that's cool.

Yeah.

They have both.

Nice.

Yeah, and here we have Dortmund against Celtic.

Sure.

Oh, I think that's wrong.

Sorry.

Did I understand correctly that this Polypane browser is using OXE as a plugin?

Or is it like, yeah, okay.

Yes, it's basically the X plugin, just a little bit different.

Without all the advertisement that you get to sign up for Deque's stuff.

Which is their good right, because they are putting a lot of effort in it.

You know, not like disparaging that.

like uh it's i i think this is much cleaner and uh and you get these like hover things uh and uh and

you also get other testing tools and i show a couple of those but here we have like for these

like so there are two footballers from uh dortmund and two from glasgow um so and the alternative

text is prime ucl which is like on a german website um this tells me nothing like it's

uefa championship league i guess uh but it's like it's like this is a you know this alternative text

tells me nothing so automated tool cannot tell you that you know a better alternative text would

be like collage of four football players i guess if you are into into football you would want to

know what their names are but i could not tell you so i will not even try to guess it's probably

fritz and klaus um manfred uh yeah sorry it's me again uh but i i i i'm interested in your process

again there where you said like and then i do the the vcag like and then i just realized maybe i'm

just stupid but uh it's a numbered list right so is there a priority so when you start at the top

do you get like the the most prioritized ones or it's just a coincidence that it's a numbered list

for for vcag uh it's just a coincidence that it's numbered in the way it is

That in itself is not according to semantics. It's grouped and they made the decision to

put it in that order so that variance using an ordered list. So it's your decision to say this

order has meaning. So in WCAG it's perceivable, operable, understandable, and robust.

And that basically this order is like implicit, like, oh, this is like not more important, but like look at this first and then at the second.

I don't think it's like strong, but you can totally do it.

Yeah.

But yeah, I mean, going back to also like the, you know, there's the politics and the business stuff and, you know, people saying, you know, we need to prioritize the accessibility things.

And who are our target audience?

What type of disabilities would be most common in our type of product?

And things like that.

And of course, you don't want to work like that.

But sometimes that's an unfortunate reality for many of us.

To have to be very pragmatic and not really supporting humanity in that sense.

Yeah, that's unfortunately true.

And I mean, it's always a balance.

And there are people who are very strict and say like,

oh, you must do everything perfectly.

Otherwise, what are you even doing?

But I think every step counts.

We're really thinking that,

and that's what we try to do with our clients.

Because the good thing is about accessibility,

every barrier that we remove will help a person

to have a better experience.

And that's awesome.

and of course in reality if you look at like especially the laws and side of things you have

to meet wick hack double a so all double a success criteria and there's no there's no like oh this is

more important or this is less important or whatever it's just like you have to do all of it

and that's that's what it is of course you can decide to ignore stuff like you can ignore um

quick

performance or you can

ignore security

considerations.

But it's not

what you should do, right?

It's inspiring to see

companies like Netflix, for example,

discovering they have this audio

description. A lot of their series

you can watch even though you can't

see. It's so cool

that a company like that

I can imagine it could have been

the opposite, like people saying that, OK, we only have visual content, so we're not

going to do accessibility for people who can't see.

But they did the opposite, and that's kind of cool.

It's probably a lot of stuff behind the scenes that's not good for accessibility there as

well.

But it was an eye-opener to me.

And the reason why they do this is because in the US, they have been always required

to do that because they have much more strict regulation on that or like laws.

And so they had to provide that.

What they didn't have to do is like not only translate all the series into different languages,

but then also pay for audio description in those different languages.

And like if you look at like Netflix or Amazon Prime Video or stuff like that, it can be

widely different between like what the producers are and like where it was like released first and

stuff like that um and i i have to say like one place where this is like astoundingly great is

apple tv plus they do have everything in like almost every language in almost every like

and audio described and sign language for certain things and stuff like that you know captions in

different languages it's really impressive and it's like that's a lot of hard work like

putting making websites accessible super easy because you just like you know you just make some

html and css go nicely making content accessible like for every like hour of television you have to

like commission so many people put so many you know take so many so much money in your own hands

to make that work. I think that's

much harder than

what we are doing with our

little things.

And of course,

they're all specialists, so

it gets done, but

it's a lot of effort.

I like this discussion about the politics

and how we can make things happen

because that's the way you have to go,

right? You can't force

the business to prioritize

this kind of stuff.

And I mean, that's why you have the laws.

And I'm looking forward to when we have that discussion,

when we can talk about how you can prioritize and make others believe that you have to do this.

And then like, what parts of this do you have to do?

And so on.

Yeah.

And it's like, it's always been a struggle against like other business priorities.

Like, as long as like, we've seen this with stuff like GDPR as well, like, nobody takes data protection serious unless like, people say like, oh, you have to pay a lot of money, or you take it serious, right?

And accessibility is the same thing because people think like, oh, this won't affect me or this will affect only a little bit of my business or stuff like that.

And then they don't realize like, oh, 20 to 25 percent of people have a disability or multiple disabilities.

Lots of things we don't even think about are disabilities.

You know, if you are like sick, if you have children, if you have a child on your arm and you try to do something, you know, stock up your online groceries or something like that.

It's like these are all things where accessibility principles help everyone.

And it's not, it's not, you cannot isolate that.

That's when people come to us and say like, oh, what do I save over three years if I make my website accessible right now?

We can't, oh no, like this is unpredictable.

But you have to do it like really step by step. And this is one of my personal philosophies is also I try to inspire people and get them on board with making changes and, you know, try to help them making simple fixes relatively quickly.

And then get them thinking about like the big picture, because just thinking about like, oh, I need to like make this, fix this ARIA label, I need to do this.

It doesn't give you like the step back that you need to see the big thing.

Because for me, a lot of accessibility honestly is avoiding building barriers in the first place.

and if you don't make that experience if you don't go through and you say like oh here's a barrier

and this is a barrier this can be a barrier in certain circumstances you will never get to where

you avoid them in the first place what you will do is you will run into the same barrier again and

again and again and that is frustrating that's expensive so by getting people on the table and

talking through things and like taking them and if they push back that often happens um you know

you say like yeah this is this is a good discussion but yeah you know the law requires it or we really

recommend you to do that and then you know some people get the message and some people don't and

that's also okay um like no one who is in accessibility is in there for their own well

I shouldn't say that.

Like most people who are in accessibility are not in there for their own ego.

Like we want to improve stuff.

We want to help people improve stuff.

We want to make people not frustrated about the topic because in the end, it's a social justice topic, right?

It's a human rights problem.

So we want to make sure that people like to do the right thing, like to do the good thing.

um and that's like you know when people say like oh you say x and y like you had this discussion

about like automated tools like uh overlays that promise you to like one click make your website

accessible which is impossible but they do and like a lot of people push back including me

and some of those companies say oh they just don't want us as like you know to to like get

their clients and I'm like if your tool works if it like if there's one click that makes the whole

web accessible I'm the last person who doesn't want that like yes but I was thinking about that

Eric in your auditing because for me it feels like as a UX designer our main work is making

something accessible because we we test it on users we try to make it you know understandable

and then the things we're talking about now are like below like underneath for screen readers

and stuff like that and then i was thinking about the auditing for me a big part of it would also be

like how do users perceive it and use it and understand it which can't be audited by using

tools or looking at the age levels and so on. Yeah, but it has to be done testing it on real

people. I mean, the tool is one thing, but when you're doing real user testing, I mean,

that's part of our jobs. And that's what I find so interesting with this, that it's just another

layer on the UX scale, so to speak. Yeah, and this is actually a good point.

One of the reasons why I say don't do what I do is because I have 15 years of speaking to people with various disabilities, observing how they use assistive technology really in a very analytical way.

So I factor that in my manual testing as well.

If you don't have that experience, super hard to do that, right?

So I know when I see certain HTML, certain ARIA, I know how it works in screen readers.

I don't need to test that specific thing with a screen reader user, or I can use a screen reader to validate my assumption.

But that's not always the case.

So sometimes there is the thing where you go like, I think this is technically okay, but does anyone understand this?

And then you have to go into usability testing.

The complicated thing about accessibility usability testing is if you test with one person, you have tested exactly with one person.

Like it's super hard to like get those results and say these are now universally applicable to everybody.

Because my colleague Daniel, who is a low vision screen reader user, but also a nerd.

Like, he has, like, probably the most, like, you know, smart home that I've ever seen.

And it's like, he's a real nerd.

He makes stuff work for him, you know.

And so he will not have the same problems.

He probably can, like, emulate being a normal user.

But, like, if you would, like, grab him from the street and, like, ask him to do something, you would get his, like, unique view.

And then there are so many assistive technology as well, like how different screen readers work, how different voice inputs work, that whole stuff.

It can be very, very different from each other.

So what we try to do with accessibility and the automated and manual testing is to level the playing field for all.

And then you look at individual solutions and you test them with different people with different disabilities and see how they work.

I also think that it depends on what service and product you as a company is providing, right?

So if you're providing something for everyone, then it's even more important than if you have maybe a small like niche product.

Because then it's more like a service for the society sometimes.

Yeah. And one of the things that I always say, even if we do, like in Access Lab, we do usability testing with disabled people. And I think it's super important. Once you know that your site is technically accessible, then doing that.

Because otherwise you run into things and like some clients do that.

They say, no, we want accessibility testing with disabled people from day one.

And so, and we already know from like looking at the code, that stuff is inaccessible.

You know, it doesn't, you don't get any results.

Just people get frustrated.

And sure, you can use that and show that to the client and say, see how frustrated they are.

But in the other, I don't need to put a disabled person through that to figure that out. So, yeah, but yeah, I think that's good. But then the next step is to say like, oh, thinking accessibility first, that means also at some point feedback first.

because the only people who can give you real feedback about your product are the people who are using it right now.

You know, not some, like, laboratory usability testing that's always hard.

But, like, what are the needs of your current clients?

And that's, you know, where we talk about, like, more organizational structure things,

like making it super easy to report bugs,

making it like super easy for disabled people

to like get someone on the phone if they want to,

you know, get the feedback in,

saying like, oh, this thing technically works

with my screen reader,

but it's super hard for me to use, stuff like that.

That's the next step.

Like, and, you know, this is like,

but this is all then human stuff.

Like this is not accessibility technical stuff.

This is all like human stuff.

just try to be like be good person and a good good company and like be able to get that but

you know to get there it's like you have to go through like making sure like the basics are

accessible i think also like going back to what you said hannah about like maybe if i understand

you correctly like making it a part of your daily work as a product designer or like i've been

thinking a lot about that like how do we make it so just like an architect you know uh they don't

it probably comes natural to the to design because it's been around for a longer time like if there's

a curb cut of the sidewalk no no one questions the curb cut of the sidewalk like and it's being

no and not anymore so so people are using it for bikes they're using it for uh for strollers

or carry-on luggage, you know.

But, like, that's my main concern.

And also, going to your colleagues,

sorry, I don't know your name next to Hannah there,

but, like, how do we turn it into reality

so that it's, like, embedded in what we do in every day?

How do we, you know, make sure?

And I think one idea that I had is, for example,

when we did keyboard navigation analysis,

I was like, this is information architecture.

This is, like, how we structure the page.

So you just need to sell it sometimes as well to management or others.

Like, okay, we're improving how the page is structured, you know, where things go and

how people move around on the page.

And then, by the way, it happens to also now be compliant with, you know, VKAA.

Because it's just going to be one part of it.

Like, it has to be natural.

Like, okay, now we're doing this other thing.

And then it's just like this accessibility principle, it just, it just, should we just

go in there?

It should be like a foundation or like a basic thing.

Yeah.

But I think you have to practice your arguments, right?

Yes.

So.

Exactly.

You always have to do that.

Yeah.

Whatever you do.

One of the things is that we have a lot of like practices currently that are contrary

to accessibility.

Like, you know, I mean, if you look at like all the like push towards which now is like turning around a bit to single page applications, for example, like putting everything into one JavaScript thing and like managing everything yourself.

Those are technical, like, design choices, you know, in that case, but also, like, of course, design choices, like, if you have text on top of an image and stuff like that, you know, those are all of those things that prevent you from doing accessibility in an effective or efficient way.

And so, yeah, the thing that I think Hampus will talk about is this shift left into like making accessibility a thing in your planning, in your like, oh, these are the things that we need to look at for accessibility.

and then you will make choices that avoid accessibility barriers automatically.

Because if you know from the start that if you have a big background animation on your page,

you need to have a pause button to pause that animation,

you will design a pause button in the site and it will look good.

It will be okay.

It's not like when you design doing everything

and at the end an accessibility person comes around and says like,

oh, there needs to be a pause button here.

And you go like, oh, come on, where do I put this pause button now?

You know, it's like you front load that.

You say like, oh, this is a decision we do.

We want this video.

So we need to have this button.

And then you have the choice of saying like, oh, we don't want a video after all.

You know, we're okay with the image.

Are we okay doing something else?

You know, so you have, with knowing about accessibility at the beginning, you have choices that you can do.

Once you have made your choices, redoing those choices is obviously more work than incorporating it.

And I guess it always depends, but most often you have a lot of legacy, right?

You're coming into a company and you're working stuff and you have like 20 years legacy in the systems.

So there's always a lot of work to change stuff that's already there.

Yeah.

And there my recommendation is change the new stuff.

Don't look at the old stuff.

It's like reusable stuff.

If you have a website or web page or part of your application where people are using it and they're heavy using it,

you know, then of course you have to like redo it.

But if it's just like, oh, we have this one view

because there's this one customer that uses it every three years

to export their PDFs in a very specific way

and nobody else finds it,

maybe not put all your X in the basket to redesign that, you know.

And I did that with clients that were like,

oh, we have this like one legacy thing

and it's like, it's really broken and it's really complicated.

and I was like, yeah, put it in an iframe into your otherwise accessible template

and put it in an iframe in the middle and, you know, make three or four fixes that make it, like, bearable

and then be done with it.

Like, it doesn't need to be perfect in those instances.

And, you know, and there is in the law as well, there is this undue burden clause.

that basically says like, oh, if you go bankrupt from doing this,

then you don't have to do it.

Which like, it's very strict in terms of like,

oh, you can't just say like, oh, this costs a lot of money.

I think this is unbearable for me, which is good.

But like, yeah, if you can like demonstrate,

oh, this is like a low use and there is maybe an accessible alternative,

you know, or like, even if you like make a plan and say like, oh, this will be redesigned in like

a year and a half anyway, you know, and you know that and then you can incorporate accessibility

into that. So there's a lot of flexibility in how to handle it. You just need a plan, right?

That's always the most important thing, like have a plan first and then, you know, you can

can react to things that come from from the outside i think one of the things i've been

thinking about is the design system like and how that can help in terms of the the new stuff that's

being built if you if you create a design system and all the new products are based on that so i

was kind of wondering if you you were planning to talk a little bit about you know how to think when

you're building your design system accessibly or in that sense?

Yeah, I think Hampus has a whole thing about design.

At least I hope he does because I don't.

But yeah, I think he has a whole like day of design.

I think design systems and just being systematic in your design.

I mean, this is like, I think we've gotten better with that,

but it's still not great.

with like you know components and stuff like that what what I see is a lot of like over

like I don't know in tv or or cinema you would say it's overproduced like oh they try to do too much

like it's it's it's more than it needs to be and I see that in a lot of design systems but in general

that's the right thing to do like have legos have components that you put together and that make

your stuff accessible so you don't need to reinvent the wheel on every page but it's also

totally okay to like say uh because that that was the feedback that i got a lot when i when i said

like yeah get a design system in you know uh or framework or whatever uh it was always like oh

but we want to be flexible and then yeah you can be flexible in instances but in general you want

to have things that you can like reuse and yeah, and just put in context and then it's okay.

All right. This was a good discussion. And I think I need a break before we have the individual

things. My brain is great today. Yeah, thanks for the lively discussion. I think this is really

good. If you want to continue this in Slack, that's totally fine. And just, yeah, just feel

free to like ask questions. We really like doing that stuff with you too. And yeah, and I think

next week it's Hampus turn, which means I have a Tuesday off. Well off I do other stuff. And then

I think I'm back. So have a good rest of your day and see you around. Bye.

Take care. Bye. Bye. Bye.