>> MICHAEL BECK: Welcome to technica11y, the webinar series dedicated to the technical challenges of making the web accessible. This month, our presenter is Luis Garcia, Senior Product Manager for Accessibility at eBay.
Hello, everyone, and welcome to this March edition of technica11y. Thank you so much for joining us today. And say hello to the Facebook world as you may have seen through the sharing that we are currently live streaming from our Tenon page. This month we are Luis Garcia, Senior Product Manager for Accessibility at eBay, and he'll be talking about the various color related guidelines in WCAG and how fixing one issue might just create issues in other parts of the page. As always, we'll be answering questions at the end, so you can put them in the chat box beforehand but we'll get to those when Luis is done with his presentation so without any further ado, take it away.
>> LUIS GARCIA: So hey, everybody, thanks for coming out for signing up.
We're going to be talking today about color alone, color contrast, color conflicts. All sorts of fun stuff that can happen when you're doing color stuff with WCAG. So before we get started, I have the slide deck URL for anybody that wants to follow along at home or on your personal device. The URL is Garcialo.com/2019/technica11y.
And, as I was introduced, I'm Luis Garcia. I'm a Senior Product Manager for Accessibility at eBay if you want to follow me on Twitter I'm @garcialo. Let's get started. So, a real quick overview of what we'll be talking about. For the last few years I've been giving a talk where I explore exceptions to the WCAG success criteria and when I cover color related things, I show these two examples. So there's two sentences. The first one says somewhere in this sentence is a link that fails 1.4.1 which is the use of color guideline or color alone guideline, and the thing with this one is the word, "sentence," is a link. At least to me, it's pretty clearly, you know, I can tell that that blue is a link.
And then I have a following sentence which says, "Somewhere in this sentence is a link that passes 1.4.1." In this sentence, the word, "sentence," is also a link, but, it's a little bit less noticeable to me that it's a link. So, it's just kind of, like, there are some weird things going on with the contrast and the algorithm that we use for calculating the sufficient contrast for colors. I would also say things like, I kind of hate the color alone success criteria. The color contrast algorithms doesn't always work as we see in the example above but it's what we have available to us. The only difference between nothing and text is color in the shape of letters. I say things like, "I'm going to make a talk about how much I hate the color alone guideline."
And I've also encountered many things from wonderful people I've worked with. And designers, developers, people trying to meet the letter of WCAG but not necessarily the spirit. This isn't a nice talk that will make you feel all pepped up and gung ho about accessibility. It's not about like got yas like when you use color, look out for this, and work through that this way. It's kind of more of a warning of some things people might want to try to get away with so you can be prepared to say, "No," if they say, like, "Well, this technically passes," you can be like, "Yeah, that does technically pass, but we really should not be doing that."
So we'll go ahead and look at our agenda.
So as the title of the talk suggests, we're going to be looking at color alone. We'll look at color contrast. Then we're going to be looking at the color conflicts. So color conflicts in this case isn't necessarily, like, where things butt heads. It kind of is but it is kind of like things that aren't completely clear from the guidelines given to under the circumstances like what should you do. Or there's not enough guidance for how to make a judgment call.
But first, let's cover the guidelines to see what exactly we're talking about because I'm sure not everybody here is on the same page as far as, like, there's people who are new, people who have been here a while doing accessibility so we just want to make sure we're covering the basics.
So the color alone or use of color guideline, 1.4.1 in WCAG, says, "Color is not used as the only visual means of conveying information indicating an action, prompting a response, or distinguishing a visual element."
And this affects users with low vision. This affects users with various types of colorblindness. And a note on that is that when we're considering use of color, we want to make sure that we're including all types of colorblindness. So I've seen several times where a designer, they are trying to do the right thing. And they are like, "Oh, we're going to choose these colors because they work with people who have red-green colorblindness because that's the most common type of colorblindness." It's, like, "Yeah, that's good and I applaud that effort."
But, just as people working in the accessibility industry, we are representing people that have disabilities and are typically like a small percentage of the population. So, just as we're advocating for people we're saying these people that are a small percentage, they are a protected class, they need to have representation so just as we're saying that, we should also within that group not discriminate against people who might have a more rare type of colorblindness or a rare combination of disabilities. We want to make sure we're completely inclusive and that we're considering all the way down to the smallest populations, including people who might have grayscale type of vision, so, just doing stuff for people with red-green colorblindness that's not going to be enough.
I'll stop diverting from that and we'll take a look at some of the common ways people will fail use of color.
So, one of the most common ways is input errors.
So, if you have type 2 inputs on this screen. One of them is a normal state. So the first name field with text input and then we have another text input for last name. And that one the text is in red and the outline of the input is in red to show that this is in an error state. That's typically how this one gets failed because people will just change the color or something, you're using color alone to indicate the error status; it's obviously an issue.
We might have charts and graphs where we're linking the data that's in the legend with the data that's presented in the bar chart or in our graph using only color. So, the example I have is I have some, you know, no actual values here. Just some rectangles that represent bar charts, a bar chart. And then there's a legend for lions, tigers, and bears. And then the only association between the two is the colors.
Then we have the classic one, "Links in a sentence." This one, simplified, is links in a sentence, but it's really color alone that's used to indicate the interactive text when in the same context as non-interactive text. So, it basically means that in the same space, you have things that are interactive, things that are not interactive, and we're using color to show what's interactive and this typically occurs in sentences and paragraphs. But it also happens in lists and in tables so let me just show you these examples.
So, in the sentence it says, "Somewhere in the sentence is a link that fails use of color" and the words, "a link" are in blue. And so, the only things that are blue are a link and then everything else is kind of like the typical like black color.
But, this also occurs in a list. So you have in this list I have three list items, the first list item, second list item, and third list item. The second list item is in blue, the first and third are in black, so, the blue is there to indicate it's a link and that's another way we can fail it in the context of a list.
And then finally, "Links in a table." So, I have a 3 by 3 table with different types of pies. So, I have the columns are pie flavor, sale price, and normal price. And then going down the rows, I have different types of pies, I have an apple pie, a pumpkin pie, and a key lime pie; all very delicious pies, but in this chart, they have different prices.
So, the prices that I have underneath the sale price column are all linked and all of the ones that are in the normal price column are not linked. However, they have basically the same visual styling with the exception that the ones that are links are in blue.
So, this is a place where we would want to do something in addition to avoid failing the use of color guideline.
So, what are some things that we can use to make sure we're not using color alone? Some of the things that we can use are going to be text, where we just provide a little bit more information via text; we're a little bit more verbose. We can provide underlines. We can use patterns, shapes, and icons for things like charts and graphs. And we can use the position of content. We can use brightness or luminance; that's a 3 to 1 contrast ratio. And we can use other text styling like bolding, italicizing and changing the size of our text.
Here are some examples. Kind of looking back at the examples we just looked at, but, giving them a little bit more context, a little bit more information to avoid just using color alone. I took that last name error field from before and just added some text into the label. It says, "Please provide a last name." It's probably not the best error message, but it's basically some text showing how we can provide the information that there's an error state that's using more than just a color. Then, the same thing, similarly we have underline for link in a sentence, the link is underlined. We have a sentence where the word, "link," is underlined and it's also blue so we're not just using the color but also using text formating and continuing with that, we can use other types of text formating such as bold, so I have another sentence that says, "The link is emboldened," where the word, "link," is a link. It's blue and in bold making it visually distinct from the non-text content in the sentence. However, if you plan to emphasize content on your site, then you're back to having the same issue.
So, that issue kind of happens with underline, as well. If you're using underlines to distinguish links or if you're using bold to distinguish links, then make sure on the same page in the same contexts, you're not using that styling to mean something else. Because otherwise, you're back where you started and you're back to having color alone being used as the only means of conveying that information.
Then I have charts again. But now I've put some friendly little shapes inside them. Inside of the first bar, there's a square, the second one has a circle, the third one has a triangle. In the legend, the bullet points for the three data points, "lions, tigers, and bears," each correspond to a shape. So now we're using some shapes in addition to the color to associate the content in the bar chart to the content in the legend.
Alright, so, let's take a look at where we're at in the story of this webinar. So, we have completed color alone, andnd of got an idea of how that works. Next we'll look at color contrast, then we'll get to color conflicts.
So, for color contrast we'll ignore the AAA guideline because most people don't use that and we'll only look at the two success criteria at AA level. That will be, "Contrast minimum" or as I'll say. "Text contrast" and then we'll look at the new "Nontext contrast" guideline from WCAG 2.1.
So, for text contrast, this one is fairly straightforward. It applies to text and images of text and any text or images of the text need to have a contrast ratio of at least 4.5 to 1, with some exceptions. So, if we have larger text that can have 3 to 1 contrast, slightly lower contrast requirements. Inactive UI components are exempt from the contrast minimum. Similarly, decorative content, invisible content, incidental text, those are exempt and logos, those are exempt from contrast minimums. And a side note about text contrast is there aren't any contrast maximums defined in WCAG.
This is important to note because for some people dyslexia, reading black text on white, something like a really high contrast can actually cause pain for them. So, if you're looking at the webinar, you can see the text I have it's black but it's kind of like an offblack and then my background isn't white, it's kind of like a creamy kind of offwhite color. So that's there to not have, like, such a stark contrast between the background color and the foreground color. Oh, and another note, don't neglect your image alttext when considering text contrast if your images fail to load on your page. You want to make sure everybody can read the alttext that shows up in place of your images. Yes, you can style alttext. If you're following along at home, you can click through that link and see generally how you would do that.
Alright, so, "Text contrast" clarifications. So, if you have much larger text that doesn't mean you can go below the 3 to 1 contrast ratio. I've had some people ask me that, "What if we make our text bigger? How much lower can we go below the 3 to 1?" Well, under WCAG it doesn't let us really have any avenue for you to do that. It's 3 to 1 no matter how large the text is, even if it's up on a billboard or Megatron, or the Jumbotron, 3 to 1 is the lowest contrast ratio that's allowed in WCAG.
And we have the logo exemption for branding kind of stuff of the logos, but that doesn't really extend to brand colors. So, I learned that lesson when I was, so people who have been working in accessibility or if you have done stuff related to contrast and trying to make the colors work, you'll know the orange, yellow, some of those colors are kind of hard to make work against white or against black.
And so when I was at UT Austin, our Web site, we had, for those who don't know, the colors for UT Austin are burnt orange and white. And so, we had on our Web site, like, all of our links are orange. So that was difficult. Because making the orange, finding an orange that worked was a bit of a challenge but we were able to get it done we were able to get our branding people on board to find an orange that was burnt enough for them or burnt enough for us or not too burnt that it looked brown.
So the exemption doesn't apply to brand colors, just for the logos.
And low contrast is often used as an affordance for disabled content, which means that that's kind of a visual cue to users if something has a low contrast and typically in gray, that's going to mean that the control or the element or that section of content is disabled.
And the last bit of clarification is the success criteria for, "Text contrast" actually says that inactive UI components are exempt from the contrast minimum but really it's equivalent to being disabled in HTML or unavailable for user interaction. So, the differentiation there between inactive and disabled is basically the difference between having, let's say, a submit button at the end of a form that will only become available for the user to use after you've completed the required fields, for instance.
So, I would say that that's disabled because in HTML we would put the keyword disabled on that input, which means it would be unavailable for users to interact with.
However, inactive just means that the user can interact with it, but it's not currently what's active.
So, a good example for that would be if you have a tab list, like a group of tabs, you can switch between the different tabs. So the one that's active is the one that you're on.
But, then all of those tabs you could go to, those are inactive. That's generally the way that I think of the difference between inactive and disabled. In WCAG, they still kind of use inactive and disabled in a similar way. But, just so you know, that's what I mean when I use those two words. And I would say the inactive content, such as the additional tabs you might want to click on, I think those should meet the contrast minimums because how are you going to know which tab you want to go to if you can't read the content?
Alright, so, moving on to non-text contrast. So, this is a newer guideline introduced in WCAG 2.1. And this one basically says that, "UI components and graphical objects that are needed to communicate information or functionality have a contrast ratio of at least 3 to 1."
So, some clarifications on non-text contrast for clarifications...[chuckle]...so, some clarifications on non-text contrasts.
So, if you have text in your UI components and your graphics, those are main texts and are still held to the standards for the text contrast. So, if you have regular text inside of your button, that's going to be, the text self would still need to meet the 4.5 to 1 contrast ratio if it's normal text. And it can be 3 to 1 if it's larger text. And then logos are still exempt if it's a logo in your graphic, it's still going to -- still exempt from the contrast minimums.
Another thing is that non-text contrast does not always require the component boundaries to meet the contrast minimums. It also does not always compare the contrast between the component itself or the graphic itself to the background. So, when we do text contrast we are always comparing the color of the text to the color of the background of that text. So that's not always the case with non-text contrast and we'll look at some examples in just a second.
Lastly, it does not require that different states of the same component need to have a sufficient contrast minimum met unless they are next to each other. And we'll actually go a little bit more into detail into that a little bit later on.
So, when do I check for contrast? Generally, it's...what is required to identify the component and its state. So, if there's information about a control that's needed to tell that it's a component or that it's, like, interactive, or, like, what the state of something is, that's when we want to make sure that we're checking for the contrast. And then to identify the part or parts of the graphic that are important to understand what that graphic is.
Let's just take a look at some examples that are in the guideline itself.
So, I have this in reading view. This is the 1.4.11 non-text contrast.
Here is an example of how I was saying we're not always going to have the boundaries of the interactive controls need to be specified. So, both of these examples would pass assuming the colors meet the contrast minimums. So button here on the left doesn't have a border, it's just a text button. But here on the right side, we have the word button in the center of a button and we have some styling for the border.
In this case the left one would pass because the text button, which is all that's kind of needed to let the user know that this is a button, that this is actionable. That's going to meet the contrast minimum for text 4.5 to 1. And then similarly, on the right side, even if this boundary that's around the word, "button," fails to meet the 3 to 1 contrast ratio, the word, "button," itself could pass because it's 4.5 to 1, so, the entire button wouldn't necessarily have to meet that ratio.
In this next example, they are a little apart. So, we have this name input up here at the top and then we have this name input here at the bottom. And these are both examples of how we're not always comparing the text, we're not always the color of the component with the background. Sometimes, we're going to be comparing the component with itself or some other part of the component with the background.
So this top example, so we have name is in a dark color and then there's a white background behind the entire page, the page background will be white and the input field is a silver gray box boundary around the box.
In this case, the thing we would use to check the contrast for this non-text content is going to be the boundary box or the border and check the contrast of that against the background of the page. We're identifying what this input is.
However, this one down here is pretty much the same thing. The name is in white instead of in black because we have a dark background for the page. But, basically, the box is probably the same silver gray color. But if we compared that gray color to the dark blue background, it probably wouldn't meet the contrast minimum. However, in this case, we can use the inner background of the text input and compare that to the dark background, the dark blue, and it will meet the contrast minimum. It's not always that we'll be comparing the component in its entirety with the background.
Here is another example where we're comparing the contrast of elements within the component itself instead of worrying about the background. So this is a kind of gray check box with the rest of the background of the component is a purple color. So, we're comparing the components of the check box itself, the check box or the checked state. So the check mark. And then the purple background. We're doing a comparison of those two colors, not of the purple and the background how it is on the page.
I'll just look at...let's see. We'll look at two more examples just to kind of give you an idea of some of the principles around this and then we'll move on to the next section which is going to be a lot of fun.
So, this group shows some radio buttons. It's four different radio buttons in different presentation styles. So the first one is not selected it's just a circle with, it has no filling inside of it. The second one is a circle that has, it's selected so all the rest of them are selected, but the first one that's selected has a complete fill within the border that's been specified for it.
The third one is more of a flat design where it's completely filled but the fill is kind of like the same color as the border or it's a fill without a border.
And then the last one has the border of the radio button and then there's a fill inside of it to let you know it's selected but it doesn't fill up the entirety of the radio button, so, there's a little bit of like an inner kind of border. There's like a border and then there's some spacing between the border and the selected area fill.
So in the second and third examples, what we would be doing for checking the contrast is we would check the contrast of the fill in the second example with the background color.
In the third one, the flat design, the only color that we have really is the fill so we compare the fill with the background color. But in the last one, what we would probably do is compare the fill color with the inner background color of the input. So, this gray fill with this little white border kind of in between the border and the fill.
This last example that we're going to look at kind of twisted my brain a bit the first time I looked at it. So there's four different types of star ratings presented. The first two will pass. And the last two will fail.
So, these two at the top, they pass. The bottom two fail.
The rationale behind each of these is pretty straightforward after you look at this a little bit and read it a little bit.
So the first two, well, the first of these star rating examples, it has five stars. You know, possible five stars. But the ranking that's been given is two out of five stars. So, the first two stars are the ones that are filled in, they are completely filled in, they are black. And then the remaining three stars that aren't selected, they have just the outline. So the thing that we're comparing here is, "How do we distinguish between the stars that are in one state versus another?" We're going to compare the contrast of the content, of the fill versus the not filled state for the non-selected stars. And that's going to be a sufficient contrast ratio between this black and then this inner background color.
For the second one, if we look at the same and we kind of compare the same thing we have the same situation, two out of five stars selected.
If we look at the fill of the two stars that are selected and compare it to the fill of the three that aren't selected, that's not going to meet that contrast minimum. That yellow against that white, that's not going to work.
So then how does this pass? Well, if we look at the border, we can see that this has a thicker border than those remaining stars, so, that's how it passes. So, it's not just comparing this one aspect of it. It's looking at the entirety of it and seeing if there's a way that we can distinguish these two stars from these other three stars. In my personal opinion, this isn't really super clear. I guess I'm just not as good as seeing some things are bold and some things aren't when it comes to graphics, but this is sufficient according to WCAG.
And if we look at these latter two examples, they both fail.
The first of them that fail is pretty similar to that last one that worked. So we have the two stars are filled in with yellow. The remaining stars are unselected, have no fill. But in this case, we don't have a thicker border that we can use to delineate. So, actually, yeah, now that I look at it a little closer, so I can see clearly when comparing this one with the one above it, it's like, yes, this one definitely doesn't have this thicker border on these two stars. So the only difference between this and that one is color and the contrast isn't sufficient enough to distinguish them. That said, one of the things that we can use is like brightness or luminance. Which is defined as like a 3 to 1 contrast ratio. So if we were using a different color, then we could potentially have this one work.
So we are using a darker color in the first example where we had the black. So the black against the white.
Okay, so, the Position guidelines, or the position conflicts is basically that...so we have some navigation links up here and we're using positioning to define that these are links. They are separate from the normal content in the page. But, what if we have a more subtle separation for the links at the top. So this, "Learn more on its own line," then we have a paragraph here and then we have, "Learn more here." It is positionally different from this content like, "Learn more..." will always be on its own line at the end of a paragraph. Is that enough position separation to say that nothing else is required. What if, "Learn more..." is more separate? Is that going to be enough? Like we put it further down? We put more space between the text that has a similar treatment and the, "Learn more..." Is that going to be enough? That's a little bug. We don't really have guidance in the guidelines to let us know that.
And continuing on, I've not really seen people talk too much about visited links and unvisited links. Is this a failure of use of color? The new contrast guidelines for non-text contrast says, "There's not a new requirement that visited links contrast with the default color." But does that mean that that wasn't a requirement before? Who knows?
And then also because in that same paragraph it says that the guideline, "doesn't require change of color that differentiated between states of an individual component." That they, "meet the 3 to 1 contrast ratio when they don't appear next to each other."
But does it need to meet the contrast ratio when they do appear next to each other? And if so, how much is next to each other? What's that differentiation?
Then for Disabled Inputs, so this one meets the contrast minimum. This top text input. The bottom one doesn't meet it. But what if the enabled input is just above the contrast minimum, the disabled one is just below, does it fail use of color because they are so close? Just like we have text in a sentence that we need to make sure there's a sufficient contrast between those if we don't want to use an underline. Do we need to do something else similarly for enabled and disabled inputs?
And then similarly, we start getting into switches and we add a lot more states. It's not just enabled or disabled. There's visual difference. They are showing us whether this is on or off. And in the case of switches, the only one that has color is going to be enabled and on. Usually, disabled is going to be gray. And then off will desaturate the colors in the control. So, we have three states that all have different kinds of gray. What parts do we need to differentiate? Both parts of the switch are needed to identify the component is a switch. The big bits on the right, if it's on. The big bits on the left, if it's off.
And the on and off. So, on and off is designated by the position. So, do we need to have a sufficient contrast between enabled on and disabled on to differentiate between those two states? And what about enabled off and disabled off? That's even worse, because, like I said, those are all going to be in gray.
And this is the last bit.
So we're a little bit late but, we should be able to get to this. So this sentence here at the top has a link in it. And this is the classic case that everybody is aware of. When we have that link in this situation, it can pass if it has a 3 to 1 contrast ratio between the link and surrounding text and 4.5 to 1 between the link and the background, so, the linked text needs 4.5 to 1 with its background. The surrounding text needs to have 4.5 to 1 contrast between it and its background and then on hover and focus we need to provide an underline or similar styling and we are used to balancing these issues out; it's a pretty well known issue. But, what if we have a situation like this sentence where it says, "But, what if the entire sentence is a link?"
And we have some color. Does this need to meet, like, do we need to have some kind of...does this fail? It seems like it would technically be correct because color is being used, but there's no surrounding text for the link the entire thing is a link, we're just using multiple colors within this link. And then what if there's no difference in color between the link and the surrounding text? Can it fail the use of color success criterion if there's no actual use of color? I would say technically it fails. Technically it passes. Because there's no color being used. So it can't possibly fail that. But, it just seems like it's a bad idea to do these kinds of things. So I'm not going to go and shame designers or other people who have maybe tried to get away with some of these things. I'm not going to tell you which of them are things that designers have tried getting away with or that are just ideas that have popped into my head. But that's pretty much some of the conflicts that can kind of come up. Sorry I had to rush through that last bit. I promise, I said it much more eloquently the first time.
So, thank you for listening to me rant. Thank you for attending my talk. Any questions?
>> MICHAEL BECK: I did see one pop up in the chat earlier on. Let me get back to it.
So, are buttons address differently when they don't need a border or background to help identify them as buttons or actionable items whereas links and content should be used to help identify them as links by not relying on color alone?
>> LUIS GARCIA: Yes. What's the question?
>> MICHAEL BECK: Are buttons addressed differently that they don't need a border or background?
>> LUIS GARCIA: So, I don't think it's necessarily that buttons and links are treated differently that way. There's this kind of, so, that was another example I was thinking about putting in here. But I didn't feel too confident about it. Like, do we need to have some visual distinction between things that are links and things that are buttons? I would say that in practice they are treated the same way, that the designers are going to treat them like interactive elements. And developers, like, people know that developers are just going to go use links as buttons and use buttons as links. To some developers, they're really like they are interactive things. And not tied to any specific functionality. So, I would like there could be, you know, within a design system for there to be consistency between things that are links and things that are buttons, not between the two, but, a user should be able to differentiate what's a link and what's a button just by looking at it. But,, right now the guideline probably would allow you to have differentiation or it wouldn't really matter so you don't need to make that differentiation.
>> MICHAEL BECK: All righty. And do we have any other questions? Oh, there we go. Non-text contrast. Does the hover state of buttons have to meet the contrast ratios or is the fact that it's in the hover state enough?
>> LUIS GARCIA: I think that they said that they don't really need to, so they would need to on their own. Actually the hover state. Probably the focus state would need to. There is a bit on it. It's one of the newer guidelines. I'm not as intimately familiar with it. But, I would encourage you to take a look at the guideline itself, because I'm sure it mentions it. Let's see. State. So non-text information within controls uses a change of hue alone to convey the state. That's a little different. We can look through this but basically do some reading, search for the word, "state." If a focus state relies on a change of color, changing from one color to another has at least a 3 to 1 ratio there will be some content in here. You'll be able to find your answer in here. I haven't internalized this guideline well enough to give you the answer.
>> MICHAEL BECK: Got ya. So yeah, read through the WCAG guideline. I just put the chat -- the URL for the tweet for the deck in the chat for anybody that wants to take a look at it again.
>> LUIS GARCIA: Cool, awesome.
>> MICHAEL BECK: What is the best link combination for link styling in a content management ystem that allows people to use bold and underline while adding content to the page? Would you have to use color bold and/or underline to avoid conflicts?
>> LUIS GARCIA: Typically, I usually use underlines. So, yeah you can have conflicts with other text that's underlined but since the beginning of the web, underline has been the affordance given to identify links. I would just kind of, like, within the CMS it gets a little bit weird. Because it's like you don't necessarily want to treat every single link and have underlines for every single link. That said if you did have underlines on every single link, some people just think it looks a little bit ugly. If you look at mine, I have these navigation links down here they are underlined. I don't think they look too bad and people know that links are underlined by default the browser is going to underline links. And, you know, often the guidance I give to teams when there's something that needs to be underlined I'm saying, I don't tell them to add an underline to it. I tell them to stop removing the underline from the link that the browser puts on here.
If you get to the case, like, let me show this because I know from memory this is a thing. So, if you go to a footer, oops, it's all the way down here. If you have something like this where you have multiple links right next to each other, the underlines are going to give you affordance of where that link begins and ends. You can't just say it's going to be the word because, "Accessibility," is one word. The link is one word, "User Agreement," that's a two word link, "Privacy," "Cookies," these are all going to, like, the underline is what everybody knows as being a link.
>> MICHAEL BECK: Yeah. A follow-up question to the button answer. I know you said read the guidelines but Michelle would like to ask, "If there's not a border and no background defining the button area, wouldn't it look like..."
>> LUIS GARCIA: It will just look like text that's on the page, yeah. So, it will look like what some people would say, "Oh, that's a link!" It's like, "Well, no, just because it's a text doesn't mean it's a link." Because there could be within a sentence, you might have a flyout for that text to give you a little bit more information about that term. So, if you go to Wikipedia, they now have on there the links they have the little flyout thing that comes up. That doesn't necessarily mean if it was a toggle kind of functionality, then that would be a button, it wouldn't be a link.
>> MICHAEL BECK: Okay. All righty. Our next presentation will be on, what is that first Wednesday in April?
>> LUIS GARCIA: It's going to be the 3rd is the first Wednesday in April.
>> MICHAEL BECK: Yeah, 3rd, first Wednesday in April at 11 a.m. We'll have Shell Little, the mobile Accessibility Lead at Wells Fargo. The title of her talk is, "Dark Adventures in Mobile Accessibility." She's going to talk about why the mobile space is so difficult to work in and give concrete examples of things that would technically pass in WCAG but are really bad experience for users with various disabilities with a focus on cognitive disabilities on mobile.
So thank you, all, again for joining. And thank you to Luis. And I hope to see some of you at CSUN. Stop by the Tenon booth. Karl and I will be there as well as some of the other Tenon family and I'll see you next month. Thanks again.