All above combined

Welcome to audio and video. This is an important topic because a lot of audio and video content is just happening on the web and you need to make sure that it's accessible to everyone.

Just as a heads up, audio and video content, there's not a lot you can actually do to explore it or to test it.

It's basically looking at it and saying, yeah, the features are there or they're not there.

So there's not I don't think this is like the very hands on topic, but we'll give you a lot of like insight on how you can look at this and make sure that you have the experience to see if the features are there and which features are needed for which type of video.

and audio. Speaking of audio, let's start with audio. Audio is available in a lot of places.

You know, there are podcasts, there are audiobooks, stuff like that. And

it's important that that medium is accessible for people who can't hear the audio.

Let's take a quick look at an audio player example. I have prepared this. So if I go to the front and then press play, this plays. And these players look different on different websites, so don't get too hung up on how this looks.

There are no requirements for the look apart from the normal design and interaction requirements.

You want to have it keyboard accessible.

You want to have enough contrast, stuff like that.

But there's nothing really that is specific to these kinds of players.

And let's hear a little bit on what's going on there.

It's really not that much things happening there. It's just the intro to this podcast, in this case.

And this player has a couple of comfort functionality like the go to the start and you can skip through it and then you have speed to listen and sound, mute sound and play sound doesn't even have like sound adjustment, which is totally fine. There is no requirement for accessibility for that.

Some principles, general principles, the user needs to be in control of the audio.

So never auto start the audio, never like spring audio on someone.

There are some interactions where you can use audio.

For example, if someone clicks a button and you have like little feedback sound, that would be okay.

But everything that distracts from the content can be a problem.

So you should never auto start audio and you should make sure that the user is in control and always say like, oh, I don't want this audio to happen right now.

And on websites, you should use the audio element.

And I get to it why this is so important to use these standard things all the time in a bit.

Because the same goes for video as well.

So let's talk about video.

Video is also super important. I mean, there are a lot of videos out there. Here's an example that I like to show. This is Bill Potts, the 10th, no, not the 10th, the 12th Doctor's companion entering the TARDIS. And it's a little video player, press play.

Thank you.

What a great scene. Yeah, so you have this reveal and you can see that for videos, of

Of course you have more options. You have the skipping around part, but you also have a couple of other things in here.

This is new. Get embed code. So if you want to embed it on an external page, you can open it in picture-in-picture mode.

Again, playback speeds. And you have subtitles in this case, so I can switch those on.

Now I have. And then if I go back.

and you know and full screen so you have all these different options as well and this is standard

video player like you know it from YouTube, but it's always good to have that mode of reference.

And so there's a lot of technical accessibility in here that you need to look at, like the keyboard

navigation stuff, but there's also something that I think is important, and that is going beyond

the technicalities and looking at how the interaction should be in the grand scheme of

things. And there is this really nice use case of the BBC iPlayer that is relatively old. It's now

from 2015, so it's seven years old, but it has a lot of good information on how to design

a video experience. So for example, they operated under those four UX principles

to give users choice, put them in control, design with familiarity in mind, and prioritize features

that add value. Now, the previous screen was the old interface, and what you had was TV and radio

here at the top. And then you had featured content, most popular, and an A to Z of the

program and then categories and the channels were on the bottom left here. And the interesting thing

was that they didn't really look at this when they started from a user perspective. They just put

online, how it came. And now they redeveloped this according to these principles. And some

features that added values are things like giving users on the top, like direct access to their

program to BBC One or BBC Two, because people like that. Also categories here,

and including in those categories, putting audio described and signed sign language as categories.

So this is super useful for people who need that kind of content.

Here in the teaser, same thing, looking at like what is really important for people,

and there are audio descriptions and sign language icons in there as well. Just making

sure that it's easy to find, easy to know what's going on here also to turn on and off sign language

and audio description. So you get these accessibility features as part of the redesign as like a cohesive

information here. Yeah, and that meant like putting primary information at the top,

adding better search, which is also an accessibility feature. We don't talk about that too often.

And then also managing keyboard access.

There is this article, "Accessibility originates with UX" from Henny Sworn, which is excellent.

I really, really recommend reading that.

It's a good case study on how to bring video content, make it so that if you're, especially

if you're a video first company like the BBC is, that you can bring that type of content

into the web and make sure that your users needs are really prioritized.

And of course, for we had the audio element for audio stuff, the video element, you want to use

that for videos, because that's really straightforward. And of course, you have

ways to embed stuff from let's say YouTube or other hosting platforms. But they use the video

