Unlimited WordPress themes, graphics, videos & courses! Unlimited asset downloads! From $16.50/m
by
Lessons:23Length:2.5 hours
Access 1
  • Overview
  • Transcript

3.1 Links

Links are essential to how we navigate the web. Without links we wouldn’t be able to get from page to page or even to different portions of a page with internal links. Links relate to Guideline 2.4.4, Level A, called “Link Purpose, In Context.” This requires that any link in your page is easily understandable and the content of the link makes sense and the context of that link is understandable.

Related Links

3.1 Links

Hey, John Hartley here. And in this chapter of A Beginners Guide to Web Accessibility, we'll be taking a look at some of the guidelines of the WCAG. And how you can meet those, and also a few areas where these guidelines are not met. How these are currently on a website that don't end up being compliant and how you can fix those. So in this particular lesson, we'll be looking at links. Links are essential to how we navigate the web. Without links, we wouldn't be able to get from page to page, or even to different portions of the page with internal links. Links relating to guideline 2.4.4 are seen here and that is link purpose in context. So the links need to have some sort of context and there's also another part of the WCAG where the text and the link must be discernible. The content of the link itself needs to make sense. And the context that the link is in will then become understandable. So let's look at a few issues that are prevalent and easily fixable. I've put together a large sample of links, and we'll kinda go through those here. And we'll also hop over to the code. And first and foremost, with any link, you need to make sure that there is an href. And in that href it has to have something. Whether it be an octothorpe or a hashtag, as I have here, or whether it be a full on link or telephone link like we have down here. It needs to have something in there. If you find yourself wanting to create a link in this way without any sort of href, then you're most likely wanting to just use a button. And the main way to think about whether or not to use a link or button, is buttons generally handle something that then happens on the same page. Whereas a link will take you to a completely separate page. So a button would open a dialog or a modal and a link would take you to page two or page three or some external page. Now down here in this code, and you can see this over here, Link and ARIA, it's best to let a user know if your link is going to do something out of the ordinary. So if a link is not taking a user to another page or is not using the number inside as a telephone number, then you need to make sure that they understand what's going to happen. So from looking at this link right here, More Details, you would think that this would expand, show you a few more details, something along those lines. But if you click it, it's actually going to try to download a PDF. Now this is a bit out of the ordinary and normally you would say download this PDF or something along those lines. But there's a fairly easy way that you can actually fix this. Right here in the code you'll see I have added an aria-label. And ARIA stands for Accessible Rich Internet Applications. Now, in this context, aria-label is a way to give this a bit more detail to a screen reader, while not having any external content. So this will download the PDF directly to your computer. And that's a label that we will now have on there, all you will ever see is this More Details text. But if you're using a screen reader, you can see that it says, Visited link, This will download the PDF directly to your computer. So the screen reader, instead of saying more details, takes a look at what is an aria-label. So aria-label will override whatever the actual text is. And to follow that up we have another thing that you can do called aria-labelledby and you'll see that in the next section. So storms hits east coast, this is a very common pattern that we see, especially with news sites. You have Storms hit east coast as your title. Torrential rain and gale force winds have struck the east coast, causing flooding in many coastal towns. Read more, dot, dot, dot. Now as a sighted user, you could say okay, yes I understand the context of this, I would like to read more. But if you're using a screen reader, or you're just tabbing through a site, you may not totally understand what read more means. So in our code we can actually give it an aria-labelledby, and then we can pass in some IDs that will then read as that label. So first we'll use p123, and this is taken directly from the examples given in the how to hit the 2.4.4 guideline. So the id p123 and the text inside is read more. And then also the id of headline and we can see right here that it'll say read more storms hit east coast. So let's see if that works with the screen reader turned on. So we'll hop back to the More Details link, which is read as visited link. And it reads as visited because I've actually clicked on it already. So if I tap again it says Read more, Storms hit east coast. So you can see how we don't necessarily need proper text in there to define exactly what the link will do. But this is where context really matters. Again, if this screen was blank and you were listening to a screen reader read the information to you and you came across a link, read more, you wouldn't know, necessarily, what you were going to read more of. The main distinguisher between aria-label and aria-labelledby is that aria-label, you generally use when you don't already have text on the page to help you out. So here, for more details, we want to say this will download the PDF directly to your computer. This is extra information that is nowhere else on our page. Whereas the aria-labelledby uses areas like this. So read more and then storms hit the east coast. And aira-labelledby just combines those two and reads that context. Now I got a bit ahead of myself. And I'll go back up to the top to kinda go over some general practices. First, let's take a look at how the screen reader reads some of these links. So we refresh the page, and it's gonna take a look at the top. We hit Tab once, says link, follow this lorem ipsum tutorial. And so that is completely what we have in that text link, we haven't done anything different. This is just a standard link on your page. Now in this never use section we have read more. And this is what we just talked about. So, in this case, you would most likely wanna use aria-label. But, we'll see another technique you can use here in a moment. Try not to use ALL CAPS. And also don't use a TEXT-TRANSFORM UPPERCASE because that is one of the only times that a screen reader will respect the CSS that is given to an element. Using ALL CAPS and TEXT-TRANSFORM:UPPERCASE will almost sound like the screen reader is yelling at you. Think of it like getting an email from someone that's in all caps. You read that as if they are yelling at you, or very, very excited about something. So in some cases, it may actually be best to use all caps, but in most cases, I would advise against it. Another thing that you shouldn't do with your links on a page is only have the URL in there, and here's why. >> Visited internal link, http://www.mycoolurl.com. >> And so you could hear through the screen reader why that's not such a good experience. Instead of reading the entire words in there, it reads every single individual letter. Now I'm not sure about you, but I for one would not want to go through a website that that's all they had was a bunch of URL links. Where my screen reader would then have to read every single letter of each one of those links. So try to avoid that at all costs. Another big issue we see with accessibility is the use of icon fonts and SVGs. So that's all well and good. I understand the use case behind those, but using them as links, we need to make sure that the context is still there. So take a look at this next link. Now because this is an icon, and this is from Font Awesome, this is all just a style. The screen reader doesn't know what to make of this because we've given it no context. It's in one of the i elements. So it's not sure what to do at all. Now a way around this is to either have text that's available to the screen reader. Or like we've talked about already, use something like aria-label. Take a look at this next one. So you saw that we still have the little icon there at the end of what it actually reads. But it doesn't make any noise for that. And in the process, it actually read through what we wanted it to read. Over here we can see that actual link in, and it's right in this area, so, I'll break down and single it out. Taking a look at the code that we used right there, we have the link. And then we have a span with class of readable, followed by the actual icon itself from Font Awesome. So, this is the main thing that we're looking at right here, is this span with class readable. Now when you look at the page you don't see that text anywhere. You don't see Like John's Jerky Hut on Facebook, instead you just see the icon. But we heard the screen reader read it, so what's happening there? That brings us to our first snippet of CSS which will allow screen readers to read content that is not visible to sighted users. So here we have broken out our sr-only/visually-hidden/vh/readable classes, and really you can use whichever one of these you want. In this case, I used the readable class. And then take a look at the CSS we have here. So we're absolutely positioning it. We're giving it a height and width of 1px. A padding of 0. Margin of -1, so it disappears completely. Overflow of hidden so you never see it. And clipped path of rectangle 0,0,0,0. This way, the text is never seen. We've done everything we can to totally eliminate it from ever being seen on the page. But we are still allowing it to be a part of the page which is then digestible by a screen reader. So we hide this text completely from the page, but allow it to still be read. In this way, we can add additional context while not forfeiting certain designs that we've been given or looks that we're trying to achieve. So for the title attribute, never use the title attribute with links. iFrames and frames are fine, but screen readers generally do not respond well to the title attribute being on a link. As of HTML5, relying on the title attribute for the visual display of text content is currently discouraged, as many user agents do not expose the attribute in a way that's accessible as required by this specification. Now as you saw, it does actually have a little hover. And when you're hovering over a link, it'll pop up and have whatever your title is. So using title's not a good idea. That's used over here, you can see that that is my title. So in pretty much every case, don't use the title attribute. The one instance that I can think of this is on a website called xkcd, where they have their comic of the day on the page. And then they have a title attribute attached to it that has additional information, as almost like a small extra little secret. So next up is target = blank. And this is one of the last attributes that I'll mention. This doesn't deal specifically with how screen readers read a link, but it deals with accessibility usability. So opening the page in a new tab or window prevents the user from simply hitting the back button to return to the previous page. By opening a new window or a new tab, you're then just taking that away completely from what they generally know for how to navigate backwards in websites. A case where this might be all right is if you make clear that clicking the link will open the page in a new tab. This is like what we talked about with the aria-labels. So More Details is going to read as, This link will download a PDF directly into your computer. Same thing here. So if you want to use target= blank, you would need a label, or context, it's visually hidden. It says, hey, this is going to open a new tab. That way, once a new tab is opened the user is not confused, and is able to navigate back to your site. Just to really drive the point home, the new tabs or windows affect users that deal with a loss of fine motor control, vision issues, or could confuse someone with a cognitive disability. Now I've added a link that triggers JavaScript event in here as just kind of a preview of when we talk about JavaScript events. This is an instance where you don't necessarily need much in the href and where you have to decide, is it best to use a button? Or is it best to use a link? It'll come down to how you want to develop it semantically. But, overall, if the action is taking place on your own page, it's probably gonna be a button. If it's taking you away from that page, it's most likely going to be a link. We'll touch a bit more on this later on. One more time going back to the context of a link. We have these phone numbers, and I don't think these are actually real phone numbers, but I did not test them on my phone, so not 100% sure. I'll turn VoiceOver back on and read through this area right here. >> Link 1-800-555-5555, link for more information on jerky, call John at 1-800-555-5555. >> So now, of the two of those links, which one would be more helpful if you heard it read on a page? Hopefully you're saying number two. And if so, you are correct. That one has more context. It helps out a bit more with that phone number. If that, like on many websites, is just kind of floating off by itself, a user may not understand exactly what that number goes to. You could argue that well, it's the only phone number on the page, so of course, they're gonna know that it goes directly to me. But is it going to you? Is it going to the actual store location? Is it a fax number, maybe? So, all of these things are something to consider. But again, we don't have to sacrifice the look and feel of your site, just to add more context. And to look at the actual code for that, right here I use class of vh. And as we saw that vh class is in here with visually hidden and readable. SR only means, to me, screen reader only. And, vh is just shorthand to me, for visually hidden. So using those classes, I'm able to then give more context, and hopefully let the user know to give me a call. Now you saw, throughout most of this lesson, that I was just going from link to link to link to link, and that's just with the Tab key. Users with screen readers or only using the keyboard can press Tab to skip directly from link to link. And in this way, if there's no context or description given to the link, a user will be unable to understand what your link does. And one last thing to note, images are fine inside of links. But the image then needs to have clear alt text. Much like we've given clear text to this phone number, we would need to give an image clear alt text. Now we'll talk more about images in the next lesson, but just wanted to throw that in there for now. So now we should have a pretty good idea of a few of the areas that links get broken and how we can fix those. As well as how we can give extra context to users that may be using a screen reader. In the next lesson, we'll take a look at images and how to make those as accessible as possible.

Back to the top
Continue watching with Elements