Navigated to episode What makes an accessible card?.

What makes an accessible card?

by Rian Rietveld

recorded on August 07, 2019


[Intro Music] [Title: technica11y]

>> MICHAEL BECK: Welcome to technica11y, the webinar series dedicated to the technical challenges of making the web accessible. This month our presenter is Rian Rietveld, senior accessibility consultant at Level Level.

>> MICHAEL BECK: Ladies and gentlemen and all variations thereupon, welcome to technica11y! I am, of course, Michael Beck, the operations manager here at Tenon. And it is fantastic to have you here today! We have with us one of the most anticipated presenters of this year, Rian Rietveld. Hello, Rian!


>> MICHAEL BECK: Welcome to Technica11y. Today Rian will be discussing the considerations for making an accessible and flexible card pattern. So without further ado, take it away!

>> RIAN RIETVELD: Okay. Thank you. I will start my slide show now. What makes an accessible card? I'm not having all the answers. I just want to discuss some options and show some major things I see going wrong in the reviews I do.

So, first of all, I'm already introduced but this is the required slide. My name is Rian Rietveld. I work as a senior accessibility consultant with Level Level. And these slides are on So, I just published them if you want to look at them. I think there will be a blog post with all of this information later on, but, not yet.

So, what is a card? A card is a teaser on a webpage. Basically, a component with a link to other content. It wants to tease you to click the content and read that and they come in many forms and shapes. This is, for example, from the Huffington Post. You have an image and the title of the post you're linking to, an excerpt, a description, and who wrote it. And there's different layouts. The first row you see two cards and then the row below three cards.

And this is another card. These are search results by Google. If you search for Rutger Hauer, one of my favorite actors that died recently, you see there are top stories with an image with the title of the post it's linking to, the URL, and the days ago that it was published. So, there are many forms.

This is one from our own website, from our Level Level website. It has the category, the post title, and the "Read the article" link.

In this talk, I refer to "post," but it can be a page, it can be any content you want to link to, but I just refer to "post" for convenience.

A card can contain many different elements.

Well, at least, it should have a link to the post and a title of the post: that's the bare minimum.

But, also what I came across: an excerpt; tailor written teaser content or just the first few lines of the post; an extra "read more link" to the content; a featured image; an image slider; video embed; an indicator if the content is the post of a video; or the possibility to like and share the post on social media in the card itself. That last one I think is very ridiculous, but I see it many times.

And then there's also the metadata belonging to the post: publishing date; last modification date; author name; maybe there are multiple authors, so there are multiple names; the author avatar; the author's job title; a link to the author's archive page; links to related categories and tags; the number of comments; the number of likes and shares on social media. There's a ton of things!

How much info does it take to make you click? I wonder.

Is this all necessary? It's not really an accessibility issue, it's more usability, UX design. What does it need to make your audience click?

And that can be different things. For example, this is a PlayStation blog and they mention the featured image, the title, and author, also the job title of the author of the review (and this is about games!), an excerpt, the date published, how many likes and how many reviews. Maybe this is important for the audience that they know: "Okay, there are so many people commented on that. That must be a really interesting piece to read. Many people liked it." So, this can be useful information.

This is USA Today and they have the featured image, the blog title, the post title, and the date it's published. They made another decision. These are not accessibility issues, but I think you have to reconsider what actually you want for information to put on the blog post to put on a card to tease people to click. Maybe sometimes it's too much.

But, what are the accessibility issues I encounter? And I want to discuss with you.

First of all, in every review I do, I see broken semantics: HTML that's wrong, that's not rightly used; a flat DOM, like everything is `<div>` and `<span>`. It's very convenient for the developer, but it's hell for someone who, for example, has a screen reader or uses only a keyboard.

HTML5 is really the basic of the web. It's not only `<div>` and `<span>`. So, broken semantics is what I see a lot.

What is important for accessibility? The order of things: how are things presented in the code? The heading structure: what headings do you give and how do you use them? The link text quality: what do you put inside the link? And the taborder: if you tab through a page, if you cannot use a mouse, you can use the tab key to go from focusable element to focusable element. And if the taborder is a mess, it's very hard to make sense of where you are.

So, these are the four things I want to address and I'll start with, what's the order in the DOM? The DOM means "Document Object Model" and we all see that if we inspect the code.

