All above combined

Welcome to week four. This is about page and site structure. So we're going to look at how are websites structured and how are individual pages structured and why is this important for accessibility.

And I will try to slice it up in a couple of different videos so you can, you know, re-watch and rethink about stuff as you want to.

And also showing some more interactive things than we have been before.

Now for the first thing, I want to talk about page titles.

They seem to be like a super small thing, but they are super important.

So if we look at the browser over here, we have a couple of tabs open.

And one of the most important thing is that you know what is behind which tab.

So we have the writing for accessibility tips for getting started here at the top.

And here we have the how to meet WCAG.

Then we have page structure tutorial, web accessibility initiative.

And these are all on the same domain.

So they have the same icon.

and they follow roughly the same structure in the title.

And the guidance for page titles is that they are short

and that they are appropriate for the page that they're on

so that they reflect basically what the user is looking for.

And that's pretty important.

the page title is used in different places. So it can be used as the title on your

search engine results, or it can be used if you share a link on social media,

it will show up there. So page titles are incredibly important. And there are a couple of

things that you should think about when you're using them. So the first one is that on the

homepage, you usually don't need to put in like home or something like that.

It's pretty self explanatory.

But you want to be, you know, make sure that it describes the website itself very well.

Like we have here at AccessLab, we just write AccessLab digital accessibility,

consultants, reviews, and development, which, you know, is perfect.

No, no additional information.

I have on my website, I have home and then my name because I thought that would be appropriate for there.

Just trying to keep it consistent.

Then you want to have the most important part at the front.

So we call that front loading the information.

So if you have a latest news page, like here, this Space Teddy Inc. has the latest news page on the front, and then it has the rest basically at the back, like what is this?

And it goes from more specific to less specific.

And if we look at the Access Lab page, if we go to products, it says Access Lab products, which is totally fine.

Access Lab articles.

This can be done this way.

because access lab is very short. I personally like to put the more specific thing at the front.

So if you go to my website and go to the blog, it will say just blog. It should say blog Eric Egger,

but it doesn't. So there's the blog for you. And then here it is back to what should be

with the blog posts at the front and then the site name basically at the end.

And the same is done on the W3C page.

So here we have writing for accessibility, tips for getting started.

And then there is a pipe, like a vertical line, and that goes then to design and develop.

Oh no, it goes directly to Web Accessibility Initiative and then to W3C.

And that makes a lot of sense for this type of website.

So you don't need to have the full breadcrumb inside of your title.

That's too much.

And titles are important because that is the information you get directly after the page loaded if you're using a screen reader or other assistive technology.

It can be useful if you have an error message, if you have interaction with a form, like you have multiple steps, then you can put the step count in your title as well.

It gives everyone really nice information on that.

What does WCAG say about that?

WCAG basically only says page titled, and that's 2.4.2.

And it's a very simple success criterion.

It says web pages have titles that describe topic or purpose.

So this doesn't really say anything about like, oh, put the most important at the front or anything like that.

So especially if your title is not super generic, you will meet this super easily.

And most websites do.

And especially for like normal content websites like WordPress or something like that, the built-in solutions are pretty good.

Where you get into problems with this is if you have something like a single page application and they sometimes are programmed in a way that the title doesn't change.

So you always have like my awesome app.

And even if you are on settings or inside some specific page, it doesn't change what it says in the title.

And that is confusing to people.

So you want to make sure that the page title is specific enough.

Now let's talk about language. So you need to set the language of your page and the language of

parts on the page. So if we're going back to the W3C side, on the top right, you see this

all translations page. This is not super useful at the moment for the page that we've been on,

because that has not been translated. But if we look at Spanish, we see that there are several

pages that have been translated into Spanish. So if we go to the business case for digital

accessibility, we see that this is translated into Spanish and there is an English version,

of course. That has been the basis for that. Now, when a screen reader accesses a page,

they need to know what is going on, what is this website in, what is that content for,

in what language is that content, and it does that on the language that the website specifies.

So if you look into the code, so that's how you usually test that.

You see that there is, I'll try to make this a little bit bigger.

You see that there are some attributes on the HTML element and one of that says langen.