element and it has a lot of advantages. So first, it has a

lot of these like very simple to use functionality, like auto

play, controls, loop, muted and poster. So if you need to show

an image while the file is downloading or before play is

pressed, you can just specify the image inside of the poster.

If something needs to loop, like in an animated GIF, you can specify the loop attribute.

If something, if you want to display the controls, you just add the controls attribute and you're set.

You don't need to do that yourself. And in most browsers, these are actually accessible. So

you can make sure that you don't need to do anything. So, you know, just specify controls,

and you're good to go. Talking about autoplay, this is a functionality that you should generally

avoid. I have never come across a website that I deemed accessible that autoplayed video. So,

just don't use it. Especially like these big background videos, they can be very hard for

people with certain cognitive disabilities to ignore and they distract from the content.

It's just not a good way to do it. The nice thing about HTML video elements is that

most browsers now give you the option to completely disable auto playing videos.

So this is a screenshot of a very old version of Safari. And basically you can say "AutoPlay,

stop all, never auto play". Or you can say "I only want silent videos to auto play".

So you can make that decision on a general global basis and on a website by website basis.

Both elements, audio and video, are completely scripted.

That means if you want to use your own UI, you can actually do that.

And you can use normal HTML buttons and UI elements and users can click on that.

And this is the preferred way to do this.

And so if you're testing stuff for audio and video and audio or video element is used,

which should be like 99% of all cases these days, then, you know, you just need to look at like,

oh, does this pause button, is that available using the tab key? Is that reacting to keyboard

access and stuff like that? So you don't need to do anything extra because these elements have that

capability, which is super nice. How to make audio and video content accessible? Now, this is the big

question, right? And I post it like this because this is much easier to understand than the opposite

question, how to test for accessible audio and video content. Basically, you look for available

features and if those features are not available, then you can say it's inaccessible or if all of

those features are available, then it's accessible. Let's look at user needs. There are basically

three user needs for audio and video and they have overlapping needs as well. So the first one is

hearing. Hearing means that deaf and hard of hearing individuals have a way to consume the

audio content that is in the video or in the audio. So, you know, if you can't properly hear

what's going on, then you need an alternative for that. Then you have vision. So blind and

low vision individuals, they need alternatives for the visual content. So that's everything that is

displayed on the screen. And yeah, this is pretty obvious. Basically, you do the same thing that you

would do for images, but for video. And we see how we do that in a minute. And then there's cognitive,

which is basically mostly people who have issues processing information.

So for some people with cognitive disabilities, it's super hard to process visual and auditory information at the same time.

So for those, it's nice that if you have things like pressing pause,

If you give them a way to slow down the video, that can help.

And sometimes it's just that they prefer written information much more than the video.

So having an alternative in written form is a good accessibility requirement there as well.

Now, short tangent on the WCAG requirements.

So everything about media is basically covered by 1.2 time-based media, 1.4 distinguishable, and 2.2 enough time.

So these are the WCAG guidelines that mostly apply to video and audio content.

And to make this harder to understand, there is a little bit of recap lingo that we need to talk about, because otherwise it's just too hard to follow.

And there are basically five terms that we need to talk about.

The first one is pre-recorded.

Anything that is pre-recorded is anything that is not live or what we would call recorded.

So if you publish a video on YouTube, if you, you know, this is a pre-recorded video and it's not live.

Then there's live, which basically means what it says.

That's why I put the live there as the definition, basically.

But it's happening at the same time as the broadcast.

So if I was live streaming this to the internet, then this would be a live audio.

But I'm not, so this doesn't apply.

Then there is audio only, and that's media that only includes audio.

So that is all media that has no visuals or no visuals that matter.

So what I mean by that is if you have an audio that is a podcast or an audio book, you don't have visuals with it that happen at the same time.

So they are not connected.

The same if you have like a voiceover and there is like, I don't know, there's a visualization in the background.

like you often have that when you share stuff from your podcast app.

You can create little visualizations.

They have nothing to do really with the content.

So that's all considered audio only.

And then you have video only, which is the same thing, only the opposite.

So this is content that only includes video.

So no audio, no spoken text, no music, nothing like that.

There is probably could use music, but you want to say like, oh, this includes music.

And then there's synchronized media.

This is WCAG language for media that includes audio and video.

Basically, when two sets of media are happening at the same time and they depend on each other,

you have dialogue and you want to see the person speaking move their mouth, then that is synchronized

media. A certain part of the audio needs to happen at the certain time that some video happens,

