Live Session (2024)

All right, welcome to our first live session. That is like the proper deal. Happy to have you all here. I hope you will not be too much bored after this and enjoy what we're doing.

So the first thing is a couple of housekeeping things.

I hope you all have seen the videos that we uploaded before, because that's basically what we're trying to do is give you like all the foundation before.

And then you come into these live sessions and we have like maybe a discussion, maybe questions.

Maybe I just show stuff off really depending on like, you know, what your needs are.

And we are recording these so you can also like if you don't have time or you say like, oh, this, I think I have understood everything from the initial video.

I don't think I need to be in there to like, you know, to sit around for two hours or an hour and a half, however long this is.

You know, totally fine to say like, oh, I just watch it afterwards and get my information from then.

Yeah, and that's basically that housekeeping part.

The other housekeeping part is that we have the, what are they called?

The one-on-one.

Oh, my brain.

That bodes well for this session, I tell you.

What is it called?

one-on-one tutoring that's how we call it um and there are still open um open times for this week

and next um it's totally fine that like you think like you know we haven't heard eric at all so we

haven't booked anything you know i don't take that personally um but if you have like for next week

something also you know feel free to like put in your time early and if you don't have um uh if you

feel like oh i don't you know it doesn't it doesn't work time wise you know always feel free

to reach out through slack and uh and ask for um uh for for another date or time uh because we try

to accommodate that for you as well. Another thing that I put online but I haven't linked from

anywhere is that I started putting online the transcripts for these meetings. So

So, now we'll put that into Slack as well after this. So, let me quickly share this. Let it put my share up there at the top. So, this is the thing. I'm going to optimize that.

and share. So this is the link here at the top. It's chas-transcripts.yatil.net, which is like, anyone can guess that. But there's basically a place where like, if you had, I don't know what, oh, these are double because I didn't delete them. Just pretend those don't exist.

But basically where you can say like, oh, for this week, like for the video, I can read through the text of the video.

What I said, it's basically like the captions just as an HTML site allows a little bit easier for like search and replace.

It's not perfect.

Like here we have a tag that should be a G.

So I probably should like review those a little bit more closely.

But yeah, that's basically what you have.

And if you want to like review it in the video,

you can click on show timestamps.

And like, then you see like,

oh, it's like at one minute and four seconds.

And you can, you know, go into the video and find them.

So yeah, try to set this up today

just to make sure that we have a little bit more of that.

didn't really suit the way that the chess infrastructure thing works.

So there's the, you know, the just like, just doesn't work well enough

to support this amount of transcripts and stuff.

So it's a good way to look at that.

And I hope to complete all of the courses, all of the transcripts until the end of the course this week.

Because I have already all the videos.

And I will also caption and transcribe these live videos too.

So you get all of that in all of the formats.

Because that's a little bit what accessibility is all about.

Yeah, so any questions, any clarifications you'd like from the video, from the introduction to WCAG, anything that I should be like more in detail, anything you'll say like, oh, this was hard to understand.

And I know that this is very technical.

And the nice thing about these sessions with me is it will get more and more clear over time.

I know that this is a lot of text and stuff like that.

But we are going to improve.

Your understanding will improve or will get higher.

And so you will have an easier way to actually understand it over time.

That's just how it is.

I don't see any hands.

I don't see any messages.

So I guess you're okay.

I always take that as I explained everything perfectly.

So there's no questions, which is not true.

Okay.

I want to quickly go a little bit over the history, like the WCAG 1.0 guidelines to give you a bit of context on why WCAG 2.0 is how it is.

I talked about that in the video, talked about that a little bit also in the WCAG 2.2 section.

But I think seeing what WCAG 1.0 is and was, because it's now officially superseded, is probably like a good thing to just have in the back of your head.

Because it explains some of the like, you know, this is weird stuff that is going on in WCAG and that I will like, you know, help you navigate through.

So the first thing is that this was in effect basically for 22 years, which is quite a long time on the web from 1999.

I talked about that.

And it basically laid the foundation for a lot of things that we are talking about today,

like all the user agent concepts, the web content concepts, and all of these things.

And that's actually pretty, pretty cool that it did that so early.

And the reason is that disabled people haven't changed, sure,

like how they use computers that you know they use like mobile phones uh stuff like that that

has changed that's actually a big change but the basis on like what you need uh as a screen reader

user as someone who's blind as someone who is like deaf those needs they stayed the same so

So it was relatively easy to get that into even the first run of the WCAG.

And then we made that better over time with the knowledge and experience that you get.

And the web was still growing exponentially.

So it's like, what did we know in 1999 that would be coming up?

And I also realized that this 1999 is probably for some of you before you were born.

So that's always fun to realize because the web is really old now.

When I started with this, which was around that time, like 2003, it was all new.

And like, you know, it was like really, really like mind blowing.

And now we have this for such a long time.

And like the basis is still the same, which is like, I think it's pretty amazing.

Anyway, trying to not feel old.

Yeah, it has a pretty like sizable introduction.

and it also talks about accessible design.

This is something that WCAG 2 does not do in that way.

WCAG 2 is way more focused than WCAG 1 was.

The reason for that is because it had to explain

what accessibility actually was and accessible design was.

And WCAG 2 took the spaces and needed to be more clear and more focused because this was not so easy to maintain over the time.

But yeah, so there's actually an introduction on what is important.

And then we go into document conventions.

And this is where you find the most difference to what WCAG 2 does.

so WCAG 1 was very much for HTML

there was no things about PDFs or anything

it could not apply to that because it was very much tied technically to HTML

and so you have actually real elements and stuff like that in this

So it says like element names are uppercase letters, attribute names are quoted in lowercase letters.

And then you have links to definitions, which look a little bit different.

And that's like a significant change or significant difference to Recag 2 because of just how when this came about.

I should also make the text a little bit bigger so you have an easier way to see it.

Then we have priorities here. Priorities is basically what the WCAG levels are in WCAG 2. So there was priority 1, priority 2 and priority 3. And these are for the individual success criteria, which didn't, they were not called success criteria, were they?

Checkpoints, they were called checkpoints.

I have not used this for a long time.

So for different checkpoints, they had like their priorities.

So this is priority one checkpoint, priority two checkpoint, priority three checkpoint.

And then that was translated into conformance levels for A for all priority one checkpoints, AA for one and two, and AAA for one, two, three.

So, and then with like WCAG 2, they said like, yeah, the priority thing that didn't really work out. So, we just put the level on the individual success criteria.

