WCAG Fundamentals

Welcome to the WCAG Fundamentals, the first real async video that we're doing.

And yeah, let's dive directly into it.

So we talked already in the intro about WCAG and what it actually does for you.

And now we're going to dive deeper into the actual document and what it actually brings.

And I will also give a little bit more context to how W3C actually works.

Again, the W3C is a standards organization and creates standards like WCAG and CSS. So it has

a lot of different things that it does, a lot of different views and technologies. It also does

internationalization, so making sure that the language, for example, is supported in different

different um circumstances and uh yeah and i talked a little bit about tim berners-lee who is

the inventor of the world wide web and uh basically made sure that we can use the internet as we

use it today right um and uh he started w3c because he realized that you know we need

people work together to make the web work. And not only, you know, that everyone is doing their

own thing, but we have to work together so that it is interoperable and that everyone can use the

same content and display it in the same way. So that's like the incentive. And as part of that,

W3C has released 240+ specifications and those are the specifications that are current today.

There have been specifications that have been removed from use as well and about 13 of those

specifications are related to accessibility.

It doesn't sound like a lot but actually it's quite significant, especially as most of the

accessibility work is going into a relatively small amount of specifications like WCAG and

stuff like that. So there's a lot of like, oh, we're doing all of this in one specification going on.

And it's so important to have WCAG because these standards create shared understanding of

requirements among consumers, authoring tool makers, developers, and makers of browsers and

assistive technologies. And that's what we want, right? We want to have this shared understanding

so that not everyone is doing their own thing. And standards are super important. I mean,

we wouldn't be here without having web standards as we have it. They make sure that you have

flexibility and give users choice how to interact with content. They make sure that you have a

quantitative measurement of conformance, for example, to WCAG, you can say, yeah, this

meets WCAG or it doesn't, super important.

And when you remove user's choice, when you basically say, oh, we're deviating from those

standards, so you're using a technology that is only accessible in one particular browser

or in one particular operating system, you remove the user choice.

And that means users who don't use that particular browser, that particular operating system, they get barriers or they have barriers because they can't use their preferred operating system.

And that's the beauty of the web is that everyone can use their browser on their operating system and just go for it and have their preferred way of using it.

There are a couple of other web standards bodies.

I don't want to go into too much detail, but you can see there is the Web Hypertext Application Technology Working Group, or WOT, W-G, which takes care of things like HTML, DOM, and URL.

Then there is the World Wide Web Consortium, which we already talked about, which has CSS, web fonts, web audio, all those jazz, but also the accessibility stuff, mostly.

And then there's ECMA International, which has JavaScript.

So you have these like, it's almost like a separation of like concerns or like in a political system where you have like, you know, make sure that you have different branches taking care of different things.

And it basically developed over time into this.

And that's really fascinating.

HTML used to be developed by W3C, but is now completely in what WG hands and some people

are contributing from W3C.

It's like a really nice web of little bit checks and balances to make sure that everyone's

needs are covered.

So that's good.

Web accessibility at W3C started with the foundation of the Web Accessibility Initiative.

That is, we call that WAI in the “biz”. You know, great. So, WAI is a web accessibility

initiative. Basically, after a couple of years, Tim Berners-Lee said, "Oh, you know, this

web needs to be universal for everyone. And so he got Judy Brewer in, who was the WAI director until

November and is now still working with W3C, but is going away. And so basically for about 24 and a

and a half years or something like that, really steered the whole web accessibility on the web.

And yeah, there have been positive steps. And one of the things that we got out of this

interaction is the web content accessibility guidelines. And, you know, if you try to find

like a concise definition of what WCAG is on the W3C side, on the wayside, you won't find it.

It's like all super complicated. So this is my summary. Web content accessibility guidelines

to as an international standard that ensures basic access for disabled people. And I think it's

important to say this is basic access. This is not like, oh, we conform to WCAG, this is the

greatest website ever for people with disabilities. That's just not the case.

WCAG just defines like the baseline, these are the needs you need to meet to make sure that you,