and that's synchronized. For the requirements, I just skip really quickly over these tables,

because I think they're more distracting than useful.

So these are the requirements for pre-recorded media,

and these are the requirements for live media.

You see that for live, there's a lot less to do.

And for pre-recorded media, there are more things you should do,

including some WCAG AAA success criteria.

But we will talk about those at the end of the video. I don't want to distract from this, but

you will see these tables in your reading and you will say, well, what's going on here? So,

yeah, these are the requirements. It's not super clear and it can be a little bit distracting.

Requirements for live media. I already talked about that. And this is where WCAG's focus on testing is not super useful. Because yeah, you have to test all these success criteria. But in reality, understanding what the needs are, we have already talked about that.

and then seeing which features do apply to those needs is much more important.

And there are basically four ways to address the needs of users in regards to media.

Now, we will mostly talk about the first three, which is scripts and transcripts, captions and audio descriptions.

And the reason is, if we go back to WCAG, sign language is only a AAA criteria for synchronized audio and video.

And it's not even needed for live media at all.

So sign language basically does not play a role when testing for WCAG.

Still super important.

I wish we had more regulation that says, hey, use.

And that brings us to the four ways to address the needs of users in regards to media.

Scripts and descriptive transcripts, captions, audio descriptions, and then sign language as basically like the cherry on top.

Talking about scripts and transcripts, scripts are basically the text that speakers say.

For example, the voiceover is part of their role in the movie.

Transcripts is when speakers say something like I'm doing right now, I'm mostly improvising.

And then you write down what the speaker said.

So that's transcript.

And scripts and transcripts publishing those addresses the needs of low vision folk, hard of hearing people, deaf people, and a lot of cognitive people as well.

So it makes sense if you have those scripts or if you create transcripts to publish those for real.

So, for example, if I go to my website, yeah, till.net/videos, I did some YouTube videos a

a while ago. And if we look at, for example, over cake overview,

there is this transcript, but in reality, this was the script

that I was reading to the screen to the camera. And the nice

thing is that you can line that up with your with your video and

create captions, which is the next thing that we're doing. So

that was quite nice. It was very simple. And I could just

published that on my page and it was useful for a lot of people. Speaking of examples, so here's

the transcript of the web ahead. This is also a podcast and was a podcast and if you show the full

transcript basically it's always showing who said what and then the text that was said. And there

are even timestamps in there, which you don't always need. Yeah, but that's, that's a very

simple transcript, someone sat down, and there are professional people doing that. And just

writing up all these different things. But what was that? So that's useful. And, and this is

the general way how you can provide a transcript. Now, there are ways to have interactive transcripts

there and if we look at the TED talk then we can see how that would look. So basically

click "retranscript". Oh, I already had that in here and you see that there is a transcript

on the right and then you can play from minute 114.

Yeah, and so you have this kind of interactive transcript where you can click on things.

And you jump there immediately. That can be a really nice experience, especially for research

applications and stuff like that. This is not needed strictly. Just having the text as a text

file, as an HTML file, is totally sufficient. But if you want to do more, you can basically go from

this simple way of presenting the information over like my little bit more structured way with

headings and stuff to like this interactive thing. There are no rules about this. The most important

part is that everything that is said and all significant sounds are inside of that transcript.

If you want to make the transcript also useful for people who cannot see a video, for example, you also want to have descriptions in there that describe the visuals.

Basically as an alternative to the visible image, like an alternative text.

I have not seen that done really awesomely well.

But it is an option and there are some niche places where this is done, but I don't have them, unfortunately, at hand.

And that brings us to captions.

Captions, you probably use them, are visual textual information that reflect auditory information in the video.

So this is again pretty similar to what we just did with our transcripts.

This is all sounds that are in the video are reflected as captions on the screen.

And generally those captions are on screen at the bottom and you can read them there.

A lot of people are using this for foreign language movies.

But it's obviously an important part if you can't hear what's going on in the video.

Just a quick note on captions versus subtitles.

In Europe, you can just use subtitles as the word in English and that means in US English.

And that means also in WCAG, captions are subtitles with the same language as the source audio.

So if you have an English product, then the captions are also English and subtitles are foreign language subtitles.

So if you have, I don't know, a Japanese anime and you watch it with English subtitles, then they are subtitles and not captions because the language is different.

It's like a minor difference.

But, you know, some people are pedantic about that.

So just I always say captions usually for accessibility.

I usually say captions.

That clears up most of the things.