And that basically says the whole language, the general language of this page is English.

There are a couple of ways to do this.

uh uh lang en is the most common one but you could even use like regional variations like en

dash gb for great britain and then you know you would say like oh this should be a british english

um that might make a difference in some cases usually you can just use like the generic like

most top level language because it doesn't matter. And also you have to have this language installed

on your system. Otherwise there will be no announcement at all, or it will try to read it

in the language of the screen reader. And that will sound funny. Now if we go back to the

Spanish page. We see that it's changed to language equals yes for Espanol. So that basically says,

oh, this whole page now is Spanish and everything is translated like this. Jump to content button,

all the links here. This is translated, so everything is basically translated, even the

chrome around the actual article. So you can go and change the HTML here at the top.

But sometimes you have places where you have Swedish text inside of an English page or

or something like that. And in those cases, you want to use the lang attribute as well, but you want to put it onto that specific element or on that specific container. So if we go back to the, to the Espanol Spanish section here, and we go to inspect that, because the surrounding page is English, right? This is an English page.

with Spanish content and actually with a lot of languages like here's Greek and here is German.

And so you have these different sub languages that you want to support. You know, you want this

translator announcement and the headings. You want them to be announced in the language that

that is actually used because that's what the user would search for. And as you can see here,

the definition list that is inside of this details basically says like the language is Spanish,

and then that means everything inside here is Spanish, apart from this second,

the second dd, third item inside of this div, which is in English. So in this case, the

screen reader can basically switch languages in between. And this is for such a page,

this makes a lot of sense. Now, you don't want to always use language switching all the time.

For example, if you have like the one Spanish language word inside of an English text, like

hola, he said, you know, and there are sentences before and afterwards in English.

You don't want to switch this one word in general because switching languages can incur a short delay.

So you have a longer time that you have there that you need to wait as a screen reader user and that can be a little bit disrupting.

Also, a lot of language is just very common in the language that you're using.

For example, in German, you wouldn't translate the word computer or something like that.

So, you know, even if it's not laid out like that or the language tag is not on there, it still would be easy or easy enough to understand.

But, you know, for a page with that, with a lot of like changing languages, it makes total sense to do it.

Let's take a look at what WCAG is saying about that. There we go. One and the other. Open it. So, success criterion 3.1.1 is the default human language of each web page can be programmatically determined.

So that basically says like, oh, you have to provide as a website, you have to provide that information in a programmatical way.

There are a couple of ways to do this.

Apart from the HTML way, for example, you can configure your server to send the language with it.

Or you can, you know, set meta tags as well.

It's like there are multiple ways to do it.

The HTML one is the most simple one and that always works.

And then we have language of parts.

The next success criteria in 3.1.2, which is a double A success criteria, while the

language of the whole page is a single A success criteria.

And that basically says the human language of each passage or phrase in the content can

be programmatically determined, except for proper names, technical terms, words of

in determinate language and words or phrases that have become part of the vernacular of the immediately surrounding text.

So that's basically what I said, like, oh, if this could belong to that text, then you don't have to do this.

Yeah, and this is basically what you need to do to make sure that those meta things work properly.

OK, let's talk a little bit about navigation.

There are three success criteria on navigation that are important.

Let's start with two, four, five multiple ways, double A success criterion.

Basically says that there is more than one way to locate a web page within a set of web pages, except where the web page is the result of or step in process.

So if you have step one, step two, step three, and step two, you only come through step one, then this is accepted.

but any other page on the website you need to have at least more than one way and usually that

is search you have a search on your page often it can be a sitemap and it's totally also valid

if there are multiple pages on the page so for example you can go from your home page to your

about page and also you can go from your homepage to the news page and then to the about page

these would consist as two different ways to get to a page so this is I think in the general sense

a pretty no-brainer because you want you know you want your pages to be found so

So I think I've never failed this in my experience as a tester.

The second success criterion is location, location, location.

AAA success criteria, information about the user's location within a set of web pages

is available.

Now, this is basically a requirement for breadcrumb in AAA.

Most content-heavy web pages have that, so it's not a big deal.

Also, it's AAA, so it's not that bad.