that people with disabilities are not excluded completely.

Then, you know, the first thing, of course,

was Web Content Accessibility Guidelines 1.0.

They didn't start with 2.0,

although I would totally give it to them if they had.

And I don't want to go into too much detail

because it's super different to WCAG 2,

which is the current standard.

But it was basically created in May 1999.

And it's an interesting historic artifact.

And if you look at WCAG 2 and look back at WCAG 1, you see that, oh yeah, you pretty clearly see what the decisions were to change to WCAG 2 and what the advantages are there.

And then in 2008, so around 10 years later, nine years later, Web Content Accessibility Guidelines 2.0 were released.

And the new standard was much more technology agnostic, much more making sure that you don't have things in there that is super specific to HTML and CSS.

There was a lot of stuff in WCAG 1 that basically outright prohibited use of things like JavaScript because it was like, oh, this can never be accessible.

And then 2008, we knew better.

And we said like, yeah, you know, JavaScript and interactions like that can be accessible.

And so we have to make sure that the guidelines work for those as well.

And that was probably a fun challenge at that time.

So, yeah, and this is less technology specific.

And you often hear that if you read up on WCAG as technology agnostic.

So it's not like relating to any of those technologies.

WCAG is embedded into a standard suite.

And there's also ETEC and UAC.

and if you look at this nice graphic which if you have ever worked at W3C you are obliged you have

to use this graphic in one of your presentations every year so check that box I guess it's not

true but you know you you often see that and basically these are the three accessibility

guidelines in the standards route for accessibility and there's WCAG which is for the content and then

there's UAC, which is how users interact with the content. And then there's ATAC, which is how

developers and content people basically are interacting with the content. So the developers

and content people are creating the content using ATAC in an optimal case. Then you check for WCAG

to make sure that it actually meets the standard. And then you have UAC, which makes sure that

browsers, media players, and assistive technology works well with it. That was the dream. It didn't

really pan out. Basically, only WCAG really came through as like, oh yeah, this is what we're doing

now. It's just a little bit sad because the other components are super important. And, you know,

they get picked up very piecemeal, but I think there's a little bit of a, like,

trend towards making sure that these other standards are also like at least looked at.

Now, as I said, it was about 10 years from WCAG 1 to WCAG 2. So, you know, you think like, oh,

you know, at least WCAG 2 gives you a good framework to iterate in there. So,

You can expect pretty quick updates.

And yeah, sure.

After 10 years, there was another update in 2018, in June.

And WCAG 2 was a major step up.

I mean, I can't even stress that enough.

And WCAG 2 is a really, really good standard.

It's probably, and you can quote me on that, it's probably the best standard W3C has ever written.

And it also has its flaws because every standard has, because it's a consensus way to create standards.

But it's a great standard.

It has stood the test of time.

I mean, it's now, how old?

Almost 15 years.

That's a long time for a standard.

Yeah, and so WCAG 2.1 came out and basically WCAG 2.1 only added to WCAG 2.

So if you conformed to WCAG 2, your website is accessible to WCAG 2.

There were additional requirements, but it wasn't like you had to rethink everything and this is a new approach.

No, it's just like iteration.

And the same is going to happen with WCAG 2.2, which is supposed to come out in 2023, which would half the time for a new WCAG regulation, which is great.

It was originally announced for 2020 and then we all know what happened there.

And now it's getting like, you know, it's always inched back a little bit, but which is normal for web standards.

This version actually gets to probably gets to significant changes from the approach that I just outlined.

So the first one is that there is, and I get to that, there are different levels in WCAG, and WCAG 2.2 is supposed to change a level of a success criterion. That has never happened before.

And there is one success criterion that is basically just technologically irrelevant right now.

And so the idea is that that success criterion gets removed in 2.2, which also never happened before.

And everyone is like up in arms for it.

So that's going to be fun.

I think that's a really good change because you don't want irrelevant stuff lingering around,

creating, especially in accessibility, a testing burden for testers.