Example is again the TED talk from Tim Berners-Lee. So I can switch on what they call subtitles. That's why I put that slide in here. And I can just say I want English subtitles.

It's not super easy to switch on, but when I do that, basically what is here in the transcript

then becomes visible on the screen.

For someone who talks and thinks as fast as Tim Berners-Lee, super useful to have a transcript,

I tell you. So yeah, that's, that's how captions look. And the nice thing about captions is that they are that they are super useful to have them especially for, like, as I said, people who don't understand the language very well, but also for people who can't hear what is said.

There are a couple of best practices here in this Smashing Magazine article, which is super new.

It's from January 11th.

And basically, hey, they have the same example that I had.

And they go into detail what you can do when you're actively producing subtitles.

This is usually not what we do when we do testing.

We just say like there are no subtitles or the subtitles are, you know, don't match up what is said in the video or other things like that.

So that would be classical fails for WCAG success criteria.

And there are subtitles formatting conventions and stuff like that.

It's really, really good.

It's a nice little article on what's going on.

And I really like that.

So next time when you are watching something on a streaming service like Disney Plus or Apple TV Plus, they have exceptionally good captions, but also audio descriptions.

So if you are looking into that, that is, you know, a homework I can do.

Watch your favorite TV show with subtitles and audio descriptions.

captions.

And for captions, you can just use the track element in HTML.

So using in this case, web VTT formatted file, putting that in again, usually you don't test

for that.

look for a closed caption button, you click on it, and you can then see if you have it.

And then the VTT file in this case looks like this. There are a couple of different formats

out there. There's WebVTT, then there's SRT. Doesn't really matter in practice for testing.

Basically, what falls out of your process, you can use that.

Usually just upload it and refer it from the track element.

One thing that I don't have a slide about, but that is important, is open captions versus closed captions, because this is a little bit confusing.

What we have here that the captions are there and you can open and close them or switch them on and off, which is not the easiest thing to do.

That is called closed captioning.

If the subtitles were built into the video and you could not switch them on and off, then those would be open captions.

It's very confusing.

I don't like that it is this way.

but it is. So closed captioning is usually what you want. According to WCAG, having open captions

is not a failure. So you can do that. But if you have the option to have open captions, no,

closed captions, see, it's hard. If you have the option to have closed captions, then use closed

captions that you can switch on and off. And that brings us to audio descriptions. Now, audio

descriptions are interesting because this is basically an audio track that narrates

visual information.

That addresses the need of blind and low vision folks to know what's going on on the screen.

I have an example here.

And basically what this does is that it uses natural pauses in the video to add narration

the video. And that is super clever. And it takes a lot of skills to do that. Much easier is it if

you just leave enough space for the audio description. So if you put your storyboard

together, you plan for the audio description, and then you can have an audio described version and

non audio described version. And but but you have to plan for it. There's no no way around that.

Web Accessibility Perspectives

Colours with good contrast

Signs with directions are shown.

A woman is walking happily down the street.

There's something about great design that allows it to go practically unnoticed.

But it doesn't take much to make things confusing and frustrating.

Choosing colours with poor contrast makes navigating, reading and interacting a real pain.

The signs change to have poor contrast.

The woman now looks confused. She looks at a navigation app on her phone.

Good design means sufficient contrast between foreground and background colours.

That's not just text and images, but links, icons and buttons.

The app has a button with low contrast that changes to become clear.

If it's important enough to be seen, then it needs to be clear.

And this is essential for people with low contrast sensitivity, which becomes more common as we age.

An older man on a sofa is looking at a tablet. He goes to read a message on his mobile phone.

With good colours, websites and applications can be easier to use in more situations, like in different lighting conditions.

Sun glares on the phone, but the text is still readable.

Web accessibility. Essential for some, useful for all.

The woman from earlier arrives at her destination using the mobile app.

Visit w3.org slash WAI slash perspectives for more information on colors with good contrast.

W3C Web Accessibility Initiative Copyright 2016

So this is a typical example.

Like whenever there's like a narration pause, so the male sounding voice in this example did like the normal narration that you have in any video.

And then the female sounding voice did the audio description and described what's going on on the screen.

So this typical audio description way.

If you want to see this also in practice, as I said, streaming services are extremely good with accessibility.

If you have Disney+, look at things like Daredevil.

If you have Apple TV+, See is a good example where it's about a society of blind people, which is interesting.

I've only seen the first series, so I can't comment on how good it is.

But yeah, there are a lot of good examples where you can switch on captions, closed captions.