And then we have 3.2.3, consistent navigation, and this is probably the most complicated

success criteria, success criteria even, and it says "navigational mechanisms that are repeated on multiple web pages within a set of web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user." Now, what does that mean? It means that on this page, Planning and Managing Web Accessibility, this site navigation is always after the user.

the breadcrumb navigation and before the main content. And then if I go to sustain,

this side navigation is always between the breadcrumb navigation and the main content.

If the sidebar does not exist, the rest that does exist needs to be in the same relative order.

It's a little bit complicated to understand, but basically you don't want to have like

your main navigation sometimes at the top even though it's visually at the bottom or something

like that you know you want to have everything in a nice way layout that it makes sense for you to

to explore so that's multiple ways that's not multiple ways that is consistent navigation

It's double A criterion and I think it's pretty easy to achieve and most websites do a good job.

However, you have to take a look into the code if you have a website that is built with WYSIWYG tools.

So basically where people just drag and drop stuff in and arrange it and it's like positioned, then this might be an issue.

But it's super rare.

All right, let's move over to landmarks. So basically this is now structure of the pages themselves, like on every website has their own structure.

So in this case, the way website, they have like these three or four even parts on the top with a skip to content and then the must head section and then the main navigation, breadcrumb navigation, and then basically a section that has the site navigation in it and one that has the main content in it.

And then you have footers and stuff like that.

So this is always the same structure and that's good.

You want to have this purpose on there.

You want to have a good understanding of what's going on.

Now, for people who are using assistive technology or screen readers, this might be something that they can't see, right?

But for them, it's like mostly a linear thing or it's like hard to know what's going on where.

So to make it easier for assistive technologies to know where to go, you can put in basically meta information that gives users more information on where they are on the page and also allows them to jump around.

So you get the big picture view organizational wise, and then you get the way to jump to

individual places.

And so we call that landmarks.

And landmarks are basically sections on the page that you can refer to.

So if you look at the page structure tutorial, this is what I would suggest you to look at

after this.

There are actually a couple of examples in there and we're going to go through them just, you know, to give you like the big picture of, you know.

So and these are the page regions or landmarks that are defined in the ARIA specification and in HTML.

So you have like it's really easy to get to those and to use those.

For example, if you have the page header, you can just use the header element and boom,

you have your header landmark.

It will be announced as a banner landmark actually because of history.

And you get the way for user with assistive technology, they can immediately go there

if they want to get that shown.

Footer, same thing. You just use the Footer element and that works. Now for both Header and Footer,

you have to make sure that they are not inside of an Article or a Section element, because then they

only apply to this Article or Section element and are basically not general page-wide headers and

and footers. Then you have the navigation. For example, you can have the main navigation and you can have the side navigation. And that is a super easy way to say like, oh, yeah, we have these nav elements. And that allows a screen reader user to just jump directly to those nav elements. And doesn't need to like hunt around on the website, making sure that

they find what they need. Same goes for the main element. So this can be only once on the page.

In contrast to the navigation nav element, which can be multiple times on the page,

you only want to have one main because it's the main information on the page. So it should be

unique and you can jump to that as well.

So this would be the main navigation.

Then you can have complimentary content, which is like additional information that

pertains to the main content.

And those are already the main landmarks that you can use.

And, uh, using them is super useful, as I said, for people to know what's going on.

So we can use, uh, let me see, is this the two?

Uh, no.

So here I have landmarks, a thing that shows landmarks.

So here we have the nav landmark at the top.

Then we have a header, then we have another nav, then we have another nav, then we have a main that actually starts here.

It's just the CSS is not cooperating.

We have here nav, then we have a header inside of this main.

So that is basically scoped to this article here.

And then we have a navigation here for this in-page navigation as well.

And you might say like, oh, that's a lot of navigations.

How are users supposed to be like moving around there?

Now we already have seen in the example here, like in this example, that you

can label those navigation areas.

So when a screen reader gets into these navigation areas or shows them in the list, it will use the ARIA label basically as a name for that region.

So if I go into the first accessibility fundamentals link and I tap to it, screen readers would announce main navigation or accessibility foundations link, main navigation.