We don't have enough people doing this job.

And so the less work or the more effective and efficient that work can be,

that time can be used, the better.

And that brings us to the WCAG 2 structure. So WCAG 2.1 and later 2.2 are stable referential standards. And that means that they don't change once it's published as like a recommendation as a W3C standard. These are set in stone until a new version comes out. So that's really important.

And it's organized as 13 guidelines under four principles, which I will get to.

And then each guideline has testable success criteria at three levels.

And there's some supporting material as well.

We get to that as well.

So this is like the general structure.

You have these three levels of things, and those are principles.

guidelines and success criteria and the idea is that basically the principles give you like the

north star the thing you're looking at and then you know you get to the the guidelines which

basically gives you like more information and more guidance how to find that north star and

then there's these sc's the success criteria which basically tell you oh this is what you really have

to do. And that is what you test against if you're doing a conformance report. Principles and

guidelines are a little bit the spirit of the law, like the big like, okay, this is what we're doing

here. It's not like you're testing against them necessarily, though, you know, if you're doing a

test, you might say, oh, you know, this doesn't really fall under any success criterion because

it's like too complicated or it's new technique or technology um but it opposes this guideline

so you're able to do that not a lot of people do though uh and then you have uh the success

criteria which are the letter of the law like this is your speed limit like you can't drive

faster than 100 kilometers per hour here um and you know and the uh the guideline would be you

know, drive safe and look at other people and make sure that you don't crash. But you really

want to also say like, no, there are actually rules here that enforce this guideline.

WCAG has three levels and I like to describe them as the following. Level A removes many

barriers for many people. AA removes most barriers for most people. And AAA is removing additional

barriers. Now, you will never hear me say, I hope, that WCAG helps you to remove all barriers or that

it basically works for all people. There are always things that are not caught by WCAG. For

For example, a lot of cognitive disabilities are hard to put into testable criteria.

For example, using easy to understand language is a hard thing to put into quantifiable success criteria.

And so they didn't do it.

And the general level you want to conform is AA.

And to conform to that, you have to conform to all success criteria of the levels A and AA.

So you can't say like, oh, we're only like conforming to all the double A1s and do nothing of the A1s.

That won't give you anything.

I talked about the principles before.

Yeah, if you're using like the jargon, they often called like the poor principles because they start with the letters P-O-U-R.

And that's perceivable, operable, understandable and robust.

And yeah, these are like the general things you have to think about when implementing an accessible website, making sure that everything's, you know, can be perceived with different tools.

Everything can be operated with different tools.

Everything is understandable to many different people.

And it's built in a robust way that doesn't break when you're interacting with it or if there's new technology coming around.

So, perceivable means that information and user interface components must be presentable to users in a way that they can perceive.

And that includes things like text alternatives for non-text content.

So if you have an image, you have to provide a text alternative because people who are blind can't see the image.

It means captions and other alternatives for multimedia.

So if you have a video and someone is talking, people who are deaf can't hear it.

So you need to put in captions.

Someone who is blind can't see what's on the screen.

So you want to have audio description.

So that's all perceivable, like making sure that people who cannot perceive one way of information can perceive other ways of delivering that information.

Yeah, and also that content can be presented in different ways.

So for example, if I apply a style sheet or I increase my text size or something like that,

it doesn't lose, you know, it doesn't break the layout too much and I actually can get around.

And yeah, in general, making it easier for users to see and hear content.

Operable is basically the idea that you don't always have standard user interface components

like your mouse and keyboard that you are used to.

So the idea is that you make sure that there is a way to interact with the content using

only a keyboard.

And a lot of assistive technologies are using keyboards as a kind of API way to interact

with stuff on the page.

So even if you have like a big button to press your return key, it will be just mapped to that return key.

So it's basically also a kind of keyboard.

That's not really a keyboard, but that's why keyboard accessibility is so important.

You want to give users enough time to read and use content.

So this means that you don't want to have like your willy nilly, oh, we lock you out in two minutes.

Please do something really quick about it or you can't even.