No, yeah, duh.

Closed captions or audio descriptions and get that information.

Let's talk about additional features in MediaPlayers.

I take the W3C Way Perspective videos here as an example.

because they have like a very complicated media player that has a lot of features.

So if we play just a short second.

So we have this player and if we use the keyboard, we can go there using the tab key.

There we are.

And then we can restart the video.

we can rewind, we can forward, we can skip through it using the keyboard, I use the arrow keys here.

Then we can move to the volume, which you can also set using the arrow keys. Then we can make

it slower and quicker, which can be useful for people with cognitive disabilities, that you can

like basically make sure that the speed works with the speed of your brain, which sometimes can be

useful. Then you can hide the captions, show the captions. And one thing that they did here is to

have the captions underneath the video so they don't obscure the video source, which can be useful

in some circumstances. And they did that here. You can show the transcript,

which does open at the bottom. And this is actually a movable set. So you can just go and drag this up. And there you go. And then it scrolls with the content. And that is also useful. It's a little bit like the TED example, you can also hover it and jump where you want to jump. There are a lot of more preferences. Like for example, you can

set the captions how you want them. And the nice thing is if you're using the standard HTML video

player with the standard captions, it will actually reflect the settings that you have

on your device. So if you're on iOS or macOS on Windows and you set your captions and your

colors, your preferred colors and your size, then that should be reflected through every video that

uses the standard method. Yeah, and then you can have descriptions, you can audio description, I

have that automatically through a screen reader if you want that. You can have a lot of keyboard

commands here, keyboard preferences. So this is, I think this is very in detail. And you can also

say I want my transcript keyboard enabled or I want to not highlight it because that's distracting to

me, then you can save that as well. So you have a lot of settings here. You can also close this

window again. And this is really nice. And because this is not an audio described video, it doesn't

have like an audio described transcript. But if you enable audio descriptions, and then go into the

transcript, you see that the audio description is in there basically as a separate fields basically.

So we have the normal narration and then where it changes into audio description, it changes how it

looks.

So, you know, so that doesn't work 100%.

That's probably like a bug.

But yeah, it's pretty neat to have like all of that content in one view.

But that's all additional stuff.

When you look for WCAG issues, you don't need to look that deep, unfortunately.

So back to WCAG requirements.

I want to quickly skip through the WCAG success criteria that are important for time-based media, for synchronized media, and give you an overview on those.

So let's start with audio and video only.

audio only and video only so this should actually be two success criteria and of course it is not

basically these are the requirements for audio only and for video only content so if you look at

1.2.1 audio only and video only pre-recorded so this is only for recorded content this is not for

live content. It's level A and it basically says that if you have pre-recorded audio only,

then you have to have an alternative for time-based media that presents equivalent

information for pre-recorded audio only content. And alternative for time-based media is basically

a document including correctly sequenced text descriptions of time-based visual and auditory

information and providing means for achieving the outcomes of any time-based interaction.

So basically, this alternative needs to describe everything that's happening visually and auditory.

And for pre-recorded video, if you have video that is only video, no audio there, then you

want to have a description like above, or you want an audio

track that describes what's happening on the video. So

basically someone narrating what's happening on the screen,

an audio description. That applies to audio only and video

only. Then 1.2.2 is about captions. This is again for pre

recorded videos. And here it is. Captions are provided for pre-recorded audio content in

synchronized media, except where the media alternative for text is available and is

clearly labeled as such. So basically you have, if you have a video with audio,

synchronized media, then you can't have either captions or you can have

the alternative for time-based media. So the transcript.

1.2.3 audio description or media alternative is basically the flip of the coin to captions. So

this is for things that are visual on the screen. You need the audio description,

but there is an exception when the video is basically an alternative for existing text already,

and when it's labeled as such.

So, for example, you have an instruction that is written, and then you have a video that describes the same thing.

Then you don't need to have an audio description for that.

Captions for live video are basically the same thing as captions for recorded media.

You need captions and this is already level AA. So live captions are pretty high priority,

as is audio description for media that is recorded. So now you get into this like,

Oh, now we're level higher, like level AA. Now what are more harder to achieve things?

So in this case, audio description for pre-recorded video is required in 1.2.5.

Now for success criterion 1.2.5 audio description, this requires now an audio description for all

recorded synchronized media. So for all videos that have audio, you need to have an audio

description. And that basically replaces the single A success

criteria 1.2.3, which says you need either a transcript or audio

description. With 1.2.5, you have to have an audio