So you know that you are in a main navigation there.

And then when you go through this, it would jump here, it would say home.

And, you know, on some websites you would think like, oh, this is the main navigation and I'm in home.

But you're actually in the breadcrumb navigation.

So in this case, it has an ARIA label that says breadcrumb.

So it's clear that like this is the breadcrumb navigation.

Pretty clever.

And yeah, and this is how you usually use page regions.

It's very simple. This is already like a lot and probably too much. And yes, you have two good ways to label those regions. So you can use aria-labeledby, which basically says like, oh, I'm pointing at this ID region heading.

and I label my region, in this case nav, with this h2 region heading.

So when I get inside of this container, it will say, oh, you're now reached region heading on the page.

But you can, as I have shown, use aria-label as well.

It depends a little bit on if you want to have the label shown or not.

I'm a big fan of having visible content on the page that is also read for screen reader users.

So, for example, this page contents heading that should be used as the ARIA label using ARIA labeled by for this navigation.

And so it is visible.

So if this was to be copied over somewhere else and the title changed, because that makes more sense in that context, it would change automatically.

And if you use ARIA label and you have visible content there, you always have to make sure that they match up.

And that always creates problems.

So that is how you look for those.

Probably a way to say, show, show, show, show, show.

No.

Yeah, so this is the visual ARIA bookmarklet, and that can show you all the ARIA accessible names, for example, and all the content.

Depends a little bit on what you're hovering over.

Well, there's no accessible description.

That should be okay.

Yeah, and you get a good overview on what that does. I don't know if that's really what's supposed to be happening. Oh, there we saw like breadcrumb on the top left. I can't hover over there, but I will make it bigger in the video. Maybe on the top left it says egg name breadcrumb. And if I hover over here, it says egg name main. And that basically means the ARIA label is properly applied.

really quick look at the success criteria around that landmarks and the

first one is bypass blocks and the second one is meaningful sequence so

bypass blocks is the much much more important one especially in this context

but I want to mention both bypass blocks basically says a mechanism is available

bypass blocks of content that are repeated on multiple web pages. And this is what landmarks

are. They allow you to freely bypass blocks and move there, especially if you're using screen

reader. If you're using only a keyboard and you don't have assistive technology that you use,

then skip link is super important. Like we have here, if I start from the top,

there is the skip to content link and if I press that I immediately get navigated to the main

content and then can move from there without having to like go through all of the pages at

the top because if I start from the top and I don't have a skip to content link then I'm here

in for a long time and press tap tap tap tap tap tap tap tap tap tap tap tap tap tap

Now, most screen reader users do not use the tab key to move through.

They have other ways to move around.

And you have seen some of those with Daniel in our first meeting.

But in general, this makes sure that, you know, everyone has the same opportunity.

And then a little bit on meaningful sequence that doesn't really apply to the like landmarks and stuff.

But it helps to think about the landmarks when you are looking at the code.

And meaningful sequence basically asks that the sequence in which content is presented,

that if that affects the meaning, that the correct reading sequence can be programmatically determined.

So basically, if changing up the reading order would make something harder to understand, that should be avoided.

And I have a good example for that.

So if I go to w3.org slash wai slash bat.

No, it's demos slash bat.

Demos slash bat.

This is a website that has basically an inaccessible and inaccessible website on it.

And yeah, the design is very old and it needs an overhaul at some point.

But it still shows the issues pretty nicely.

So if you go to the inaccessible homepage, we have these three, what looks like three

news items here. So we have the heat wave linked to temperatures, man gets nine months in violent

case and lack of brains hinders research. Now, if I look at that without CSS and linearizing this,

basically, you would see that these three, these three and then these three sections,

So the headings, the images, and the teaser text, they are in that order, like from left to right.

So they don't form like one cohesive heading, image, teaser text order.

They do heading, heading, heading, teaser image, teaser image, teaser image.

And then teaser text, teaser text, teaser text.

So this reads actually like, after three years of effort, city scientists now agree that the primary cause of the 2003 heat wave was hot air from our mayor.

These kinds of crimes need more creative, effective punishments.

For example, we could require compulsory brain donations.