And there are a couple of rules around that in WCAG as well.

You do not want to use content that can cause seizures.

It's super important.

A couple of years ago, well, probably in the 90s,

a Pokemon cartoon in Japan caused seizures in a lot of children

and was hence since then re-edited and basically made sure that they don't have that blinking, flashing sequence of animation in their cartoons anymore.

But you can and you must prevent that and it's actually pretty important.

And then you want to help users navigate and find content in this operable principle as well.

Then understandable, so this has a few guidelines and they mostly refer to how user interfaces are

constructed. So the information at the operation of user interfaces must be understandable. And that

means making text readable. So there is like a very general like readability thing in there. And

and understandable. So one thing that is under understandable is that UI interface, if it has

the same functionality on two different pages, those should be presented in the same way.

So you can actually, you know, go through and say like, oh yeah, I recognize this element and I

I don't have to like relearn everything that I know.

Also, make sure that content appears and operates in a predictable way.

This is important when you're using, for example, a screen reader.

You go through the content and you don't want later content to show up before earlier content, you know, and making basically a mess out of the content there.

And then you want to help users avoid and correct mistakes.

That is mostly applying to things like your forms and your user interactions.

So if you ask someone for, you know, I don't know, a street address, and you know that that street can't be inside of that town because you have a list of all the streets.

You know, you give them like feedback and help them avoid or correct that mistake.

And maybe you have like a prediction algorithm that says like, oh, you typed main street and you want to type main street or something like that.

You know, just avoiding those typos.

And then there's robust, which is one of the most nebulous out there.

And this is actually where one of the success criteria is going to be removed.

I'm pretty sure about that, but it's still in discussion.

Because it's, you know, unless or until W3C says WCAG 2.2 is done, it's just not done.

And things are open.

So I want to couch this into some caution that, you know, we don't really know what that is.

We will just teach you this robust criteria as if it stays there with the asterisk basically hovering all over us all the time.

And just so you know, this might change a little bit in the future.

And the idea is that robust gives you the principle, gives you a guideline that basically makes your content robust enough that it can be interpreted by a variety of user agents, including assistive technologies, and that you can use standard valid coding methods and practices to achieve that and maximize the compatibility with current and future user tools.

So that's general, like robustness principle.

That's a word.

There's another section in WCAG that people don't like to look at because it's a little bit complicated and technical.

But I think in the course like this, we need to bring it up.

And that's conformance.

Basically, conformance is a way to say my website, my web application, my technology, whatever you have, testing against WCAG actually meets the success criteria that are in WCAG.

And it basically defines how conformance works.

So you can say, oh, yeah, we're conforming to WCAG AA, which is what you legally want.

And Hampus will talk about the legal implications next week.

And so you can meet three levels of conformance.

I already talked about A, AA, and AAA.

And this is basically how you test them.

So you look at all the A success criteria.

And if they are all checked, yes, there's no failure there.

then you are conforming to WCAG level A.

And the same goes for WCAG level AA.

You test for level A and AA.

And there is no WCAG level AAA conformance.

This is more theoretical because there are actually success criteria on level AAA that disagree with each other

or are really hard to meet for both of them.

So I don't think that has ever happened to have a AAA conformant website, which is by design.

And one of the things that is in there is the conforming alternate version language.

This is language from WCAG, by the way.

And the conforming alternate version is basically, oh, we have the same content.

That's important.

And one of the presentations does meet WCAG and one doesn't meet WCAG.

And you can then say if you have a way to get to the WCAG-conforming version really quickly or this is your primary thing, then you don't need to meet WCAG for the alternative version, basically.

And this can be useful for some things like if you have a highly interactive, like visually interactive graph,

and just say like, oh, text description is over here, then that can act as a conforming alternate version.

So just keep that in mind.

Sometimes you don't want to, you don't want or you can't spend the time or effort on making something that is not meant to, like, to work for some things accessible in that way.

So, for example, if you have like a really, if you have visualization of something, it's taking data, making it visual.