Can I ask a question about the levels? Isn't AA what you need to fulfill to, why is there a level A? What is the use for it?

That's a good question. So basically, this is like, as I said, historic stuff. If you ask about WCAG 2.0 level AA, yes, that is what is in the law as the basis. And basically, that means you have to conform to all WCAG 2.2. Let's switch to the right.

WCAG 2.0 A and AA success criteria.

And the reason why there is a difference is mostly historic.

So when WCAG 2.0 was introduced, there was the decision of like,

okay, how can we help websites to be more accessible?

And so the idea was that there is a level A that everyone could get to,

and then they could work their way up to level AA.

Today, these level A success criteria are all so basic and so, like, yeah,

so, you know, inevitable that no one makes that distinction anymore.

And if you want to read more about it, I actually wrote a blog post recently about that

called WCAG's A and AA distinction is mostly academic, which it is.

So basically you have level A and AA is used in two different ways.

So in WCAG, you have your non-text content has a level A success criterion,

and then you have the conformance, which is basically also levels.

And it's like a little bit of like, oh, we have these two things

and they are connected, but like it makes it harder to talk about it.

But yeah, text alternatives is the absolute basic thing.

And then, you know, you get into like more elaborate thing,

like having live captions.

Those are harder to do.

target like fewer people so it's like uh it's it's like double a and then you have triple a

which is like yeah this targets like even fewer people um and it's even harder to do so you know

it's like triple a that's inessential what it used to be uh nowadays i say level a is like

the basic stuff that you need to make it fairly accessible to a number of people and then level

AA is like making it accessible to many, many people, because that's never fully accessible.

Manfred. Yes, hello. Follow-up question from the lecture material from the video before.

So did I understand you correctly that you said something about AAA being almost by design and

we're not supposed to be able to reach it, but it's more aspirational. So then we have A that's

not used and AAA that is impossible to reach. So it's just hanging there on the sides.

Yeah. I mean, A is used as a level of success criteria. So you have to put audio description

or media alternative into it.

And you have to put like here,

you have to put your alternative text in.

So subset of AA.

Yes, but to reach AA conformance,

you have to meet level A and level AA.

So having those two separated

as part of the success criterion

doesn't make a lot of sense

because you have to reach those two always,

basically to be conformant.

The aspiration is to push everyone further and further,

and then eventually maybe even AAA will be reachable.

Yeah, I think that was the initial plan.

I don't know how well that works, to be fair.

So if you go to conformance level in WCAG,

it says basically here it's not recommended

that level AAA conformance be required as a general policy for entire sites because it's

not possible to satisfy all level AAA success criteria for some content. So you might even

run into like, oh, I want to reach this AAA success criteria and this AAA success criteria,

and they conflict. I don't have a good example for this happening, but they must have come across an

example that they put this note in there and that's that's really interesting but for example

let's go and stay in media because I think that's always the most interesting thing for

for AAA or the most easy to understand stuff so when we go from pre-recorded video so this

means I have an audio or video and the audio has no video with it that makes sense and the video

has no audio with it, then you have A as the basis, an alternative for it. So if you have

an animated GIF, for example, it's totally fine to just have an alternative text to it

because it's the media alternative. If you have synchronized media, so that means audio

and video, then on level A, you need to provide captions if it's a recorded thing. So if you

If you have like a news broadcast and you put that on the internet and it's pre-recorded, then you need to put on captions.

But if it's live for level A, you don't need to do that.

You need to do that for level AA.

So effectively, all your videos need to have captions, no matter if they are live or not.

But that's basically the difference.

That's where the step up is.

And then for AAA, you have things like sign language for pre-recorded videos, because making sign language required for all of the videos might be great for people who speak sign language as their first language.

and we have sometimes a hard time reading captions

because I don't know how well versed you are with sign language,

but it basically has different grammar.

It works completely different than spoken language.

So some sign language speakers have a really hard time with written language.

This is now better that we have a lot of written communication, of course,

because that's becoming one of their primary languages too.

So that has been a fun development.

But basically telling people like, let's say,

Chas, who is doing like these types of courses,

every video needs to have sign language.

That's like a huge cost and it's hard.

And, you know, so they opted to put it into Level AAA.

And that's basically the idea behind that.

So it's everything that, like, yeah, you should be doing this,

but we understand that, like, it's not achievable for, like, in all situations.

And so we don't want to put it on level AA.

Yeah.

And if it was, if people ask me, I think let's get rid of the levels altogether

and remove the AAA stuff from WCAG because nobody is doing it anyway.

That has been my experience.

And the AAA stuff, you could put into a separate document

or you could do it maybe differently.

But I think it's more like, yeah, you have these

and it doesn't make a lot of sense.

to have them. Yeah, but that's all for WCAG 2 and for the current, like, you know, regulation

and stuff like this. Yeah, but, like, the conformance levels, they existed, like, in 1999,

so this is all not, like, accessibility is all not that new thing on the block that people make

it out to do and I just want to show like one of the checkpoints because they have basically

repurposed that in WCAG 2 as well so if we go to checkpoint 1.1 we'll make this a little bit

larger even because they have very dense text so I think it's hard it's pretty hard to read

So, basically what they do here is they say you should provide a text equivalent for every non-text element, for example, via alt, longdesc, or in-element content.

This includes images, graphical representations of text, including symbols, image map regions, animations, applets and programmatic objects, frame scripts, images used as list bullets, spaces, graphical video, sounds played with or without user interaction, standalone audio files, audio tracks of video, and video.

There's a lot of stuff in this thing. And then they say, for example, in HTML, use alt for the image input and applet elements. There is no applet element anymore.

We used to have a lot of fun stuff floating around on the web.

Or provide text equivalent in the content of the object and applet elements.

For complex content, the alt does not provide a complete text equivalent.

Provide an additional description using, for example, longdesc with image or frame, a link inside an object element, or description link.

Longdesc doesn't exist anymore.

There's a lot of stuff that just doesn't work.

But this is basically how they started this.

And you see that it's very much like, oh, what do you do in HTML to do this?

And it's very much technology-specific, animated GIFs, all of that stuff.

And yeah, it's a really interesting approach.

And of course, you only had that type of technology disposable for you.

So when WCAG 2.2 came around, there was a lot of additional stuff.

There were already PDFs.

There were things like Flash games and stuff like that.

And so the idea was for WCAG 2.0 making it much less specific to HTML and web technologies.

which means that the language is a little bit more reserved and a little bit more like open