For example, this is a page of Reddit and if you inspect the code, you see the generated HTML: this is not what you write but what's generated by the browser, so, all of the JavaScript, all of the CSS. is actually put in place here. So, this is actually what every browser works with, and what all the screen readers work with, and all of the assistive technology that looks at your website, if not to interact with your website, reads. So, the DOM must make sense. And then, it's very important that the order of things is logical because if a screen reader cannot see a website, it's read outloud to them. So you actually have to read top to bottom to make sense of stuff. And if the order of what's represented isn't right, it's very difficult to make sense of it.

This is a very simple example. For example, you have here a card and when you can see, you see, actually, there are two different cards. It's very clear. But, if you cannot see and you have it read out to you, you think, "Okay, photo of the week. That's the heading," and you read from there. And then you encounter the writer, the author and then another header. Then, you can get it wrong.

Someone with a screen reader can jump from heading to heading and then you expect, "If I go to heading, everything that belongs to the card is below that heading." And here, the author is above the heading. So, when you encounter the next heading, you have a different author, the author that's above the next heading. So this is very confusing for screen reader users. They get the wrong information out of this.

Headings should represent the content below and not what's above it because that's not really logical. Headings also reflect the page organization.

This is a very good example. This is from technica11y.

You have latest episodes. That's probably a heading. And then, you have the heading of the and the link to the post: "Designing and coding for low vision." And then by Mallory van Achterberg, recorded at, and then the excerpt, and then the next heading for the next card. So, this is a logical order, so people who are blind can actually make sense of who is the author here.

You have to use your heading right. This is an example from Reddit, and here the heading is actually describing the content of the whole card. This is actually used as an excerpt. This is a very large heading: "The official licensed browser game of Game of Thrones has launched! Millions of fans have put themselves into the battlefield! What about you?" That's one heading. That's not really describing what is the content below, that's really describing the whole content. That's a lot of text for someone who uses a screen reader to comprehend.

Also in this card, when it's published, it's above the title. So, maybe that's content someone with a screen reader can get wrong then because the order isn't right.

Then there's another thing and that's up to debate. So, I would like to hear your suggestions if you have one. Don't use a heading when you have no content, use only a link. What do I mean with that? This is from a Dutch website, Volkskrant. And on the right, there is a list of posts and it's only the post title. Above that, there's a category: News, and then there are several post titles.

Don't make headings out of this. Because then you get a list of headings with no content below.

This can be very difficult if you have a Content Management System. If you have, for example, a mix of excerpts and no excerpts, if you give the content manager the option to add an excerpt or not an excerpt. So, maybe, for some posts, you only have a heading and for other posts you have a heading and an excerpt. If you choose where, "I have not an excerpt," then it shouldn't be a heading, then it's all [unclear], the heading structure will be all mixed up. So, this is really something to debate. How should we do this? And it's bad to have here, for example, only headings.

I think no screen reader user will die from this; it may be a bit mixed up if you have headings only. It's something to debate. I don't know the answer for this. Because you give the content manager the power to add an excerpt. So, be pragmatic.

That's my solution.

Okay. Other about headings is, "Use a meaningful heading level." What do I mean with that?

Headings are the backbone of your content. And don't mess it up. This is one of the Volkskrant, this is a Dutch website. If you are the developer of this website, I will give you some free consultancy how to fix this.

But, what you see here is the headings on the left and there is no H1. There is H4 for the main article. And then there is H4 for the news category. And there are a lot of empty H4s and a H3; it's just a big mess. You cannot really make out the structure out of this. Here headings are chosen for the size or just left empty because maybe in another view there's a heading visible. This is really sloppy code.

This is the headings map from the BBC. The headings map is a really cool Firefox extension; it's an add-on. So, this is what I'm using here to show the headings map. Here you have H1 is BBC homepage, and H2, "Welcome to the BBC," and then you see the biggest topics of the day. And they are H3s and those are the blog posts. Then another H2, that's the main category, "News," and then H3s there are the news items under the news.

This is really a good structure. Here you can see how the page is put together. That's not only very convenient for blind people but also for search engines. They can see this is the structure of the page. That's about headings.

Link text quality. Link text must be meaningful and clear. Right. We all know that, don't we? This is from the Mirror website, a UK website. Screen readers can call a list of headings, but can also call a list of links. And on the left you see a featured image of someone injecting herself with something to lose weight, I guess. And then, there's the link to the category, "Obesity." And then, there's the blog post title: "Miracle flab jab branded 'wonder weight-loss treatment' yada yada yada," and below that, there's an icon of, I think, comments: it's like a little balloon or something and then after that there's the number 12.