It doesn't make a lot of sense to make that visualization accessible.

But what you want to do is take a look at the data, at the raw data, and basically make that accessible to people who are not visual.

And yeah, that's always a thing where you have to look at and see what the best approach is in context.

WCAG conformance always goes for full pages, so you can't say, oh, this paragraph conforms

and this doesn't and stuff like that.

No.

If there's an error on the page, if there's a non-met success criterion, then you are

not meeting WCAG for that page.

The same goes for processes.

So if you have a checkout form or something like that or sign up form and one of the steps

is inaccessible, then your whole, like every page in that step is also considered non-conforming.

The other thing is that you have to have accessibility-supported ways of using technologies.

So, for example, you can't use a functionality that is completely not supported by screen readers or something like that.

There is nuance in this.

Like, there might be some things that screen readers just don't care about and don't announce by default or, you know, or it's hard to get to it or something like that.

That's not meant here.

The idea is that you can't just say, oh, I conform to WCAG because I use, I don't know, this new programming language and it's inaccessible and that's just how it is and eat it.

I don't know. It doesn't work.

So you have to use accessibility-supported ways for your technology.

This is important.

And then you don't want to interfere with how the user uses the website.

And there are a couple of success criteria listed there, like if it breaks keyboard accessibility and stuff like that, that just effectively prevent users from accessing the rest of the page.

And that is interference.

And that means that everything that is considered with this interfering page is also considered not meeting WCAG.

So if you can't get to a page because you don't have keyboard accessibility, you're interfering with assistive technology.

And that means that all pages that you would get to from that page, this is the only way to get there.

would also not meet WCAG, although they might be perfectly fine.

There's a lot of additional information there,

and we get into that in the live session on Monday,

which might be today if you're seeing this on Monday.

But the idea is that we're looking at the understanding,

what that means, into the WCAG techniques a little bit,

and into the HowToMeetWCAG2 customizable quick reference.

There is the Web Content Accessibility Guidelines overview on the W3C website.

It's a little bit long and has a lot of stuff in there, but I think it's a good start.

At least after listening to this, I think you will find that you get quite something out of it.

and to close this out i want to look at success criteria because we haven't even looked at success

criteria yet and i'm i'm a big fan of not doing this as the first thing that you do because they

are basically rule sets um in the like most general way of of defining a rule set um and so

you know you have to learn to read them and understand them and uh and there's nuance in that

so reading WCAG success criteria we're starting here and the idea is that over time

you will learn about more success criteria and how to read them and also in the live sessions

we will go through them and see how they apply to what we do during that week

yeah so one of the things that I really want to encourage you is to read WCAG

and if you think like yeah this whole course is about WCAG why would you tell us to read WCAG

there has been this long-standing drive because WCAG is dense technical language that is not easy

to understand that people were like oh don't don't even look at WCAG only look at like

additional material. Um, and that has created a lot of, um, issues and problems and just like

misunderstandings about what WCAG really wants you to do. Um, and so I will, I am now encouraging

you to, you know, if you have like 17 hours, just look at WCAG and see what, what is going on. And

this information here will help you doing that. And it's important to read WCAG and define what

it means for you for certain success criteria, because there is a lot of discussion about WCAG

interpretation, even so that there is this white paper called the Accessibility Interpretation

problem, which basically looks at, okay, there are different views on it, also different situations.

So for example, if you are creating something like, if I am creating a user interface widget,

and I already know everything about WCAG, I can go and go far beyond like these basic

requirements of WCAG and make like a really good thing and that comes from WCAG because it defines

the guidelines for me but if I'm testing something I often have to like look at what is presented to

me and say like yeah does that really like meet the threshold of meeting WCAG or is this like

completely like you know off the base so uh that can be sometimes you know you have to

to look at the margins so i personally think it's more like a accessibility interpretation chance

uh you know don't let's not say problem it's like okay there are it's it's very versatile so we have

the chance to adapt wickeck to the practice that we're actually doing right now this is how wickeck