but it applies to a lot of different things and this is and I talked a little bit about how to read

WCAG in the video this is basically what they did so basically you start with a statement

and then you have exceptions to it and almost all WCAG criteria are built that way and makes

a lot of sense. So here we have all non text content that is

presented to the user has outer text alternative that serves the

equivalent purpose except for the situations below and then

there's a list of situations. So Ma. Hi, I was wondering when I

saw this at first, I was thinking that it would be really

nice to have like practical examples to these exceptions. Do

Do you know if there is a good page for that?

If you want to read more about it?

Great question.

Great question.

Indeed, we do have that.

So this is basically just the, so what I like to call, like, this is the law.

And then you have the, like, how is the law applied in practice?

And when you want to learn more about success criterion, like here, you can go to this understanding link.

and that goes to the WCAG 2.2 understanding docs.

Are you showing something on your screen?

I am.

Is it just me that can't see it maybe?

I can see it.

You can see it.

Okay, maybe I have some.

You chose the wrong tab up in the interface.

You chose one that says meeting and one that says Eric Eggert.

So you switch from reading to the Eric tab.

Ah, okay.

Thanks.

I'm not used to Zoom.

Awesome.

Yeah, they have really like broken this a bit.

Like this used to be better.

So sorry for that.

Let me try to reload that.

So this is the WCAG 2.2 understanding text.

And that basically, it gives you this in brief, like introduction, what it does.

and then repeats the success criterion because we expect that people go to these pages not only through WCAG.

So having the text there is very important.

And then you get intent of the success criterion, additional information.

And this is terrible. There's so much text and it's like a wall of text.

Benefits, this is like a little bit better with like bullet points.

And then you have the examples here that give you a little bit more insight.

And then on the very bottom, under the related resources, you have the techniques.

And techniques are basically examples.

I think they should rename that to examples.

It would be a much better thing to do.

So in this case, you have like what you can do is situation.

This is also one of the most complex and confusing example.

If a short description can serve the same purpose and present the same information as a non-text card.

And so, yeah, this is very confusing.

But basically, you have things like H37, which is an example on how to use the alt attribute on image elements.

And then you have this example.

And then, you know, you can see your test.

And you can just get into those, like, more and more.

Yes, Dick has quite a good page.

It's a good link for those.

For what I've heard, because I'm not a Swedish, like, speaker.

But from what I've heard, they say it very clearly what you need to comply to.

Reading the chat.

Yeah, exactly.

So the question was like, oh, you know, can AAA criteria met?

Yeah, they can be met.

The individual criteria can be met.

like providing sign language, you can do that.

But the effort to do that is so much higher

that it's not like in the baseline

of what you need to do for accessibility.

That's where the AAA comes in.

And I also think like sign language as the specific example

does not collide with any other AAA success criteria.

As I said, I don't know how they came to that.

but like there is content where like sign language will not do it

like if you have let's say a game that could be interpreted as like you know audio visual content

and then you could say like oh for a game like this is like impossible to me

I don't know really grasping at straws

And actually, WCAG has like a similar thing to DIC. Let me see, where do I go? So if you click on the how to meet non-text content here, very small link, then here are the techniques again.

and this is like this is um basically a filterable way to look at wickhack so um here we have all the

techniques and i think they're a little bit like more compressed arranged so it's easier to scan

and here we have like these situations because this is such a complicated

success criterion with all these exceptions so if we go to an easier one which we should

because this is too hard.

Like orientation, I like to show orientation

because this is very straightforward.

And it says content does not restrict its view operation

to a single display orientation,

such as portrait or landscape,

unless a specific display orientation is essential.

So this has the statement and an exception,

which is like, oh, that's an essential way.

And the examples that they have is like a piano keyboard on a tablet.

Like you want that in landscape because that makes more sense.

And then you have the techniques in here.

So using control to allow access to content in different orientations, which is otherwise restricted, would be one way to address this.

Like you'll just have like a button or checkbox that says like, hey, let me use this in a different orientation.

And then you're able to do this and then you're meeting the success criteria.

So whenever we like are testing for success criteria, we basically look through, we look, we open the page on one side.

WCAG sometimes on the other and say like, oh, does this content, this page restrict its view to landscape or portrait?

And if it doesn't, then it passes WCAG.

And if it doesn't pass WCAG, then it's a failure and we write it up.

And there are two types of techniques.

There are three types of techniques.

Sufficient techniques, those are basically the minimum you have to do in general.

And then you have the, what are they called?

I should know that, but my brain is not working great today.

Advisory techniques.

I was advanced techniques.

That's not it.

No, it's advisory techniques.

So advisory techniques go over the minimum and tell you like, oh, you know, in this case, this is the success criterion for info and relationship.

Basically, anything that's visible on the screen needs to be in programmatically or as text in the website.

So if you have headings, they need to be headings in the code of your website.

So you get things like using role heading to identify headings.

Yes, that does it.

Like this meets the success criterion.

But it's better, the advisory techniques, to use CSS to control a visual representation of text or to organize the page using heading elements, basically.

So you get like a little bit more like on top of like this is the minimum you need to do.

These are basically best practices there.

And then you have failures here at the bottom, which basically mean that these are examples on what you can do and fail the individual success criteria.

Like here, it basically tells you, oh, we did this one thing, like here it's a P with a heading one, and that would fail the success criteria.

So try to give you like examples on like what is not acceptable in those situations.

So that's how you get to like more practical examples from the actual like WCAG specifications.

And I would recommend using to go from the quick reference.

Most of the time, what the quick reference does not have is all the glossary items at the bottom.

It should have that, but it doesn't for reasons.

And so, you know, if you want to know, like, what non-text content means, you have to go back to WCAG and, like, see what that means.

But you can filter this, how to meet quick reference, as well.

So if you say, oh, we're doing European Accessibility Act, don't really care about the new WCAG 2.2 stuff, you can go and say like, oh, I only go to WCAG 2.1.

And then like the WCAG 2.2 success criteria are all like hidden from view.

and then you can say like oh I'm currently working on uh contrast uh for icons and then you click

uh those those um tags here and then it says selected filters regex 2.1 success criteria

tag with contrast or icons and let's see if that works. So there's identify purpose and then there's

contrast minimum, images of text, contrast enhanced. So you see all of those and you can say like oh yeah

I don't actually care about the AAA criteria. So you click them away here and then you can say

I'm not interested in advisory techniques and failures and I only use HTML and CSS.

and then you only see HTML, CSS techniques for the selected text.