If you look at the link list, the first one is the link on featured image and that's actually the URL it's linking to, I think.

Then "Obesity" is a link to the category. You can see that. Below that, there's a link really describing the content it's linking to. Then, you've got a link: a question mark 12. That means VoiceOver doesn't know what that icon is.

So, these are the links of the featured image and the link for the comments are really not understandable. They should be very clear.

For example, you can use an ARIA label on the link to the comments and you can say, "Amount of comments: 12" or something. You can overrule that. But what do we do with the image?

Linking an image. What should the alt text be? And this is where I get the most questions about with all of the designers and, especially, the developers, from the developers. And I don't know why, but, it's a heated discussion. I posted this once on Twitter what I thought to do and I got a lot of comments from people who didn't agree. So, I want to make one thing clear. WCAG says, "All non-text content that is presented to the user has a text alternative that serves the equivalent purpose." It doesn't say you have to describe what the image is. You have to say what the purpose of the image is. And this is Level A. Single A.

So, I wanted to let you know in CodePen what I mean, what I think is good practice. and what the fight is about with the frontend developers.

Okay. Linked images if you have no alt attribute. So, you have the link, and there's an image, and there's no alt attribute: how does that sound? I will fire up VoiceOver.

>> VOICEOVER: That sound VoiceOver on Safari, VoiceOver window.


>> VOICEOVER: Comma sound VoiceOver Safari. VoiceOver window cover Rian Rietveld okay. Comma sound voice on Safari.

>> RIAN RIETVELD: I think it's --

>> VOICEOVER: One single window comma sound VoiceOver sound Safari comma Rian Rietveld.

>> RIAN RIETVELD: I think something is interfering, the Zoom is interfering.

>> VOICEOVER: Sarah comma Rian Rietveld.

>> RIAN RIETVELD: I will stop this and I will say what the screen reader announces and you can practice this at home. If you have no alt attribute, then the screen reader thinks, "Okay, this is the content, the image is the content," and because there's no alt attribute, the image or the URL of the image is announced. So, what the screen reader announces if you give focus to this image, this linked image, it says, "Home flowers dot jpg." If you have an empty alt attribute, then there's no content at all in the image, in the link, I'm sorry. There's no content on the link so what the screen reader does, it reads the URL.

So, if the link just says that it's a link and it goes to HTTPS:// That's not very convenient for screen reader users because it just gives the URL instead of what the link is going to.

If you describe what the image is about in the link, for example, you give it the alt [text], "flowers," then the screen reader will see, "Okay the link text is 'flowers,' so the link text will be 'flowers.'"

So, that's not really information about where you're linking to: you're not linking to flowers. You're linking to the website of, my website, Rian's website.

So, if I use this alt attribute, the link mentioned in the link is "Rian's website." Then, the screen reader will see that as the link text. So, the link name will be announced as, "Rian's website." And most people don't want that because they say, "That's wrong." But, this is how it works.

This is really the content: the text that's inside the link, the accessible name, will be the alternative text. So this will be announced as, "Link: Rian's website."

If you are so upset by losing something else as an alt than describing the image, you can just use an ARIA label. The ARIA label you can override. You put it on the link. And you can overwrite what's inside the link. This will announce exactly the same if you have an alt as "Rian's website" or you have on the image or you have a link and you have an ARIA label on the link. The ARIA label will completely override what's here inside, so this will not be announced.

So these are two options you have.

The other ones are wrong. These are just the only right ones.

I prefer not using ARIA if I cannot. So, I prefer using the alt text and having the link destination site.


This was my concern and I hope I made it a bit clear. If you have a screen reader, the links in the CodePen can be in the slide [also below in the description].

Then the other one: be very clear about hover and focus styles. If you tab through a card, you must really see where you are. If you hover over a card, you must really see what's clickable.

Don't assume that people will really know what a card is. I have one example, a hover example, that went wrong.

Okay. This is a website we created, our company created a few weeks ago. It's about a caterpillar that's only on oak trees and it's really bad for your health. It gives you rashes. And we had cards like this. We hover over it. You see it becomes a hand and then people can click on it. And people didn't get it. They didn't get you could click it even if the pointer became a hand. Because there are two little changes going on and what we did, we did a big button here below: "Bekijk het antwoord." That means, "Look at the answer." So,people were saying, "What's the answer to this question?" and we had to add a big button to make it clear that they had to click on it to watch the answer. So, don't overestimate how easy it is for people to use a card. Because you're a designer, you know everything. But, you are so used to all of the interfaces, but, most people need some more help to actually get the interface.