description. So you will always meet 1.2.3 when you meet 1.2.5.

Now, you should you should best practice is to also provide a

transcript or alternative for time-based media. But you don't need to do that. If you meet 1.2.5

with an audio description, then you don't need to think about 1.2.3 at all.

And then we come to the AAA success criteria. So these are the out there things that you can think

of and that are useful. One of those is sign language. Now, some countries like Germany,

they require sign language on main pages for websites. So sometimes that's needed. And

basically sign language interpretation means that you're using the sign language of the,

audio, the sign language of the territory of the audio basically. So British sign language for

British video, American sign language for American video, or you could also use international sign

language and you have a sign language interpreter on screen. There are no requirements for how that

is done. So you don't need to like, there's no height or width requirements or backgrounds or

anything like that. It should just work in the in the general way these, these things are you used

to having it in your territory. And then the question is also like, just making sure that,

You know, they are always in view and they're not too small.

But as I said, there are no hard rules about that.

Then there is extended audio description for pre-recorded media.

So normal 1.2.5 audio description only means you have to fill gaps in your video.

And that means if you can't describe something because there is not enough time,

then you can just not describe it because there's too much narration.

So there's no pause in between.

But 1.2.7 AAA criteria means basically you have to re-edit the video

and make sure that there is enough space to insert the narration.

And the example we looked at was such an extended audio description, actually.

So they cut the video in a way that the narration for the audio description fit into the gaps,

instead of scrambling everything into audio description there, into the gaps between

narration. And then we come to 1.2.8 media alternative pre-recorded. So this is basically

that you need to have an alternative for time-based media for all pre-recorded synchronized media

and for pre-recorded video only media. So this is having a transcript that has all the information

in it, what is said, what is visible on the screen for all video that exists.

I recommend that.

I think this is a good thing to do.

But for WCAG purposes, it's only in AAA.

That brings us to success criterion 1.2.9, audio only live.

It's also AAA success criterion.

And this is basically about having an alternative for time-based media that has the equivalent information for live audio-only content.

So that basically means having a transcript that gets updated live while the audio is happening.

And, yeah, this could have the form of live captioning, which is, you know, a double A success criteria.

If you have video, it's, you know, it's more often the case that there are live captions.

And so this is basically what they say is like that triple A criteria.

You need to have like caption style transcripts for your audio only content.

So if you have a live radio show, something like that, if you do live streams of audio content like your favorite podcast, this would be covered under the AAA 1.2.9 audio-only live success criterion.

And there are two other guidelines, 1.4 distinguishable and 2.2 enough time that are kind of related to media content.

And the first success criterion here is audio control.

An audio control basically says if there is audio on a website that plays for more than three seconds,

then you need to have a mechanism that pauses or stops that audio.

Or you have a mechanism that is available that allows you to control the audio volume independently from the overall system volume level.

Yeah.

And this is super important.

You don't want to interrupt people for a long time with automatically playing audio.

As I said at the beginning, just never play audio automatically and you never have this problem.

And this is usually also like even if you're inside this three seconds window, the general advice is to just not do it.

And then there's 2.2.2 pause stop hide.

And this is basically the same success criteria and a little bit different for video content.

So this is for moving, blinking, scrolling or auto updating information.

So videos move.

So they are covered by this.

And basically for every moving information that starts automatically and lasts for more than five seconds

and presented in parallel with other content,

there is a mechanism for the user to pause it, to stop it or to hide it.

Unless this movement, blinking or scrolling is part of an activity where it is essential.

So, for example, as part of a test or a game,

there are ways that you get around it.

But on normal websites, this is super important.

The second auto-updating portion is not relevant to this, but that's basically for information that updates like a new sticker or something like that.

And yeah, and the important part of these two success criteria is that these are interfering with the user's computer or using the computer so much that actually you automatically fail all the other success criteria if you fail one of those.

So it's a pretty big deal.

And then we have this link.

It's just a link.

It's the last slide.

This is to making audio and video media accessible on the W3C side.

A lot of more detail.

The tables that I showed that are a little bit too complicated in my view,

they are from this content and they go through the same details.

They include transcripts as well.

They have description of visual information, audio descriptions, and sign language.

they go more into in detail on how to produce them, why they are important, and how, how you can include them or integrate them into your videos. And also there is section on user experience and benefits to organizations, which can be useful if you have to like, you know, tell someone why

Why is it important that we have accessible media and you don't want to have the answer

that is like, oh, we're required by law to do it.