And that's really neat to have that.

If you want to dig down like, oh, what's the matter with this?

So yeah, I can only recommend that.

Tobias.

Yeah.

Hi.

So I have a question regarding this information, because it's a lot of developer code, how you structure the code and so on.

If you read a lot of these examples, and if you look at, for example, DIG and WebRichtlinie that we talked about, they have separated the information.

So you have this information is important for developers.

This information is important for designers and so on.

Is a way of filtering this information in a similar way on this site?

Yes, here on the left you have the text, and you can basically say, like, it's only for interaction designers as well.

I don't know how good these texts are, and the reason I say that is because I came up with most of them.

So it's like they have not gone through, like, a dedicated, thoroughly reviewed way to do that.

and they are very old now, which doesn't matter because the content doesn't change, right?

But it's like, you know, if there are suggestions and stuff like that,

it's a good idea to let people know about that.

But yeah, you can say like, oh, I want to know what like, you know,

if you have carousels, that's probably like a decent example.

And I only want to know like what an interaction designer needs to know

about carousels or I only want to know what developer needs to know about carousels, you will get different results for that.

Yeah, great. Thanks.

Yeah, so that's this. I think that works well.

Sophie did put the really great, it opened that in a different window that you cannot see, Regex documents resource. I really like this resource. And I've also seen the old diagram is actually not that bad.

There used to be a new diagram for this.

They seem to have removed that.

But yeah, this is pretty nice to see how it is supposed to work together.

And sometimes it works better and sometimes it doesn't.

But yeah, this is a good...

Anything that you find under w3.org slash WAI is always a good resource.

I worked with them for six years, seven years almost.

They are really good people.

They did like, you know, a lot of like brain matter went into those resources.

So I will show them quite often, actually.

And this is one of the good ones.

Yeah.

And so I really like that.

And it gives you a good overview.

And yeah, the WCAG at a glance is great for getting like a large overview on WCAG.

Like these are all the things that you can go to when you say like, oh, I know Eric has talked about this, but I totally forgot.

Because this will happen like often because this is really complicated.

So going there and like clicking through them and getting like a refresher or like a pointer on what is what is really, really useful.

Yeah, I did talk a little bit about what's new in, well, I did do a video for this.

I didn't do that for last year, what's new in WCAG 2.2.

So I don't think we have to talk about that a lot.

And before we do a little short break, I want to talk just a couple of minutes on like WCAG 3.

because you might be seeing that out in the wild people talking about it.

And the current status is exploratory draft.

And that means what it says on the tin.

Like they are exploring with ideas, nothing is set in stone.

There is nothing done about this yet.

Like this has started.

This is like, yeah.

My advice is ignore anything that says anything about WCAG 3.

It's not worth putting your time into it at this point if you don't want.

Like, if you want to work on WCAG 3 and make it better, go ahead.

I will not stop you.

But for like, oh, I want to use this in my work right now, this is way too early.

And it probably takes, like, what do they have in their timeline today?

I plan to upload it every three to six months.

A few more years.

Oh, they didn't even put a timeline on it.

They used to have, like, you know, 20, 30 on it and stuff like that.

And I think that's probably, like, the earliest we're going to see something, like, really materialized.

that we can like say this is a Finnish standard. So yeah, it's currently no idea how far they are.

They want to update it every six months. They have last updated it in May. So let's do an update.

And I talked to the, like one of the working group chairs and they said like, yeah, we're about to

updated, which means it's probably going to be updated, you know, after six months, which is cool.

But yeah, it's not, it's super early. So don't, don't put your eggs in the basket. One of the

things that you might come across is a new way to calculate color contrasts. You know, you can do

that, but you should also verify that it works with the WCAG 2 algorithm. So if the colors meet

both then you're good otherwise like if you get like tested by dick or whatever um they might say

like oh yeah you you said you are meeting like this wickhack3 thing which doesn't exist yet

um uh that that is not good enough for us uh so uh that's that's like a big thing that that creeps up

you know on linkedin and and stuff all the time and like yeah hold your horses the wickhack2 stuff

is pretty good

and there's

no need to like

grasp for WCAG 3

things especially this early in the

development

yeah

now let's do a

10 minute break until 2

and then we're

gonna reconvene and

talk a little bit more

about WCAG

see you

there we go and we're back um here uh in in chat there was the question about where do we find the

quick reference and i put the link into the chat it's also linked from the

Chars page. So if we go to charsacademy.infrastructure.com.

Oh, not the 2022 version. You don't have access to that.

Which one is this one? This one is this year's. Nice purple one. So if you scroll down to week

three which is the current week links from the session has those links as well so we have all

the WCAG versions and then there's understanding and techniques and how to meet WCAG quick reference

and then I will talk a little bit about the the other three things in a minute but yeah that's

that's where you find all the stuff so we try to put everything like online as much as possible if

you miss something there's always lack to ask and then we we add that you know because sometimes we

improvise like uh i know hampus is a good good improviser uh and i try i try to do my best

but uh but yeah that's that's where you usually find that um and links from the sessions give you

uh give you those um

Yeah, and that's how to meet and when you get to the page, there is this filter button, like you can either use the contents, like the table of contents, or you can switch to filter both.

That gets you there. And the nice thing about the quick reference, I did not did not say this before, like, so when we made our selections, let's say,

let's say buttons and markup and I only want developer stuff.

Yeah, this has some things in there.

I don't know.

It feels a little bit like a weird combination of things, but okay.

That's what I checked.

Sometimes clicking two texts does not make a lot of sense.

Then here at the top, you have expand all sections.

And that means that like here you have show techniques and you need to click on those.

And then you sometimes have to like show more underneath them.

Or like if you have exceptions, they are sometimes hidden.

I don't think we have a good example here.

But you can click expand all sections and it will expand all the things in here.

And then you can collapse them as well.

And you can also share what you're seeing.

So if you have a colleague, like a developer, and you want to say like, hey, this is the WCAG stuff you have to look at for buttons.

You can click that and then you can click on the share link and you can copy this URL, which has like a very ugly like URL here at the back.

But basically that will then, once your colleague opens it, will apply the same tags and the same filters as you have done.

So that can be a good way to like do like a little bit like internal communication, making sure that works.

and if you don't want to see this left side at all you can even hide it and then we show it if you want to.

Yeah, a lot of functionality in this.

And I'm really proud because I worked on this.

So I like to show it.

It's all like showing my own pride of things that we've done.

yeah I talked about the techniques