So, don't let people get lost.

Mallory van Achterberg gave a great talk last month over enlarging and zooming. I really encourage you to check it out. And if you zoom, maybe you can get lost if you are tabbing through a page to get to a focusable element and you cannot see where you are anymore.

So, be predictable in your tab order. This is one from a Dutch website, Volkskrant. If you tab, you tab through a menu. Okay. Then the large featured post gets focus. There's a blue line around it. And if you tab further, you'll see that on the far right, the, "More" link gets focused. And then the links below the "News" gets focus. And after that, the news items in the center get focus. So, the order is not predictable. And if you are enlarging the screen, you maybe just get this. While this is done, if you are mobile, then the News items drop below the featured items and below that there are the two posts that were once in the middle. You have to watch this if you play with CSS grid, if you play with grid order. Check if the taborder stays right, that the taborder stays the way it should be if you tab through all of the links in your card.

The last thing I want to address is, "Avoid multiple tabs to the same link." And I have a few options to do that. If you have a card and you have a featured image, you have a link and you have an excerpt. Most people just hover over the image and see if it's clickable, so it's very nice to have the image clickable and also the post title clickable because that's what people expect to be clickable.

So, you can add just two links. But, then, you have two links to the same page. And if you are using a keyboard, you'll have to tab two times through each card to get further. And if you have a screen reader, there are two of the same links in your link list. So, that's a lot of clutter.

So, what can you do? Well, this is what I see a lot and I really hate this. You just put an `<a>` around everything. That's a really simple solution. Just link the whole lot. Done.

Well, this is really a disadvantage for people who get the links read aloud because the link contains the whole stuff. In this case, the alt of the image, the heading, and also the excerpt. That's not very clear for your link list. I think this is a really bad practice. So there are two options you can do what I think are very neat. You can have a `<span>` inside your link that covers the card. So you have an image and you have the H3 and then you have the link. And in the link you put a `<span>`. The container you give `position: relative`, hen the `<span>`, you give a position absolute and your let it cover the whole container with width and height 100%, `top` is 0 and `left` is 0. It works like a charm. You have only one link and if you have a keyboard-only link, it's focused and so, the whole cart is clickable.