huge drop off in brain donations due to the great success of slow traffic safe streets policy.

So this shouldn't happen, right?

That like the content gets distorted that way.

And we see that sometimes these days, but it's like super rare as well.

But I thought it weren't a mention here.

So a meaningful sequence that the reading order is programmatically determined.

Usually you do that by putting it in the reading order inside the HTML.

Every section is the same.

And so if we look at these in our inspector, we see that, just making it more visible here,

this diff newsbar goes among those three stories.

And then you have three stories here.

And yeah, because that's how this is set up.

It breaks to demonstrate exactly this issue.

Moving to headings.

Headings are super important.

So important that in the...

Headings are super important.

They are so important that in the page structure tutorials, they got their own page.

And this is because many people use them for navigation, but also to understand what's

actually going on on the website.

So what are headings?

Headings are basically summaries of what comes after them.

So for example, here headings is the heading of this page.

So this is the rank level one heading.

So the most important heading.

And then you go through and you have headings level two, level three, level four.

And just FYI, I use rank and level interchangeably.

They mean the same thing.

I think ranks is a little bit easier to understand. So I try to use that language. So basically, rank one heading is the highest rank. And then you have second rank, third rank, fourth rank, fifth rank headings.

And in HTML, it goes down until heading rank six or heading level six.

And that is basically how you want to structure it.

So if you have headings here, if heading ranks here, this would be in H2.

Then you have exceptions, which would be H3.

Then this goes back one rank to be on the same rank as heading ranks.

So this would be an H2, this would be an H2, would be an H3 again

H2, H2, H3, H3. Especially if you have a lot of content on your pages, a lot of depth

in your pages, it makes sense to have good heading structure because screen reader users,

so first they can go to the first heading really easily by hitting the H key. That jumps them

directly to the first heading on the page. And then they can press H more to go to the next

headings and if it's nested nicely, it will be announced to them and they can get a better image

of the organization of the website, especially if it is a complicated website.

Quickly look at the success criteria that apply to headings. They're pretty simple, I think.

just when you're using headings you need to make sure that the headings and the labels

and headings and labels is the success criterion we're talking about but now we're talking about

headings first and foremost that headings and labels describe topic or purpose so

it's not allowed to have a heading that just is big text and says like sale and then there's

no sale information underneath it or there are no items for sale underneath it so it's not meant

to mean big and uh and and you know with a lot of uh uh like big text and and attention grabbing

or something like that a heading is there to describe a section on the page the topic

or purpose of that section and the second one is section headings and this is a triple a success

criterion and that basically says you need to use headings to organize the content you don't

need to do that if you're using if you're only going to level double a and as you have seen

There is no requirement to have headings strictly adhering to a level.

But what I recommend and what you should be doing is making sure that when you go down from H1 to H2 to H3,

that this is consistent and you don't jump around you don't go from h2 to h5

because that would mean that somewhere in there like order is lost but you can when you go through

you go to h5 down you can then go up two levels to h3 because that basically just means like oh

you're not in that subsection of a subsection of a subsection. And that's what I would recommend.

But if you're testing against WCAG, you don't need to be super strict about that.

So the next section is content structure. And the success criterion for content structure

is mostly success criterion 1.3.1, info and relationship.

Now, info and relationship is one of the broadest success criterion that you will see.

It's probably like a little bit of a catch-all for you when you're doing audits,

especially if you're going in there.

You have the level A rank, so it's super important.

And basically, the idea is behind the success criterion is that you give the user and their assistive technology enough information so that they can interpret the content that is on your page and reinterpret that for different assistive technologies.

So, for example, we already talked about headings, making sure that they work, that the structure is conveyed, that it's clear, oh, what is a heading, what is a normal text.

That is super important for navigating the whole page.

And one through one is basically about the same thing, but more general.

So it's for all information structure and relationships that are conveyed through presentation that need to be programmatically determined or available in text.

Now, programmatically determined means that you can read it with a computer.

So that would be something like marking up headings.

You know, you put the H1 or H2 or whatever around the text and the computer can say like,

oh, this is a heading because this, I programmatically determined that.