this is also a sufficient technique to

week 1, 3, 1 info and relationship so this one

basically tells you if you have a list of things you need to use the

appropriate list element for HTML

and yeah it goes quite deep into

like code and what you need to do

So I think there's no, these are really like decent examples for what to do.

And there's a list with all of them at the start.

This website sometimes doesn't look right and I don't know why it is.

Oh, because this is WCAG 2.1, it should be 2.2.

Yeah, I just noticed that exact same thing and wanted to ask you about it, if it was meant to link to the 2.1 techniques, or if you wanted to link to the 2.2.

Technically, I always want to link to the 2.2 techniques now.

Because these are like, the thing is, the nice thing about WCAG 2.2 and 2.1, as I said in the video, is that they are additive.

So looking at the latest for a WCAG success criterion that was in 2.0 or 2.1, looking at the explanation in WCAG 2.2 doesn't change what you should be doing.

So 2.2 is the thing, the latest that you should look at.

And I will change the links in the canvas on that.

does the page stay updated when things are changed added so you can trust it fully it's a good

question uh when rekeg 2.2 came out actually they didn't update the quick reference uh right away um

so i i added the stuff and and submitted that as a like community contribution um but yeah uh so the

generally all WCAG stuff should be updated.

Now WCAG 2 is not supposed to be updated ever again.

Like W3C says, this is done.

If this will be the truth in the future, we don't know yet.

But today there is no working group that works on WCAG 2 stuff.

Nothing happening.

The one thing where you might see a difference between understanding and the quick reference is in individual techniques.

So when they add techniques to WCAG 2.2, like here, they might not add them to the quick reference at the same time,

because those are separate processes for historic reasons that I don't want to get into, because I have PTSD from that discussion.

but

pretty literally

but the thing is

there's not like a one to one thing

but the techniques are also not that important

like once you have the hang of it I don't think

like you should be needing the techniques

too often and if you want to

like see what the current techniques

are you can always go to the understanding from here directly and that links to the 2.2

and then scroll to the bottom and there are all the techniques

so i tried to hide the in brief stuff here and it totally totally broke my

my view so i have to see how i can fix that but you know this is this is a me problem this is not a

like them problem for a change yeah but you can have like this really long list of techniques

and you can basically go through them and see how they they work um

so those are the techniques uh and then i want to talk a little bit about the before and after

demo did i did i have that in the links oh i did not okay that's good it's good to know so i make uh

oh where did i where did i put it

i opened too many things

Oh, there we go. Welcome. I'm going to pin this for me so I remember to put it inside of the

links for the session. So this is the before and after demo. And this is actually the first thing

that I worked on when I got in contact with W3C. It's a really fun little page. And basically the

The idea is that it's a demo page of a very inaccessible website and a website that is meeting the WCAG 2.0 standard.

Now, it looks very old because it was done in 2005 or something.

And it uses techniques that we don't use these days, like tables for layout or spacer GIFs.

If you don't know what those are, good for you.

Because we used to, like, there was no way to make layout work without, like, creating a table and putting stuff into, like, different.

It was terrible.

Like, this was, like, the worst timeline.

But there were only, like, three web developers out there.

So, you know, it was pretty well known.

So this is the inaccessible homepage.

And the idea was that we put them and make them as similar as possible.

So that means like from the inaccessible one to the accessible one.

This is not like a big wow redesign.

Never was intended to be.

Because one of the things that you often get in terms of accessibility is,

oh, this reduces or constrains my ability to design stuff.

And point taken in 2024, this is not cutting edge technology.

This is not like breaking any design, getting any design prices or anything.

And I think it also didn't in 2005, to be completely honest.

I think it shows that like, oh, yeah, you're actually not constrained about that.

You know, the measurements are a little bit different because of like how it got built in the end with CSS.

But in essential, we try to keep it as close as possible, like even keeping.

What is the main difference between them?

One is inaccessible and the other one is accessible.

Yeah, I understand that.

But when you switch between them, I can't really see a big difference.

So I guess it's...

Yeah, that's on purpose.

So let me talk you through so you can get a feeling for it.

And I do this on purpose.

So if we go to the inaccessible homepage here, we have this quick menu here.

We have here these images, home, news, ticket survey.

We have here Serif font, which is not inaccessible, but just to give you a couple of things, what is different.

We have this bad contrast over here. I think that's bad contrast.

We have this phone number here, which is also just an image without alternative text.

And I think those are some of the main differences.

Also, this banner doesn't have any alternative text.

And also, this weather information thing has no alternative text as well.

So if we go to the accessible version, this is actually real text.

like I can mark this up with my mouse. This is text. I think this was text before, to be honest,

but it's a sans serif font. Here, the contrast is better. We have now buy tickets and take survey

links instead of, I think it was just buy, or they were just read more links. So you couldn't,

like if you have a screen reader, have a list of things, you all had to read more, read more,

read more read more doesn't make a lot of sense so now they say buy tickets and take survey um

and here for the full story the same thing uh those were just like little images um and here

the phone number is in uh numbers and in like this like uh yeah it's just just in text uh

and yeah and before these were like images so it didn't have like you know you couldn't mark them

i can i can copy and paste them today because browsers today have like ocr built in so this

now works but it wouldn't have worked like 10 years ago or five years ago even um and if you

go into like right click and inspect then we can see that one thing it does

like it has those links here for going to the news for example and it has on

focus blur and that was because people always hate focus styles so back in the

day when you clicked on links they kept the focus border like a dotted line around it

and people hated that so they put often on it like on focus blur and what that did was that

if you're using the keyboard and you try to go through the page and you focus on this with your

keyboard it would automatically become unfocused and your browser would go back to the top of the

page so it would have a keyboard trap and that would be very bad because you can only get to

the first link literally on a page and everything else is inaccessible for you and then there are

images here which do not have alternative text so that means this link to the home page or to

news page in this case has a label. Where does that come from? Oh is this Safari doing fun things?

Because it shouldn't. It doesn't have like an ARIA label of course. It doesn't have the images.

Oh, I think this is metric because this is supposed to be empty. And I think this is just browsers doing metric basically today. Yeah. So, so, huh. Interesting. I haven't seen that before. But if we have, if we have this, we see that inspect element.

doing any of these changes, there's now a list around the individual items, and it just has a link that says news inside of it. So that works out really well. And yeah, and that is just a link. Just link being a link in the world today. So there are differences, but I don't think they're super noteworthy.

you can show annotations.

And that basically gives you now what has changed.