success criterion works and this is 1.1.1 the first success criterion that you will encounter

when you look at WCAG and it's also one of the most complicated so not the best like in terms of

of stepping in but it's also one of the success criteria that we see violated

most of the time. So, you know, it's just very important. So I picked that screenshot apart,

and we'll just talk a little bit about what the different components mean.

So first, you have the title of the success criterion, which in this case is success

it's a hard word success criterion 1.1.1 non-text content so success criterion is just saying like

yeah this is success criterion then you have 1.1.1 all success criteria are numbered with a three

number system and basically 1.1.1 means the first success criterion in the first guideline under the

first principle uh this does not go like it's not 111 it doesn't like float over so you have

things like 1.4.11 and and stuff like that so it's basically the 11th success criterion

under the fourth guideline in the first principle uh that's just how how it goes and i think it's

good like thing to like understand how how that is built upon um there's not a lot of value in

learning those numbers necessarily. But you know, some of the most used success criteria, you will

get the hang of the numbers relatively quickly. And then there's non-text content, which is just

the name of the success criteria and tries to give you like a really short description of what it is.

Then you have the level A, that's just the success criteria level.

In this case, it's A, it's one of the most basic things. Yeah, and then on the right side from the

level, there is the anchor link to this success question. So you can basically scroll down to the

page from a link. And it's this unassuming paragraph sign on the top right. And then you

have the links to the understanding and to the how to meet documents, which basically give you

more information on understanding what the SC actually means and how to meet it, like how to,

what are the different technologies and techniques you can use. And then there's the success criteria

in text and most of them, but this is like not a hard rule, are built in a way that you have

the format of like, this is what you need to do, except when this, that or the other is happening.

So that's the general format that you have. And like what you have to do is in this success

criterion is all non-text content that is presented to the user has a text alternative

that serves the equivalent purpose except for the situation listed below. So you have exactly that.

It's like all non-text content that is visible to the user or presented to the user has a text alternative that serves the equivalent purpose.

That's what you have to do.

And then there are exceptions.

And non-text content and text alternative are defined.

And if the underline is a little bit like removed from the text, then it's the definition.

If the underline is directly underneath the text, it's just a link to another part of the document.

That's just the convention here. And non-text content is defined as any content that is not a sequence of characters that can be programmatically determined or where the sequence is not expressing something in human language.

So you get this like, okay, what is non-text content actually? And the answer is hard to

understand, but basically it's images. Images is the main thing here, but also ASCII art,

for example. So if you're using text to create images, it's also fallen under non-text content.

And then you have the text alternative, which is also defined as text that is programmatically

assigned with the non-text content. Then you have all the exceptions. So if you have a control or an

input like a link and the only thing in there is a button, is an image, then you want to define what

it does. You want to describe its purpose. If you have time-based media, there are other guidelines

and success criteria that actually apply. If you test something or someone in the exercise,

doesn't work if you have a text alternative in there, then you are exempt from providing a text

alternative. If there's a sensory experience, then you at least provide descriptive identification

of the non-text content. I don't really know what this applies to. I think I'd never really use this

exception. Then you have the captcha, which basically is a way to prevent people from

like creating bots to create accounts and such. And captchas are exempt, though there are a couple

of caveats with it and you also get in WCAG 2.2 hopefully maybe a new success criterion that

covers some of that Captcha stuff. And then it's for decoration formatting or it's invisible.

If there is pure decoration on the page then this is not considered a non-text content and so you

you don't have to provide a text alternative.

And in that case, you have to make sure

that can be ignored by assistive technology.

So in this case for HTML documents,

it basically means you want to provide

an empty alternative text.

Yeah, this is how to read WCAG success criteria.

It's tough and we will get into like details

on how to read them when we get there,

But I want to give you like this big overview so you can start thinking about it.

And that brings us to the end of this lecture, whatever.

It's a relatively long one.

But thanks for being here and doing this.

And see you in the live tutoring or in the individual bookable tutoring sessions.

Take care. Bye bye.