ZACK: Hi everyone. This is Zack Poelwijk, Director of Client Success at ABILITY Digital Accessibility Co., and I’m joined today by our Lead Auditor, Jon.
And this is a really excited — exciting training we’re going to be doing today, talking specifically about best practices and protocols for people who are in Design or Creative roles. And we’re joining you virtually in this — in this recorded webinar today. I’m joining you from my home office and Jon is at our headquarters in Eugene, Oregon in our video studio. And that’s important because Jon’s going to be demoing some — some things for us, so he needs that technology.
So what we’re going to do today is go through a slide deck that walks through a lot of practices, standards for designers and creatives. And the concept is this: is, if we can prevent accessibility issues before they make them — make their way down to, say, development or QA testing, we — we save everyone involved a ton of time and a ton of money. So what we hope to knowledge transfer today is that you take these principles related to the design aspects of accessibility, [that] you can start building these into your protocols, and [that] it’ll just become hopefully second nature so that, you know, “Oh, when I do ‘X’ or when I do ‘Y,’ I know that I have to meet this criteria.” So that’s what today’s about.
And with that, I’m going to share my screen to a slide deck we have prepared. And then we’ll get started.
So this is, of course, Digital Accessibility for Design/Creative Teams. And what we’re going to run down today — we’re going to, at a high level, define digital accessibility just so we’re all coming from the same place, and then we’re going to dig right into the content.
So we’re going to talk about color contrast. We’re going to talk about hover-over features, focus indicators, specific rules for font [text], and then visual assets like images, SVGs, infographics, and tooltips. We’re going to cover all that today.
And the big takeaway from today — I think the primary principle, if we had to boil it all down, is really about color contrast: ensuring that we have properly measured color contrast wherever it’s needed. And by the end of that today, I think you’ll have it down pat.
So let’s talk about digital accessibility first. My slide here says, “What is digital accessibility?” and “How do we define it?”
So digital accessibility, first of all, is for digital assets. So these are going to be websites, software, software-as- a-service, browser-based software, desktop-based software, and native mobile apps. These are the assets, digitally, that we’re talking about today. And I’m probably just going to use the word “website” and that just will encompass it all. That makes it a little bit easier.
And then the concept is that if someone has a kind of impairment or disability, that they’re able to use the web and still experience the web and experience the content that’s presented to them. And as you can imagine, if — if you’re anywhere on the spectrums of deafness or blindness, if you have cognitive impairment — like, perhaps, brain trauma that requires you to process information slower — or if you have motor impairment like paralysis — you can’t, perhaps, use your hands or fingers as typically would be used — or even temporary impairment like recovering from a surgery or an injury. You can imagine that it would be pretty difficult to use the web, to use websites, say, if you can’t use your eyes or if you’re deaf or if you are paralyzed, right? And so, the concept is that these digital assets either need to be built in a manner or retrofitted in a manner so that they can be accommodating to people with these types of impairment and disability.
And, of course, the lowest hanging fruit to prove the concept is this fairly large subset of our population [that] is very likely using assistive technology, like screen readers — screen reading software — to help them navigate through a website. And those websites need to be built in a manner or retrofitted matter that a screen reader can interact with it and know what it is interpreting so it can audibly demonstrate that to the end user. So that’s the real battle that we’re all up against.
Defining digital accessibility is a different conversation and that’s what this slide is about, is defining digital accessibility. There is a single, unified standard that virtually everyone on Earth agrees on for being *the* standard. It’s written by people *not* in government. So they’re not lobbyists or attorneys or — or senators, or anything like that. It’s written by people in Tech. And the organization is called the World Wide Web Consortium. And then the set of standards is an acronym, WCAG, sometimes called, “Wuh-cag.” It stands for the Web Content Accessibility Guidelines, which is a living document that gets updated over time in drafts. So we are living in version — draft version 2.1, as of this — this training video. And someday in the future, we’ll be in draft version 2.2.
We have provided a hyperlink in the — in our slide deck to this website. We’re also going to just bounce out quickly and show you this website.
This is the set of guidelines themselves. This is probably the first place you need to start when you need to learn about accessibility. This quick reference website is provided by the authors of WCAG. And as you can see, everything is organized by article number for easy organization. And then in the right three-quarters of my screen, we’re in the meat and potatoes of the webpage.
We can see that we have a section dedicated to each article with the text of the article itself, [a section] showing techniques on how to succeed or fail to meet this criteria, and then there’s also a button called “Understanding article such-and-such” that digs in even deeper and gives you a deep, deep dive into each article. Very well written and very well researched. That is going to give you all kinds of context.
So we provide this, here. It’s in the slide deck as well. So I’ll bounce back to our slides.
And then, finally, the four principles of accessibility are this — your digital assets need to be these four things: they need to be perceivable, they need to be operable, they need to be understandable, and they need to be robust.
So think of these core principles as we start talking about what you need to do about it from a creative standpoint. Okay? Just — just one example, just one example is web content needs to be robust. And what I mean by that is it needs to stand out. It needs to be very clear what you are experiencing on the web. And a big part of that is color contrast. Having strong color contrast between font [text] and whatever its background color is ensures robustness of content.
And that is a perfect segue to the first thing we’re going to talk about, which is the use of color and conveying information. Okay?
I need to move something here really quick — excellent.
So, the WCAG article that talks about color contrast is article 1.4.1. And it says, “Color is not used as the *only* visual means of conveying information.” And we have a couple really important examples, here.
Imagine you’ve got a web page and there’s a button on that web page to go, you know, take some kind of action, but the only instructions you provide on the page say, “Press the green button to proceed.”
Well, if I’m colorblind or have any kind of visual impairment or if I’m completely blind, that instruction does mean no favors. And there’s no way, really, for me to figure out which button to press, if color is the only way of conveying information.
But with just a slight tweak, we have a totally acceptable…philosophy, I guess you could say, which is: what if that text said, “Press the green button labeled ‘Go’ to proceed” ?
By giving context beyond just the color, now we’re giving the end user enough information to take action. So that’s what this concept is about, is not relying *only* on color to denote action or information or context. Okay? Excellent.
So now let’s talk about color contrast, which is the — which is the mathematical measurement of color between layers. Font — your font [text] may be one layer and then the color behind it is another layer. Okay? And so here’s some examples of color contrast.
The most obvious one is the background color of the web page and then the color of the font [text] that’s on top of it. That’s going to be most common, but there are others. Another one is the color of a button versus the color of the font [text] that’s within the button — like, the, maybe the button says, “Buy now,” that, that color of the font [text] — and then to add another level of nuance, is the background color. So we have a background layer, we have a button layer, and we have a font [text] layer.
Another — another thing to think about for designers is hover states. So like a web page “at rest” versus a web page if you’re hovering your mouse over an element and maybe the element changes color. So we need to make sure we’re considering color contrast just — not for — not only for when the web page is at rest, but whenever a hover-over is engaged. That color and it’s contrast also matters.
And then — and then finally, a focus indicator, which is a key part of accessibility we’ll talk about a second, versus its background color.
And, arguably, the most important slide of today’s presentation is this one. This explains the requirements of color contrast whenever font [text] is present on a web page.
There are just two rules as it relates to font [text] and color contrast, okay? For standard sized font [text], you need a color contrast ratio of 4.5:1 against its background color. Okay?
If the font [text] is considered large, you only need a 3:1 color contrast ratio. So you need less contrast the larger the font [text], which makes sense, right? If the letters are bigger, I don’t need it as dramatically color contrasting.
So large font [text] is defined in two very specific data points. The first is if the text is at least 18 pt font or 24 pixels tall, one or the other, it’s considered large. Okay? And/or, if the font [text] is bolded in its styling, it can be smaller and still be considered large font [text]. So if it’s bold font [text], it only needs to be 14 pt font or 18.5 pixels tall. That sets the tone for everything on today’s conversation.
The one ingredient we haven’t talked about yet, which Jon will demonstrate in a moment, is — how do we check for or measure color contrast? Okay?
And so this specific rule is provided via hyperlink, here, that goes right to the article in question. “Contrast Minimum” is what it’s called.
So let’s talk about a couple use cases. I mentioned focus indicators a moment ago, so this slide really focuses on focus indicators. Focus indicators need a 3:1 contrast ratio as of today — we’re filming this May 2022. But note that we — we have already been alerted that the future version of WCAG, which will be called 2.2, is going to require a stronger ratio for visual focus indicators. It’s going to require a 4.5:1.
So if you are interested in saving time in the future or “future-proofing” your digital assets, we would just advise that you have [a] 4.5:1 color contrast ratio on your focus indicators.
And focus indicators are illustrated in this screenshot that I’ve prepared. And so a quick description of this screenshot is: we have a screenshot of a home page of a website where the tab order — meaning that I’ve clicked the Tab key on my keyboard — and the focus has been moved to the first drop-down menu in the site’s main navigation. You’ll see a solid-colored, like, black border around what would otherwise be clickable by my mouse. That is what a visual focus indicator is — it is, it is what its name implies. It indicates where the focus is visually.
So, these would be things that are actionable or clickable on a web page. So drop down menus, obviously, are actionable or clickable. Buttons. Text that’s hyperlinked somewhere. These are all examples of something that would be — that would require, excuse me — would require a visual focus indicator. So that’s what those are.
Now when it comes to testing for color contrast, we have some great resources for you. Some are linked and some we’ll just talk about.
One of them is Chrome DevTools — it’s a native — it’s a native tool, free for use as part of the Chrome web browser. Jon will be digging into that a moment. WebAIM is an independent organization that provides a free and very accurate Color Contrast Checker that we’ll take a look at in a moment. Chrome all — the Chrome web browser also provides a free extension called the Eye Dropper, which helps you identify hex color numbers for any color that is a se– or, excuse me –for any pixel that is a part of a browser experience. So if you’re trying to identify what a color is on a web page, you could use this.
And then, finally, we have an internal, really awesome software that we’ve built and are providing available to the public called The A11y [pronounced “ally”] Toolbox. And as a part of that will be a color contrast checker tool. So be on the lookout for that [in] future announcements from us.
So with that, I’m going to hand the floor to Jon and we’re gonna show some real life examples of the things that we just talked about.
JON: Awesome. Thanks, Zack. Let me share my screen here and we can get into it.
Awesome.
So, we’ll start off first with focus indicators. And like Zack was talking about, a focus indicator should be on any element that is actionable or can be interacted with. So like he was saying, the drop-downs, buttons, links, stuff like that.
And this site is a fantastic [example of] designing focus indicators for varying background colors. So we have on the top of the the page, here, a dark blue background followed by an aqua, and then a white. And if you can imagine, some focus indicator colors that may meet 3:1 ratios against the dark blue may not work against a white.
So I’ll start by clicking in the top corner, here, just so we can get our tab order to the top of the page. And when I hit Tab, we can see this white line — this white focus indicator — appears around this logo link. And we can see that it’s a white against a dark blue, which is fantastic. It meets that requirement that we’re looking for.
If we continue tabbing through the page into this Parts dropdown, we can see we still have that white against dark blue background. But if I tab into the list — the drop-down list, here, which has a white background, we can see our focus indicator actually turns to a blue. So we don’t have that same white focus indicator that we just experienced with the last two elements, but we have this blue on — I guess it’s technically gray, because the background of this this element is gray — but this blue-on-white, kind of blue-on-gray background.
And this is something that we can think about as we’re designing our sites and our pages and our elements and components, is: what kind of background colors might this content be appearing on? And what focus indicators? And how can we change our focus indicators to make sure we’re meeting those same requirements?
If I look into this aqua section, we have this dark blue button and we can see that we still get a white focus indicator again. And moving down into our white section on this Appliances button, here, we can see our focus indicator becomes a black outline.
So this is a great example of how we have three different colors with different focus indicators that are all changing color to make sure that they’re still persistent and present and visible. They’re perceivable and they’re robust in the sense of the page. And when a user is going through here, there’s going to be no question as to where they are as they’re navigating through the content, which is fantastic.
The next example that I would like to show is talking about hover states. And as Zack was saying, this is one of those things that we have to think about when we’re thinking about color contrast and how we’re approaching our designs.
So this page does a fantastic job about covering different hover states on different elements. The two elements that I really want to look at here are going to be these navigation links in the top, here, as well as these “Get a Quote” buttons.
So I’ll just start by opening up DevTools by clicking Right Click and Inspect. And Chrome DevTools has this fantastic kind of tool — and I’ll talk about this later as well — but it’s this “Select an element in the page” tool. You can get to it by pressing Ctrl + Shift + C, but I’ll just click on it.
And if we hover over this content, we can actually get the hex color that we’re looking at for this content — which is kind of like a dark gray, there — as well as the contrast ratio of that text against the background. In this case, we have a 6.93 [ratio].
However, if I hover over this text, we can see that it actually changes to more of a blue-green. And this is something that we want to keep in mind because as we are developing different states and different dynamically changing elements, we need to keep in mind that we need to differentiate the states while still maintaining our color contrast.
So I’ll go into DevTools, here, and this is a neat little trick where you can set states. So I’ll head it — set a hover state for this text. And if we do that same thing, we can see our color has changed, but our contrast ratio is still at 4.96, which is more than what we’re looking for to meet WCAG guidelines.
So that’s a really awesome way — and a really awesome way of approaching this issue, is making sure that even though we’re changing the color, it’s still maintained as accessible.
The next one I want to look at is this button, and this is the same sort of idea.
Let me scoot my DevTools over a little bit.
And we can see that we’re at a 4.96 contrast ratio, here. I’ll do the exact same thing, and we’ll set a hover state on this button. And we can see, there, our button has gotten darker. If I do that same thing, we can see we’re up to a 6.8 contrast ratio now.
So this is a great example of just thinking about our hover states beforehand, designing colors that look good, that fit the theme of the site that we’re working on — the design of the page or project that we’re working on — so we’re maintaining an elegant look while still being accessible. And this is something that we can really think about as we’re going through the design process.
ZACK: Awesome.
JON: Sweet. And then I want to go over large and small font [text] sizes. So like Zack was talking about, that’ll be 18 pt or 24 pixels for large fonts [text]. A little — I think it’s 18.5 pixels bolded, for large fonts [text]. And then anything smaller would be considered standard size fonts [text] and has to meet a 4.5:1 ratio.
Now, this is a bit of an extreme example because it has a full page video as the background of the main page. And this isn’t super common, but it really demonstrates how color contrast, if not thought about in the design phase or not recognized in the design phase, can come off as very inaccessible.
So, in the background of this video we can see we have all sorts of different colors. We have dark greens. We have yellows. We have browns, oranges. In the sky, we have, you know, light blues and whites and stuff like that.
And because this text is on a variety of different colors in the background, we have to make sure that we’re meeting color contrast ratios against *every* color that these texts might be covering over.
And this is an interesting example because this large text, here, this heading text, actually meets a 3:1 ratio against all of the colors in the background. So it would be considered accessible text.
However, this smaller text, here, does *not* meet a 4.5:1 ratio. So this is an example where the large text against the same background as the smaller text is accessible, but the smaller text is not.
And I want to draw attention to the very top right corner, here. We have our navigation menu. And it’s actually meeting pretty good contrast ratios for the start of this video. But as the video pans up into the sky, we’ll actually see that these — this white text gets almost completely lost in the sky. It has a very low contrast ratio…and there it goes. It almost completely disappears into the sky.
So this is really something that we want to think about when we’re thinking about — when we’re designing our pages for heading text: how big that heading text might be, and what contrast ratios we need to meet for all of our different texts, especially if it’s on a moving background like this, [or] if you have a picture background.
Or, in some cases, you might have a background like this, that has a bit of a gradient to it. And when it comes to text on gradients, the same color contrast ratios still apply. We still have to meet that 4.5:1 for standard text and that 3:1 for large text. And Zack will go into this in a little more detail — he has a great example that we’ll get to directly after this.
But this is a good example of accessible text on a gradient because our large text is meeting a 3:1 ratio against *every* color in this gradient. We go from kind of a pink-purple over to a light purple. And every color within that gradient is accessible against this main text, here. And the same goes for the smaller text right below it. We’re still meeting the contrast ratios that we need to meet.
So if you’re designing with a gradient, if you’re designing with different background colors, really think hard about what size you want your text to be and what colors you want to include in that background.
ZACK: Well said.
JON: And — do you want to go over the tools right now, Zack?
ZACK: Yeah, let’s go over the tools. And so this first one Jon has pulled up is the WebAIM Color Contrast Checker — a very accurate, free tool that we recommend that you take a look at.
JON: Yeah, this is a fantastic tool for anything color contrast. And I’ll just start by going over, kind of, the basics of how it works.
The main idea is that you have two hex colors, which is this pound sign followed by numbers or letters. If you’re working within a design software like Photoshop or anything like that, you should have access to the hex colors. Or, if your company has a style guide, you should also have access to those hex colors — so it can be really easy to check all of these.
But if you *do* need to get a color or a hex code that you don’t have access to, we can use an eye dropper, and I’ll get to that in a second.
But the gist of it is that you’ll put in your first hex color, whether it’s the foreground or the background — you can actually flip these, if you want — as well as our background. And by doing this it gives us a contrast ratio. But not only that, it gives us the contrast ratios and whether it passes or fails for normal text, for large text, as well as for graphical objects and user interface components — which I don’t remember if we cover in this talk, Zack, do you remember?
ZACK: We — we cover it in more depth in a future training video about Dev best practices. But while we’re here —
JON: Yeah.
ZACK: User interface components and graphical objects would be like non-textual visual elements within a website’s design, like iconography… different — yeah, different icons, things that denote action but don’t have words. Those would be graphical objects or user interface components and I believe, Jon, that’s a 3:1 ratio that’s required for those elements?
JON: Yep. That’s exactly right.
So this is a great tool because it gives you examples of these colors against each other. It tells you whether or not they pass WCAG AA and WCAG AAA. For a large majority of the time, we’ll be concerned with WCAG AA, so that’s what you really want to look at.
And I’ll just go ahead and I’ll just change our color, here, so we can get an example of it showing a fail. So we have a contrast ratio of 2.09 and we see that it fails for normal text and it also fails for large text. And it even gives you a little explanation of what’s going on, here, and it gives you these definitions for large and small text. So you don’t need to have them memorized.
So it’s a great tool for getting your colors, checking them against each other, seeing what they look like, and what WCAG Success Criteria they pass or fail.
I want to bring attention to this Eye Dropper tool. And you can use this inside of Chrome — it’s a free tool. You can download it and add it to your Chrome. And what it does is it adds this little eye dropper in our extension bar.
And I’ll just go back to one of our previous examples — this one, for instance.
And if I click on my Eye Dropper tool, we get this dropdown. And this will — it will be where we actually get our hex codes. And what we can do is we can hit this “Pick color from web page” button. And any — literally any pixel that we hover over, we can see that little box next to my mouse changing with the background color. Any pixel we select, will change the color in our Eye Dropper tool and then we can just go ahead and we can just actually copy this hex code.
So we just got a single pixel within this gradient. We can go back to our WebAIM Checker, and our background color — we’ll just paste in our hex code.
And there we go. We see that we have a 3.74:1 ratio where large text is passing.
So this is a great way to get individual colors if you don’t have acc– direct access to the hex code. Maybe you have a design opened up in your browser. Maybe you’re looking at a web page. Maybe you’re just on a design site or something and you really like a color you see. This is a great way to get that hex code, put it into the Contrast Checker, and see what that ratio comes out to be.
ZACK: Absolutely. And two really common use cases we see for this are if you’ve mocked up your app design or your website design in one of those Adobe XD documents, which is accessible via web browser, or if you just decide to open up a PDF in your web browser. You can use the Eye Dropper tool in any of those applications to identify exact colors.
JON: Yep, exactly right.
ZACK: Awesome. Thank you! I’m gonna take over the screen sharing now and we’re going to talk about images and some specific use cases for images.
Excellent.
So images are really commonly going to be part of the design process, right? Picking the right image, putting it into your mockup, so forth and so on. So let’s talk about some hard and fast rules for images that are going to save your Dev teams a ton of time down the road when they start building stuff.
So I’m going to do one very specific use case first. This use case is if you have an image file with a solid background color where font [text] is superimposed on top of that. These are usually designed quickly by marketing teams as, like, promos that maybe are just going to go on a website for a couple days and then get pulled down. And so, it makes the most sense, time-saving-wise, to just do it all by the marketing team and then just get an image file to the devs to upload to the site. But there are some accessibility things to think about, there.
So the example I have here is a — a promo and the — the image in question is, it just has a blue, flat background and then white promotional text superimposed on top of it.
So you actually *can* have this and still find a way to meet accessibility standards. And so what you have to do, though, is that when this image is published to the website, you need to provide an alt text or alt description within your website that is — that is displaying a word-for-word identical match of the words that are in the image file.
And this is the really important reason why, is that: a screen reader will *only* know that this is an image. It won’t know that it’s an image with text in it. So by providing that alt text, the screen reader goes, “Ah, this is what I need to read aloud to the user to describe the contents of the image them.”
So we actually have a — another training session dedicated to make[ing] these Dev changes. But I wanted to make [you] aware of that for design teams, so that you know it is possible.
But one thing you do need to do — one thing you do need to do is make sure you have proper color contrast. So you still need to make sure contrast is met for the font [text] based on its size, standard font [text] or large font [text]. And then Jon has a Dev note for us, here — I put it in parentheses at the bottom of the slide — that when you’re adding images to a website, they need to be IMG or image elements instead of DIVs or SPANs. And — and we’re going to cover that in greater detail in other training content. Okay?
Let’s take a look at another use case.
This is probably going to be a more common use case for designers, where you have, like, let’s — let’s say on the — on the home page of your website, you know, you have a big beautiful image slider or you just have a big hero image of something, and then you have text that you superimposed over it. And — and maybe that text is actual text within the HTML of the web page, so it’s a layer on top of the image. Or, maybe you’ve just saved the text within the image. But in either case, these rules are gonna apply.
And so the example image I have, here, is — the background is, like, this stunning landscape photo. There’s, like, a pond or stream and then mountains and hills and beautiful trees of all different kinds of green colors. And then we’ve got this superimposed text on top of it that says, “Protecting [redacted] Natural Lands for Generations to Come.”
So, a couple things you must do as a designer is: one, hammering this home again, color contrast. This example is showing what is probably standard font [text] and an example of large font [text]. So you need to have 3:1 for the large font [text] and 4.5:1 ratio for the standard font [text].
And then here’s where there’s a little bit of nuance with the WCAG guidelines, is: 90% of the text needs to meet a proper color contrast ratio at all times. Okay?
So, what the WCAG is giving us — what they’re doing is they’re giving us a little bit of wiggle room, accounting for the infinite variability of taking a photograph of, say, nature, and then trying to put text on top of it that meets color contrast.
So, it’s not a lot of wiggle room — 90% is still basically everything — but what that means in this example is, let’s say, let’s say that like the letter “P” in the word “Protecting,” you know, was partially not conformant color- contrast-wise to the background trees. You know, that’s maybe 5 or 6 percent of the total land — total acreage of these letters. Right? And so that would be okay.
What would *not* be okay is if the entire word “Protecting” or half the word “Protecting” was not conformant with color contrast.
So this is not — this is not a wiggle room for you to take advantage of and like, you know, have more and more letters be not conformant. This is a wiggle room that just buys you a little bit of grace. You know, grace is *not* getting what you *do* deserve, right? So, it gives you a little bit of grace so that there can be some imperfection.
As a general rule of thumb, we tell people not to play fast and loose with you know, “Is it 90% conformant? Is it 80% conformant?” It really all needs to be conformant, and there’s just a little bit of wiggle room.
I do want to give a couple pieces of quick advice to make this very easy. What you could do as a designer is, you could take this image and you could put a semi-transparent, like, opacity filter on it, you know? Maybe a black opacity filter at, like, 80% transparency or, you know — you can experiment with it. But simply by doing that and *then* superimposing your, in this example, white text over it will probably make it perfectly conformant. Right? So just keep that in mind. There’s some tricks you can do, say, in Photoshop in seconds where you don’t have to worry about this at all.
Awesome.
Let’s talk about SVGs next.
SVGs are a type of file. This is a — an entire Pandora’s box of things. I mean, there’s animated SVGs, so forth and so on. This is really specific to logos. Okay? We see very often that a logo — like, upper left-hand corner of your website — is an SVG. So I’m going to talk mostly about logos.
And so this next slide has an example logo. And this is good news for all designers — logos, like, are — they’re a branding element. Those are immune from color contrast requirements. Even if the logo has text or a sentence as part of its logo file, it is immune from WCAG requirements because it’s understood that that’s, like, a branding element.
So in the middle of the [example] logo, there’s this green text that says, “Since 1864.” You know, maybe that letter “S” against that yellow- orange-ish background — maybe that doesn’t meet conformance standards, but that’s okay. It’s immune. You don’t — it’s a non-starter. So just know that as you’re adding your logo files.
This is a really fun conversation next — this is gonna be infographics. Okay?
So as designers, you know, you love creating infographics. They’re, you know, beautiful, visually intensive things that describe or tell a story. Oftentimes they’re outlined in steps, like Step 1, Step 2, Step 3, so forth.
So, infographics have an official designation with [the] WCAG. They are considered complex images. And as such, there’s some specific rules that you can follow to make everything okay.
So when you design your infographics, if your infographics are going to have font [text], remember your color contrast rules that we’ve been talking about. Okay?
And then– and then, we have to go one step further. Okay? So the — the infographic is likely going to be saved as a single image file, like a PNG or a JPEG, right? Then you’re going to give that to your devs and they’re gonna paste it into the website. So that image file needs a short description to announce that this is an infographic and, perhaps, just give the title of the infographic or like the “elevator pitch” version of what the infographic is about.
So an example would be, like, “An infographic showing [How to Create a Bouquet of Flowers that Lasts].” That would be the short alt description that you would provide as part of the image file, or with the image file.
But then you need to provide a written transcript. Okay?
So this is paragraphs of text, most likely. A written transcript that describes the content, context, and nuance of what is in the infographic. Okay? And the thought experiment is to pretend like you were describing this to a friend who was totally blind and — and your job depended on you making sure that your blind friend understood *everything* about this infographic — like, no details left out. Nothing put under the rug. Like, at — explaining to a completely blind person what this infographic is.
And so, you know, that’s not difficult — writing a transcript is not difficult. But what becomes difficult from the perspective of a designer, is, “Okay… Now I’ve got this big old transcript,” — and it might be 500 words long — “Where am I going to put it on the web page?” Because it’s going to destroy your design, probably, to just slap a bunch of paragraphs of text on a web page that you don’t want it on. So we have some ideas of what you could do.
The two most common ones — well, there are three options.
The first one is not popular. The first one is just copy and paste that transcript right on the web page. Let’s take that off the table because you’re already shaking your head that that’s not okay.
So the second one is you could put that transcript within an accordion — a little accordionic section that you expand and collapse so that it’s visually elegant. It doesn’t kill your design.
Or, even easier, is if you just provided a text link, perhaps directly above or below the infographic, and the text link says, “Click here to read full transcript of the infographic.” And that would simply bounce you to a web page on your website that has a tran– the transcript.
But these *are* requirements. They’re non-negotiable. If you’re going to have infographics, these are the things you need to have. Okay?
So color contrast as you’re designing it when font [text] is available, color contrast if we have graphical objects or — or interface components, which… there *will* be in an infographic. And then we have to have our short description and long transcript.
Everybody knows what an infographic is and this is not a place where you can cut corners. This is the type of thing that a lawyer representing a plaintiff will rip you to shreds on if you don’t provide what we just described. So *do* take the time. It’ll pay off in spades over the cost of paying your corporate attorney to get you out of hot water.
Anything else, Jon, that I maybe didn’t cover?
JON: No, you did a really good job. The only thing I’ll point out is something that may not be super obvious or apparent, but — as an example, in this image — in this infographic — there’s that little blurb that says, “You’ll need: pruners and vases.”
So, those are visually presented as a list of things that you will need.
ZACK: Yes.
JON: And as such, that should also be reflected in the transcript. And that’s a lot of times something that the devs can do as they implement it. But even just within the — the transcript saying, you know, “A list of things you’ll need: pruners, vases.” Adding that extra context of what that content is visually presented as is something that can be included, and should be included.
ZACK: Awesome. Thank you. Thank you! And then the last topic of the day as it relates to creative is — or, excuse me — are tooltips.
And this is a really specific use case, but we see this a lot of [the] time in our clients’ design so we just want to give you the information to make these conformant from a design perspective. Okay?
And so I have a couple screenshots, here, that show example tooltips. Tooltips are usually these little helpful things that give you, like, a little nugget of information. Again, it’s visually elegant, as opposed to just copying and pasting this text on a web page — so that’s why designers use them, I think.
And so we have two examples. In both examples, the tooltip is presented as like a little circular icon with the letter “I” in it and “I” would be for “information.” Sometimes a tooltip will have an exclamation point or a question mark…you know, that’s fine. But that’s typically what they are.
And so from a design perspective, if you’re mocking up tooltips — I’m going to sound like a broken record, but this counts as a graphical object or user interface component. So the tooltip icon itself needs a 3:1 ratio against its background color.
And then the tooltip opens up, you know, a little pop-up, basically, a little thought bubble. And again, keep in mind, there, that the font [text] –that’s the message — and the background will need color contrast. It’s very likely that this will not be large font [text] — it’s going to be standard font [text]. So you’re going to need the strong 4.5:1 color contrast ratio.
The rest of the rules for making tooltips conformant comes from the development side — how to build a tooltip so that it’s conformant. So that’ll be followed in a separate video. But from a creative standpoint, that’s what you need.
And that is everything as it relates to design — just a few principles. Let me just very quickly overview what we talked about.
Color contrast is king. Color contrast for user interface objects and components is 3:1. Contrast ratio for large font [text] is 3:1. Contrast ratio for standard font [text], which is all font [text] except large font [text] is 4.5:1. Contrast for visual focus indicators is 3:1 today, May 2022, but very soon will be 4.5:1 as the requirement, so we encourage you to just do that. You can measure color contrast with the various tools that Jon showed us.
And if you’re able to just do these things in your design, everybody’s going to be so much farther ahead when it comes to building out these assets.
So thank you, again, for your time and be on the lookout for more training videos from our team as we delve into different topics.
So, with that, have a great day and thank you for making accessibility a priority in your company. Buh-bye.
JON: Thanks everyone.