So this is the accessible version.

So you get information about that.

And then also for the inaccessible version,

you'll see what is wrong here.

So in this case, the alternative text is very, very long.

And like the information is hidden inside of it.

Like people are not interested in like how this logo

looks, it's totally sufficient to say, so this is city lights, your access to the city, and that's,

that's good enough, yeah, and so this, this is a nice demo to get you, like, through, and thinking

about, like, some of the issues here, and it links back to the success criteria as well,

and this goes all into, of course, WCAG 2.0, so 15 years back stuff, but it's still,

It's still part of the thing. And it even goes to the same quick reference, which looked very much different early, like 15 years ago. So yeah, really good. I like this a lot. And if you are interested in like, how would a WCAG report look for a page like this?

Now, I personally, I don't do reports that look like this, but this is a good example on how you could structure them.

You have text alternatives, non-text content, and it basically tells you what failure techniques you met or where you failed on.

It's a good, decent way to do it.

I don't do it like that because I think this doesn't feel like super useful for fixing stuff.

And I'm about fixing stuff, not just explaining, oh, you made an error here.

Yeah.

So that's a good one.

Oh, I wanted to talk a little bit about accessibility interpretation problem.

including the white paper and then show the website. So one of the things is because the

WCAG success criteria are so complicated, there's a lot of like, you know, details and like,

you really have to find where the edges between like, oh, this is good enough to meet WCAG. And

this is like, just bad enough to not meet WCAG. Sometimes you have those discussions.

and so there is like this interpretation problem.

So I'm usually relatively nice to our clients and to the websites

because I know for two reasons.

So the first one is I don't know what like went into this,

like what discussions are there, is this intentional, is this not.

So whenever I have like a benefit of the doubt, then I will usually use that and not like hard fail them on these individual success criteria.

Because I think that's unfair if you make an effort and you make a decision and then it's like a little bit suboptimal.

And, you know, and then I come and I'm a bad person about that.

I don't want to do that.

But, you know, there's always, like, things where it's clear that it's a fail and then you have to fix it.

And so this is a relatively old article now, six years, six and a half years, from Glenda and Wilco.

And they talked about, like, they called it Accessibility Wars, which I'm not a big fan of, like, naming it like that.

and it's basically about like where do you draw the line of what is valid and what isn't and

they have figured out like three categories of interpretations excuse me second

oh cliffhanger

and i'm back okay uh so they basically have like recognized three uh ways of like how

people interpret it so some are minimum some are like optimized some are idealized i see a lot of

people falling into the last criteria where they basically go like yeah this meets technically

wickhead but i personally think this should be better so i fail wickhead that happens a lot

and i think this is like the worst thing you can do because then it's just at your personal

interpretation at your personal whim if something meets WCAG or not and that's not not a good

situation to be in like you don't want like even as a tester you don't want to be the person making

the decision you want to look at the rules and you want to say like yeah you meet the rules or you do

not meet the rules that's what you want to do you never want to be the party who makes the decision

on this um and so uh and so you know if you have good arguments for like interpreting rule one way

or the other then that's great but otherwise i try to be like very like direct to the code and

usually benefit of the doubt um if there's something that is uh uh probably meeting it

then I will not fail it.

That's where I fall.

And usually it works pretty nice.

So yeah, that's a bit of a thing.

So yeah, that's a problem.

So if you are planning on doing a lot of remediation and accessibility testing

and all of that fun stuff that needs to be done to validate accessibility,

then you should read this and the white paper that comes with it because i think it's good

like inside of what other accessibility people have been doing regarding these problems

and just like be aware of like oh this is something that happens to all of us

and how do I make my decisions the way that they make sense for me

and they are consistent with me, right?

You don't want to fall into that trap,

which is very easy to say like,

oh, this is a website I like, I'm lenient.

And then you have like, oh, this is a website I don't like

for whatever reason and I don't like it.

And so I will like be harsher or like more hard to it.

You try to be objective as much as that's possible, which it's not.

It's not very possible.

And then as the last point, I want to show the WAI website.

Just getting a brief five-minute or so overview of why you should go there and why it's really good.

And I don't say that because I worked on this.

And if something breaks in the CSS, it's totally my fault.

I wrote most of the stuff

but because it's

really like the people who are doing this

content really talented

people they try to

like

guide you through accessibility

and WCAG and all of that stuff

very

well and so

yeah I really recommend that

and

so

I think the best place to start is the homepage

This should not be a surprise, but for a long time it wasn't.

So you have the main navigation with the six big places where you can go.

But on the homepage, you have on the top right, resources for getting started, trainers, educators, content writers, web users, people with disabilities, advocates, developers, evaluators, managers.

everyone and other languages.

I don't know how that's a first group.

Yeah, it's a little bit weird.

This used to be different when I left.

But it's a good introduction.

So if you want to have design stuff, you see a list of all the resources

that apply to you as a designer.

And that can be a good introduction to it.

And then you have the news on the left, which is like mostly boring, like announcements for like, oh, you can now review this standard.

And then you go like, I don't want to review any standards.

So that's basically what's going on.

And then there are featured stuff in here, like the training course, which is in the grand scheme of things, a MOOC that does similar things that we are doing here.

and your accessibility perspectives. Soma? Yeah, about the news part, because I was wondering if I want to be able to have the latest news about accessibility. Is this a good page to go to? Or how do you keep every, what is it called? Keep on top of what's happening in the accessibility world?

That's a good question. I don't know how I'm doing it. So I think there are a couple of things that you can do. So there's the Accessibility Weekly newsletter. That is actually not bad.

leweekly.com. So I should pin that as well. So I recommend that. So that gives you a weekly

newsletter. Well, you know how weekly newsletters work. I don't have to explain that.

But that's a good way to like get what's going on. There is not a lot in terms of like,

oh, this is like, you know, like you have trade publications and other things like what you would

hope to have in something like this, but that's not a thing.

There are a lot of people you can follow on social media that know

what's going on, but I can't really do

good recommendations there on my blog.

I do have a list that is probably

outdated. When was that?

When did that happen? Did I scroll over it? Probably. No, that was much later. It did have a

a fading reverse like where to find people online. Oh, and there's a TPGI thing that I can link to.

I will find that after the meeting and put that into the links. I think that's better use of our

time. Let me write up a little note for myself. That was what was missing. Note to myself. TPGI.

I will put that into Slack.

But yeah, that's basically the thing to do.

If you're really interested in the WAI stuff, what's going on,

then you can look at the news here.