Then there's another one, I found it on the website from Heydon Pickering, "Inclusive Components." You can do the same by using the `pseudo-element` for the link, so you don't have to use the `<span>` you just use the `pseudo-element` on the link and you do actually kind of the same: `content' empty and `position: absolute`, left, top, right, and bottom 0. Very neat. You can even add an extra link to it. If you have a link, for example, in your excerpt, that link you give a `position: relative` and a `z-index` that's a positive `z-index` and if you hover over that, that's really a separate link.

Okay. So this is all done with CSS. You can also do it without CSS. And this is also up for debate. So, I would like to know your opinion. But if you have a `tabindex="-1"` and the `aria-hidden="true"`, you can completely hide links for a screen reader and for a keyboard users. Then the links are still there, but, they are skipped while tabbing, and they are hidden from the link list for screen readers. So, we have here two links in the same blog post but only one is tabbable and only one pops up in your link list. Which one you prefer is up to you. Just don't put a link on the whole container, please.

Okay, this is what I wanted to say. There are a lot more things I wanted to address if I had much more time, like: Should I put links on everything? Should I link categories? Should I link authors? Should I put categories in the list items? Should I use many screen reader texts or what should I hide and what should be clickable? But I think these are the main issues, like good heading structure, good link text, and make the order logical. And most of all, dear developers, learn HTML5 deeply. Thank you. So that's what I wanted to say. If you want to contact me, I'm on @RianRietveld Twitter and my company is Level Level. I'll stop sharing my screen now.

>> MICHAEL BECK: Okay thank you very much. That was very interesting. I'm going through the chat to see if we had any questions. Talal asks what's the argument against putting a link around the whole container?

>> RIAN RIETVELD: Because the link text will be huge. The featured image, also, the metadata, the example would be there. Putting it around the container means that everything that's in the container will be announced to a screen reader user. And that's really a lot of text sometimes.

>> MICHAEL BECK: Yeah that makes complete sense. All right. I certainly love the advice of learning HTML5 deeply. Everything I see whenever we go through a lot of stuff, just, "Why are you overcomplicating this?" HTML5 is made to do this, why are you adding ARIA labels and all of this other stuff just whenever you can use the native code for it. It boggles my mind. But yeah.

>> RIAN RIETVELD: I think you have to look at your code. And I see a lot of people setting things up in `<div>` and `<span>` and that makes your code really flat, like it has no real meaning. It's so easy because it looks okay. It works for you. But, for all the technology that really interacts with your site, it's really, yeah, hard to understand. And, also it doesn't really work very well. And, if you give structure and meaning, if you look at your card to say, "What's really the meaning of this? Is this a list?" If you have a bunch of cards, put them in a list. And then, it makes sense because it's a list of cards. Look really at each element: Should this image be linked or should I do this differently? That is what I wanted to really emphasize. Look at the code and look at the `<div>`. Is this a `<div>` or is this maybe a paragraph? Or is this a heading or maybe it's not a heading. Is this an image? Does it need an alt text? What kind of alt text do I need here? And do you really consider instead of just bumping out `<div>` and `<span>` to make it work for you visually. Because it also has to work for screen reader users who have to listen to it. And they don't have a visual overview of how it's put together.

Yeah, I see a question: "What about article tag for a card container?" Is that a good idea or choose something more subtle? I think, I looked that up on and it's really my place to go for really specs about HTML5. And if you look there, it's really for the blog post itself. And if you have a lot of articles below each other, I think you should reserve it through the blog post itself. But in the examples that in the end gives, they use, also, articles for cards.

So, maybe it's up for debate, but, I don't think any screen reader actually announces if it's not code or not. I don't know really weight it has and if it's really semantics meaning the adds to it. So, I think read the in the end specs and see if it actually suits your website. There's not really a wrong or right I think in this case.

There was another question: "Is there any valid use case for the CSS `order` property from an accessibility point of view? For example, the heading with the author visually above it or would you suggest a different solution?" I think that would be a good use case. If you have the heading above, for example, the author above the heading, as long as it's in the DOM. It's really, without the CSS, that's really the DOM is in the right order: first the heading, then the author. And then you can with CSS switch them if it's not a link. If it's a link, the order must be just as you see it, but, if it's not a link, you can change that with CSS so the order visually different. Only not if it's a link because the link order must be the same as the DOM order, but, for example, if the author isn't linked or if you want to add extra text, then you can use `order`, I think.

>> MICHAEL BECK: Okay we have another question in the Q&A. They just wanted you to share the CSS code that you showed to make larger content area clickable.

>> RIAN RIETVELD: Yeah, all the codepens.

>> MICHAEL BECK: And then I'll also have that in the description on the YouTube video as well we'll have the link. Someone did mention earlier that it's hard to come up with questions because you covered everything so well already.

>> RIAN RIETVELD: I have some questions!

>> MICHAEL BECK: Well this is new! (Chuckles).

>> RIAN RIETVELD: Well, actually I want to say, "Why is it so unclear to have the post title of alternative text in links?" Because I get so many responses on that, that it's wrong. I would like to have some feedback out of that. It doesn't have to be now. But, really I want to discuss about.

>> MICHAEL BECK: Yeah if anybody has any thoughts on that, go ahead and hit up Rian on Twitter, as well. And okay. It looks like we are out of questions. Well, thank you, everyone, for attending. And thank you, Rian for that excellent presentation. Next month we have Doug Scheppers on. What is Doug talking about? I honestly can't remember what Doug is talking about. Let me take a quick look. He'll be talking about how to think about the accessible data visualizations to learn how the brain processes data visually and how you can leverage different senses to provide an equivalent experience for people with different disabilities. And that's going to be on September 4th. Wednesday, September 4th, at 11 a.m. and that will actually be the 12th episode of our first year at technica11y. We started last October. And September will be our 12th episode. So it will be our end of Season One, I guess you could say. So hopefully we'll see you all next month. Thanks again to Rian for her presentation and to Clare for her captioning. And we'll see you next month.

>> RIAN RIETVELD: Thank you, all. Bye bye. [Title: techinca11y August 7, 2019] [Title: Presenter - Rian Rietveld @RianRietveld] [Title: Moderator - Michael Beck @stilts121] [Title: Music -] [Title: Captions - ACS]

Back to the main page