But that also goes for other information and structure and relationships.

So, um, can look into the content structure page in the, uh, page structure tutorial.

And it's a pretty long, uh, article and I will not go into details.

Especially I will just skip articles and sections at top.

They're not super interesting.

But there are paragraphs on any page.

And you want to make sure that they are in the P element.

Now, is this like super important to be conveyed to a screen reader?

Sometimes it is.

Like they will usually make like a short pause at the end of a paragraph.

that it wouldn't do if you just have a line break there or visual break.

So it's a good thing to have that.

Now, the next one is lists.

And lists are super important because they are one of the few things that we can use to group things together.

Sections are another one.

But with lists, you have a couple of different options to use your, um, uh, to, to like group elements.

So the first one, uh, is an unordered list and I will make my screen size a little bit bigger, a font size a little bit bigger.

First one is an unordered list.

Now an unordered list can be a group of almost anything.

It just means that, oh, this is a list and it is no particular order.

like if you go um and you uh you shop for uh like a tasty vegetable chili you're gonna want to buy

corn and tomatoes and beans and onions and garlic um but it doesn't really matter in which order you

buy them as long as you have them at the end so for this um recipe it wouldn't matter if the beans

were the first thing or the third thing or the seventh thing.

So you can use an unordered list for that.

And generally, many screen readers and assistive technologies will announce those lists to

the user.

They will say like, oh, this is an unordered list and it has like seven items.

And then you as a user know what's going on.

And then it will say something like bullet corn, bullet tomatoes, bullet beans, I would say.

It really depends on your configuration of your screen reader.

I would say, unordered list, item one corn, item two tomatoes.

That can happen.

And then you've got ordered lists.

And this is where the order actually matters.

And here we have the example. First, cook beans for 45 minutes. Then second, cut vegetables in small cubes. Third, saute onions and garlic. Four, deglaze using the tomatoes. Fifth, add corn and beans.

You can't do this any other, well, you probably can do it in another order, but you can't, you don't have a lot of like leeway through it.

You can't just add the corns and beans as the first stage and then cook them for 45 minutes because that makes no sense.

Uh, you can't, uh, you know, uh, you have to cut the vegetables before you, uh, you, you, um, put them in and stuff like that.

So you need to have that order in and that's where you have an ordered list, uh, when that matters.

Um, and that will be basically, uh, announced in a similar way, like the unordered list.

It just will say ordered list and sometimes it says one of seven or something like that.

You can also nest lists.

So that means that you have a list and you have a list inside of a list.

So in this case, we have as the first step prepare ingredients and then we have an unordered list inside of that that says cook the beans for 45 minutes and cut the vegetables in small cubes.

So you can basically say it doesn't really matter in which order I'm doing this or I can do it at the same time.

So I have this as the first step, but inside of the first step, but inside of an unordered list.

Then there are description lists.

We have seen them with the language example.

I don't want to go into them very much.

They can be useful for grouping as well.

And especially if things apply to different information like these authors, John and Luke, that would work.

And then you have the one editor, which is Frank.

Now, description lists, they are sometimes not announced super well in screen readers.

So you can use them, but sometimes they say like authors defined by John or, you know, something like that.

And it's a little bit awkward.

So, yeah, it's a thing that exists.

You have quotes, long quotes in a block quote element.

You have inline quotes in a queue element.

These are never really announced.

So you want to make sure that it's also clear in the text that you're using them, that these texts are quotes.

For example, by using quote marks, that's an easy way to do it.

Yeah, and then there are tables, but tables is a story for another time.

but they can help with a lot of like info and relationship stuff.

And you need to use tables properly to make that work.

Here's a full code examples of a page.

So this goes from the body and then you have the H1.

You have the navigation with the H2.

You have the main article with an H2.

And then you have a couple of paragraphs.

and unordered list. So this is something you can find on a lot of pages. For example, here on the

Access Lab page, I showed this before. Here on the right, you see all the headings like this is an

H1 called Access Lab. Then you have the actual blog post as an H1. Then you have the contrast

checker as an H2. And then you have the screenshot as an H3. And then you've got an H2 again, H3