They also have this current work page, what we're working on,

where they list all of the things that are currently going on,

which I think there's way too much stuff and it's very like standards focused.

So I don't recommend like looking at that.

But yeah, they also have like a mailing list and stuff like that.

But I think as someone who is interested in like the bigger picture,

I think the LA Weekly is the better place to like get like a good overview on what's going on currently.

The other place is Accessibility Fundamentals here at the top, the first link. And that has like

introduction to web accessibility, including a video, it has accessibility, it's about people,

which has the incredibly good, great, how people with disabilities use the web resource edit. This

This is my favorite thing Wei ever did and I have not been involved.

This is amazing.

So how people with disabilities use the web, you have the list of personas effectively.

You get these little videos.

These are new.

I haven't even seen all of them because I've been so busy over the last couple of weeks.

So you get these little dice videos.

And they're very short, I think this is like a minute or so.

Yeah, two minutes.

And basically they are explaining what their barriers are and what the issues are.

And then you can also read about all of that because, as I said, having it in multiple deliveries is always super, super important.

So here's Lexi. Who is Lexi? What are the barriers that they face?

Then what technologies and adaptive strategies are there that they can use?

And then there are other way resources to it.

So you get this like really in-depth view on how people with disabilities use the web.

And I love this.

Yes.

And I put it in here.

And yeah, depending on who you are, let's go to Druff.

Druff.

And you can see that like their strategies is transcripts.

So I click on that.

And then you can read what transcripts are.

This is important.

But you also see where they fall into the features here.

So those are features for people who have perception disabilities.

Yeah.

And they broke this up into different pages as well.

That's why I was like a little bit surprised how this works.

And it's like a really in-depth thing to look at.

And then you have to diverse abilities and barriers that basically gives you like an overview on like, okay, physical disabilities.

And you can read up on how they work and what examples of those and stuff like that.

And really, if you have been focused on WCAG for your work, for example, this gives you the real big picture on the spectrum of disabilities.

And I think it's important to learn about that.

Also has the components of web accessibility, which have these little fun graphics as well, and how browsers and authoring tools and everything works together.

So this is like the fundamentals, I think, is a really great place to go through and get a really strong foundation for accessibility.

Then we have planning and policies. That's anything for like how to make sure that in my organization accessibility works, what should policies be, how to involve users for better accessibility, and then also international laws and policies.

International laws and policies, you don't even need to read that. It's all WCAG 2.2 AA. Just do that and you're good. You don't even need to think about that too much.

Then we have design and develop. Those are like practical things, what you can do. Tips for writing, designing, developing. Those are like super short things. Like don't use color alone to convey information. Bad and good examples are really nice to get an overview as well.

and then you have audio and video media which is like an in-depth tutorial on that and then there

are the tutorials which I've been involved in those are one of the main things I did

when I when I worked at W3C and there you have like oh how do I make menus how do I structure

my page this will be what we're talking about next week so don't read this right now because

otherwise you get spoiled. How do I do tables correctly? Stuff like that. That's all under

design and develop. And then test and evaluate. You want to become an evaluator. You have the

easy checks as your first review. They also have the draft updates, which means you have two easy

checks things here on the left, which is really bad. I don't know why they're doing this.

Then you have a list of evaluation tools and what evaluation tools are.

So these are things that help you to determine if something is accessible or not.

And then you get, like, information on reports.

There's a whole WCAG EM methodology that you can follow to make your accessibility tests.

I've never used this, but I heard it had, like, good reproducible results, so that's good.

Then also involving users for those tests as well. And then teach an advocate. This is more like, oh, I have to convince my boss about accessibility or I need to create a course like this one about accessibility.

and there's a lot of information in there,

including the before and after demo.

We already saw that.

But also the business case, which I also can recommend,

because it's not just a financial business case like,

oh, you save X amount of money by doing accessibility,

because that's not how accessibility works at all in practice.

Because first, nobody is doing accessibility, like just accessibility and doesn't change anything else on the page.

So making any, like saying it's only accessibility, that would be disingenuous.

And so the idea is to say like, oh, this drives innovation, enhances your brand, extends your market reach,

because there are a lot of disabled people and it also helps with legal risk.

I think that's a good way to organize that.

So I can recommend this business case as a jumping on point

if you need to do internal conversation with stakeholders and stuff.

Yeah, and then you have standards and guidelines,

which is like WCAG 2, WCAG 3, and all the other standards

that you might or might not need to know about.

Tobias.

Yeah, I have a question about that political stuff. One session is one week is all about that, right? If I read it. Yeah, that's so that's great. That's, that's important to learn as well.

Yeah, it is. I mean, the policies stuff, I think with WCAG or with the European Accessibility Act, it all got like, we now know what's going on. Like before it was always like, oh, we don't know what, like, you know, every country is different. Now we know.

And the requirements from the law is RECAC 2.1 AA, but they can basically make the switch to RECAC 2.2 at any time.

And they will give you, I don't know, six months in advance to make the fixes.

So it's not like they're just changing it and then they just go like, oh, and now you're in violation.

That won't happen.

but it's really good to like you know I would just say like do WCAG 2.2 now it's not that

involved it's actually not a lot of new success criteria that went into it so

if you're in the process of making something accessible

doing WCAG 2.1 AA is like it's a waste of time to not also do WCAG 2.2 because it's just like

just a tiny sliver on top of it for most websites you know so that's my recommendation because

otherwise you know in a year or so you have to touch it again and that's that's annoying

yeah and maybe one other thing that that is interesting is that there are a lot of translations

of these pages so if you go here and you say like i don't know you have colleagues that speak a

different language you can go and say give me the spanish version and if there have been like

changes in between the translation and the current version like here you know it shows the dates and

shows that there is a new version in English. So that might be a good thing to know what's going

on. But yeah, there's a lot of brain power went into making those translations work as they do.

All right, that would be everything I have prepared, one would say. Any questions?

Soma? Yeah, hi. This is a very like in detail question about the thing that you talked about in the video for preparation for today. And it's about the touch target size. And I just feel that I've misunderstood it a bit, maybe because what I heard was that you said that

as long as you have enough padding and the padding plus the touch target equals 24 pixels,

it's okay. But it sounds, I must have misunderstood it because for me, it sounds really weird that

that might mean that you can have a button that has one pixel touch target and 23 pixels around,

and that should be okay. Yeah. No, you understood this completely correctly,

because that's how it is.

So what WCAG does is it gives you a minimum of conformance

for these types of things.

So if we go to...

Too far, right?

Oh, I'm bad with those new things.

Target size minimum. There we go. I knew I would find it eventually. So WCAG tries to give you like

the absolute minimum of what you need to do. And that sometimes means that that minimum is very,

very minimalistic. And this is one of these things because WCAG is also not super interested in

making design decision for yourself um they just want to make like the

the level playing field between disabled users and non-disabled users if your touch target is like

one pixel by one pixel it's probably nonsensical because because it's not usable right people

wouldn't discover it they wouldn't click it so this makes it at least that you can like find it

and click on it if you have a disability and you're getting aware of it.

For sure, it's not the – and that's the other thing.

Like, WCAG doesn't make things accessible.

It just gives you, like, the bottom floor of accessibility.

You can always make things more accessible in this case.

And like this one by one pixels with space around it, that's one of the things where like it's also compromised between like how do we make a success criterion that is understandable and doesn't have like 17 different like exceptions.

Because, yeah, you could say like, oh, if your target is undersized, it needs to have at least 10 by 10 pixels with like 14 pixels around it and stuff like that.

But then you get into like a lot of like different things and they don't want to do that in general.

So that's why, yeah, this is a loophole or whatever you want to call it.

But in practice, like once you get into like, you know, small targets that are so small, they are bad for everyone.

And then it's like, well, that's not our problem anymore.

I hope that helped a little.

Yeah, I just get a bit sad because it's, I'm still thinking about like, it should, yeah, as you said, BK doesn't take the responsibility.

but still like if the the smaller the target is it will be more difficult especially for people

who has dexterity problems as well so yeah that that's true but this at least makes sure that

it's always 24 by 24 pixels to hit something and the reason is because especially on mobile

because this is like this now also applies to like desktop browsers and stuff like that but it comes

initially from mobile and on mobile actually what the browser does is that they just make

assumptions because your finger is not very like precise right so you have like a relative large

area that you're touching and then it basically calculates like where about you touched like what

and then it makes decisions based on where that is

to find the nearest element and then click that.

So if you have a 24 by 24 space around it

and you press in that direction,

you don't have to actually press that exact pixel

and it will activate it

because you can't know where that is.

On desktop, that doesn't work,

but still they put it in like it should.

Maybe actually desktop browsers should do something like that.

I would totally be in favor for that.

But that's the idea that the minimum space that you have is 24 by 24 pixels.

So it makes it easier.

But it's still not great.

I think we can all agree on that.

Thank you.

Awesome.

Misael, is that how you pronounce it?

Yeah.

Good.

I just want to ask, you mentioned briefly about texts in the video. And I was just thinking, like, should you think about, like, having the text easy to read? Like, should you offer easier versions of a page? Or should you always have an easy language? And how do you do, for example, if it's a difficult topic?

That's a great question. That's a great question. So you might have seen in WCAG has a couple of things about readability. I am not at WCAG 2.2. Go there really quickly. There we go.

So WCAG has a couple of things on readability, but they're all not like very good, unfortunately.

So they're all in three, understandable and that there is readable.

And it talks a lot about like making sure that the language is clear and parts are clear.

And then it goes immediately into like, oh, and this is all AAA stuff because we can't ask anyone to do this all the time, which is true.

Like if you talk about unusual words here, if you write like a specific thing like for, let's say, you know, a trade publication, like you write about photographs and color spaces and you have like very specific language to do that.

it's unreasonable to say oh avoid these unusual words like that are unusual for 99 of all the

people uh because yeah sometimes you have to speak in your jargon to be effective in speaking

right um and the same goes for abbreviation and reading level um and here the other problem that

we have identified is different like languages do it differently so it's like it's it's it's a

complicated topic. That's all I want to say. The idea usually is that you try to be as simple and

understandable as possible for what you do. And then in some areas, it makes sense to have easy

to read language as well. So the German public policy, for example, says your main page needs

to have an easy to read language link that explains what the website is,

what it does and what the important like things are that you can do here.

But that's Germany specific policy.

And I think it makes a lot of sense.

If you go to Lainey Feingold's.

probably mistyped her name uh lf legal laney feingold's uh website she has a great website

about like laws and stuff like that and uh and mostly in america uh uh like when someone gets

sued and stuff like that uh and she also has um her legal updates that were her bloggers

yes this is where her blog is and if you um go through and you go into like the individual pages

at the top she has an on this page like basically easy to read summary of the page because she knows

like this is lawyer speak can't reach everyone but like this is my attempt of like making this

giving like at least an overview and then people can uh read through it um and and i like this

approach very much i'm not doing it myself because i'm lazy like that but uh but in general i think

this is a good idea i tried i just try to be like very simple in my communication if i can um

in my case working at a bank for example there's no requirements that for example a person that

doesn't know Swedish that much should be able to read it or? No, I don't think any requirements

like that are there. But you know, it might, but this might be like very specific, like local

policy, law issues. So I'm not, I'm not super versed in that. But I'm not aware of any like,

requirements. We always recommend it, especially this approach, like, you know, if someone wants

to open a bank account, you know, explaining like in really easy ways, because you also have,

you don't only have like disabled people that can use this information, but also people who like,

do not know the language, as you said, or who are like, you know, refugees or people who, you know,

who are new to the country and maybe not have heard about this specific like language. So

it makes a lot of sense. I've also seen a lot of, I've seen a few examples of people using for terms

and conditions, having basically for each paragraph, the like hard to read version,

and then a summary on the right. So you can go through the summary and then say like,

oh, I want to learn this like in detail, I want to spend the time, and then you read the more

like in in-depth version of it uh you know so yeah but there's nothing like fixed because this

is so individual to all of those pages okay oh thank you awesome that was a good question

not that the other questions weren't good all your questions were great

i don't i don't pick favorites here all right uh

yeah and i think we have a content um uh week as well i think in like 10 weeks or something like

that um and i do have uh i have a couple of links in there as well for you to like read up on like

the easy to read language and stuff like that including swedish stuff that people sent me and

said this is great and I'm like must be great otherwise he would not send it to me yeah

any other questions

going going gone okay thank you very much for attending I will update the stuff and I will also

put this video and a transcript and captions and all of the things online as soon as I can

probably today, maybe tomorrow morning, and I will ping and slack

once that's done. And then we see each other next week, because

I do two weeks, one after the other,

this time. And then you get Hampus back,

luckily. Alright,

thank you very much, take care, have a good rest of your day.

Thank you. Bye. Bye.

Bye.