again. So this is pretty standard stuff for the headings. And you can, you know, depending on what

tool you're using, you can also show like landmarks. We have the nav on the top and then main is

basically everything here. So it just puts it in the middle, scrolls down there, which is useful.

if you go into the edit elements page and then we look at this part here where

it says like doesn't h2 right contrast checker and there's the link here so can

basically click on that and then on the right we see that oh there's first a

paragraph with the link in that in there and then there's a paragraph and then

And there are a couple of bullet points.

So they are in an unordered list, three bullet points.

And then there's the H3.

And then there is an empty P element, which shouldn't be there.

And then it goes into the next section.

And that goes for all of these sections.

So it's super common to see these types of content floating around and that's good.

And it should be pretty easy to see if it's used well.

Sometimes you get into more complicated stuff as well where you have like subsections and show and hide sections.

But the important thing is that what is inside is reflecting the content on the page.

So if it is a paragraph, it is also implemented as a paragraph.

And the same goes for lists and stuff.

Now, there are a couple of things that are important when we're looking to things like these links here or also on this articles page.

There is this read article link.

And as you can see, it's the same in every teaser.

So what that usually means is that if I have a screen reader and I get the list of all the links,

it can happen that I have a lot of read article links in there or I have only read more links in there or something like that.

And you don't want that to happen.

So you want to make sure that your link name is mostly unique.

I don't say purely unique, but the more unique, the better.

So if you look at this article here, this read article link, it's actually, well, it's ARIA hidden true.

So it's not there for screen readers, but it's also inside of this link.

So this is not the actual link.

The whole thing is the link.

So you have this unique link name, which would be top seven free color contrast checks and

analyzers plus the paragraph over there, if it's not hidden somehow.

And that's good.

So that allows you to just use that as your link.

And you don't have read articles 17 times in your list of links.

And you can actually use this functionality, which gives you a list of all the links that

are in there.

So here we see the long list and they have long link titles and don't care for the area

hidden.

It's not 100% how a browser would read this.

The important success criteria for links are the following three.

Link purpose in context.

And that basically means that the link needs to be easy to understand in the context where it is in.

So if you have a heading and then you have a read more link, that technically meets this definition.

but it's like very awkward don't do it um uh but yeah you have to um uh to make sure that

it works with the programmatically determined link context and that basically also makes sure

that you can use something like um uh you know uh read the news about x and y um but you can also

just link x and y as the link text because it's inside of a paragraph. So it is easier to

understand or it's possible to say like, what is this link about? I read the rest of the text.

You can, let's take a look at what programmatically determined link context is because that's one of

these WCAG texts that is not super like user-friendly to understand.

And basically says additional information that can be programmatically determined from

relationships with the link combined with the link text and presented to users in different

modalities.

So that basically means stuff that is around the link or that is in the same paragraph

list or table cells as the link or is related to a heading. Yeah, it's pretty low level, but I mean,

it's a single A criterion, so they want to make it very achievable. There is a big brother of this,

which is link purpose link only. And that basically says there needs to be a mechanism to allow

the purpose of each link to be identified from the link text alone, except where the purpose

of the link would be ambiguous to users in general. And that's a AAA criterion because,

you know, you need to be so much more specific. Like, mechanism is not a good link text for

for this, you know, you would say mechanism definition or something like that. And so this

is a super hard thing to really well achieve. And so this is AAA. And the third one is label

and name. This is a new one in WCAG 2.1. And basically it says for user interface components

with labels that include text or images of text, the name contains the text that is presented

visually. So what does that mean? If I look at my own website, we have at the top right,

it says basically there's a Microdot blog and Mastodon and YouTube link. And so the accessible

name and the same goes for blog and videos and stuff like that. These links need to have the

text that is visually presented inside of the link as text.

So in this case, videos needs to have videos somewhere in the link text.

So I could say videos that Eric recorded, that would be totally fine as the accessible name.

But whenever you see something, it should be probably the same text.

And here I have Mastodon as the, I think, only link text in there.

Yes, here it uses ARIA-labeled Mastodon.

And so I can say in a voice input mechanism, I can say click Mastodon, and that would click that link because that's assigned there.