WEBVTT Kind: captions Language: en-US 00:00:00.080 --> 00:00:05.280 A Web Accessibility Assessment Case Study, Part 2: Visually Inspecting Color Contrast Issues 00:00:05.840 --> 00:00:10.000 Before I do this, I want to emphasize the Deque browser extension does a great job  00:00:10.000 --> 00:00:13.520 of finding most color contrast issues in terms of the color of the   00:00:13.520 --> 00:00:17.360 text against the background, so on some designs the visual check is redundant  00:00:17.360 --> 00:00:20.800 and won't reveal any new issues beyond what the automated test can find,  00:00:20.800 --> 00:00:23.680 but there are three main reasons  to do a visual check anyway. 00:00:23.680 --> 00:00:26.720 The first reason is to look for any temporary or dynamic or   00:00:26.720 --> 00:00:31.040 responsive color contrast issues that the automated check might miss, for example:  00:00:31.040 --> 00:00:33.440 if an alert message is on  the screen for just a moment,  00:00:33.440 --> 00:00:36.000 or if a carousel component  cycles through different items  00:00:36.000 --> 00:00:37.840 across the screen every few seconds,  00:00:37.840 --> 00:00:41.440 the automated test might not be able  to evaluate those fleeting moments. 00:00:41.440 --> 00:00:44.240 Similarly, if you view the design  on different browser widths  00:00:44.240 --> 00:00:47.280 or on different devices, that  can also change the results  00:00:47.280 --> 00:00:49.680 because elements of the design might shift around. 00:00:49.680 --> 00:00:53.280 The second reason is to test the  color contrast of UI components. 00:00:53.280 --> 00:00:57.920 The color contrast algorithm only tests the color contrast of text against the background. 00:00:57.920 --> 00:01:02.240 It does not yet test the contrast between the borders or edges between UI components,  00:01:02.240 --> 00:01:04.800 which became a requirement  starting in version 2.1 of  00:01:04.800 --> 00:01:06.720 the Web Content Accessibility Guidelines. 00:01:07.280 --> 00:01:11.760 The third reason is to check for the color contrast of images, especially icons. 00:01:11.760 --> 00:01:13.840 This is another requirement that was introduced in  00:01:13.840 --> 00:01:18.960 version 2.1 of the guidelines where they refer to the color contrast of graphical objects. 00:01:18.960 --> 00:01:21.840 Think of things like a magnifying  glass for a search feature. 00:01:21.840 --> 00:01:24.240 You need to be able to see  the icon and make sense of it  00:01:24.240 --> 00:01:26.000 especially if there's no text right next to it. 00:01:26.000 --> 00:01:29.680 So for example in a search feature if you have the icon plus the word search  00:01:29.680 --> 00:01:32.880 that's not as big of a problem as if you have only the icon. 00:01:32.880 --> 00:01:35.360 And if that icon is low contrast it would be difficult for   00:01:35.360 --> 00:01:38.400 people with low contrast vision to be able to make sense of it. 00:01:38.400 --> 00:01:40.800 Let's start with some common sense observations. 00:01:40.800 --> 00:01:43.120 The logo in the left corner is a medium purple  00:01:43.120 --> 00:01:45.680 against a somewhat dark  area of a background image. 00:01:45.680 --> 00:01:47.360 It already looks somewhat problematic  00:01:47.360 --> 00:01:49.760 though we'd have to test  the exact color combination. 00:01:49.760 --> 00:01:52.080 But I first want to see what  happens when we scroll down. 00:01:52.640 --> 00:01:53.280 Okay good. 00:01:53.280 --> 00:01:56.080 When I scroll down the color  contrast actually improves  00:01:56.080 --> 00:01:58.480 because a white banner appears  as the background color  00:01:58.480 --> 00:02:00.400 obscuring the variable image behind it. 00:02:00.400 --> 00:02:02.640 But what happens if I zoom out or zoom in? 00:02:02.640 --> 00:02:05.520 I've got a relatively small screen here, so I have to zoom out to   00:02:05.520 --> 00:02:08.960 simulate how it would appear on a larger screen with the browser maximized. 00:02:08.960 --> 00:02:10.320 Ah now that's a problem. 00:02:10.320 --> 00:02:12.560 When I zoom out, the location of the logo changes  00:02:12.560 --> 00:02:16.400 and now the color blends in with the background making it almost completely unreadable. 00:02:16.400 --> 00:02:21.680 I will point out that the guidelines do allow color contrast exceptions for logos and logotypes,  00:02:21.680 --> 00:02:25.520 but this is a rather extreme example of not being able to read it hardly at all,  00:02:25.520 --> 00:02:28.480 even with perfect vision, so it's still a problem. 00:02:28.480 --> 00:02:31.120 Zooming in doesn't introduce  any new color contrast issues,  00:02:31.120 --> 00:02:32.960 though there is a problem with overlapping layers  00:02:32.960 --> 00:02:35.920 at one of the resolutions and we would want to fix that. 00:02:35.920 --> 00:02:40.240 The links in the upper right area of the banner have white or light gray text and borders  00:02:40.240 --> 00:02:42.800 against the variable background  image that we saw before. 00:02:42.800 --> 00:02:45.600 I'd have to run the automated test to know if this is problematic or not. 00:02:46.160 --> 00:02:47.920 Oh but when I scroll down,  00:02:47.920 --> 00:02:51.760 there's a point at which the banner turns gray before it turns completely white,  00:02:51.760 --> 00:02:55.520 and because the text is also gray at this point, it is very difficult to read. 00:02:55.520 --> 00:02:58.320 That's very definitely a color contrast violation. 00:02:58.320 --> 00:03:02.240 If you scroll further, the white bar appears and the color contrast of the text looks good  00:03:02.240 --> 00:03:05.520 so the text passes in that state, though the contrast of the border   00:03:05.520 --> 00:03:08.960 almost completely disappears, so the UI color contrast fails. 00:03:09.760 --> 00:03:13.520 Now that i've seen the color contrast problem during the transition state when scrolling,  00:03:13.520 --> 00:03:16.080 I'm realizing that I need to  go back and recheck the logo. 00:03:16.720 --> 00:03:19.920 Yep, sure enough, I scrolled  too quickly during my first test  00:03:19.920 --> 00:03:21.520 and I overlooked the transition state. 00:03:21.520 --> 00:03:24.880 When the banner is gray, the purple text is barely visible in this state,  00:03:24.880 --> 00:03:28.880 which just goes to show how important it is to do the manual tests in the first place. 00:03:28.880 --> 00:03:30.400 Moving on to the middle of the page  00:03:30.400 --> 00:03:33.360 there's white text against that  same variable background image. 00:03:33.360 --> 00:03:34.960 Some parts of that text may pass,  00:03:34.960 --> 00:03:37.280 but it's pretty obvious that  some parts of it will fail,  00:03:37.280 --> 00:03:41.440 so we already know that this is a problem even without zooming in or scrolling below that. 00:03:41.440 --> 00:03:44.160 There are several light gray  logos against a white background. 00:03:44.160 --> 00:03:46.480 Because those are logos,  we may be able to say that  00:03:46.480 --> 00:03:49.040 they can slip through the loophole that the Web Content Accessibility   00:03:49.040 --> 00:03:52.960 Guidelines provided for logos, but still the contrast is so low  00:03:52.960 --> 00:03:56.320 that it would be worth reporting them so they could be darkened enough to at least pass. 00:03:56.880 --> 00:04:00.320 I can also see that this page  uses light gray placeholder text  00:04:00.320 --> 00:04:03.520 in the "from" and "to" fields  of the form as visual labels. 00:04:03.520 --> 00:04:08.000 The browser default color of placeholder text always fails the color contrast threshold. 00:04:08.000 --> 00:04:10.960 That's just the way the browsers have defined placeholder text styles. 00:04:10.960 --> 00:04:14.320 You can use CSS to style the  placeholder text to be darker  00:04:14.320 --> 00:04:16.720 or, even better, you can just use a real label  00:04:16.720 --> 00:04:19.840 outside of the input itself,  instead of the placeholder text. 00:04:19.840 --> 00:04:22.320 Native browser placeholder  text has the additional problem  00:04:22.320 --> 00:04:24.880 that it disappears as soon as  you start typing something,  00:04:24.880 --> 00:04:26.480 leaving no visible label at all. 00:04:26.480 --> 00:04:29.520 If I type values in both fields then I switch their place,  00:04:29.520 --> 00:04:33.120 how do I know which field is the "from" field and which field is the "to" field anymore? 00:04:33.120 --> 00:04:35.680 There's no visual way to keep  track of that information,  00:04:35.680 --> 00:04:37.760 especially if I keep switching back and forth. 00:04:37.760 --> 00:04:39.680 So these inputs are an accessibility failure,  00:04:39.680 --> 00:04:43.760 not just for color contrast, but also for the need for persistent visual labels. 00:04:44.400 --> 00:04:47.840 Let's look at some other user interface components on this particular page. 00:04:47.840 --> 00:04:51.520 We can see that we have a light gray outline around some of the text inputs,  00:04:51.520 --> 00:04:53.680 and those are probably going to be problematic. 00:04:53.680 --> 00:04:55.680 One way to analyze them is to select the color   00:04:55.680 --> 00:04:58.480 with the eyedropper utility in the Chrome developer tools. 00:04:58.480 --> 00:05:02.160 Before using the eyedropper selector, I recommend zooming in on the page  00:05:02.160 --> 00:05:05.200 to make it easier to see and  select the colors accurately. 00:05:05.200 --> 00:05:08.960 With the developer tools inspector open find any element that has a color  00:05:08.960 --> 00:05:12.080 defined in the CSS panel and click on the colored box --  00:05:12.080 --> 00:05:15.280 which is a sample of that color -- and that brings up the color tool. 00:05:15.280 --> 00:05:18.640 Within that tool, make sure the eyedropper color selector is activated,  00:05:18.640 --> 00:05:20.880 then click on the element  that you want to analyze. 00:05:20.880 --> 00:05:22.960 The light gray that we have here is DADADA. 00:05:24.400 --> 00:05:28.160 I'm going to plug that value into  the Deque color contrast analyzer.  00:05:28.160 --> 00:05:32.880 at Dequeuniversity.com/color-contrast to find out if it passes. 00:05:32.880 --> 00:05:35.200 I'll paste in the light gray  as the foreground color,  00:05:35.200 --> 00:05:36.960 and I'll set the background color to white. 00:05:37.520 --> 00:05:40.160 As I suspected, this color combination fails. 00:05:40.160 --> 00:05:41.920 Another way that we could have found the color  00:05:41.920 --> 00:05:45.120 would be to get the exact value from the styles themselves. 00:05:45.120 --> 00:05:48.000 To do this, you need to use the inspector and find the element,  00:05:48.000 --> 00:05:50.720 and if you're lucky you'll have the color definition easy to find. 00:05:50.720 --> 00:05:51.840 In this case we do,  00:05:51.840 --> 00:05:55.200 and it shows up as the same value that we saw before DADADA,  00:05:55.200 --> 00:05:57.920 so there's no correction that we need to make to our original test. 00:05:57.920 --> 00:06:00.800 But if this had been a different value we could just copy the value from here  00:06:00.800 --> 00:06:04.160 and put it in the color contrast analyzer to find out if it passes. 00:06:04.160 --> 00:06:06.560 Let's move on and test some other components. 00:06:06.560 --> 00:06:09.920 If we expand the region labeled  as "show all passenger types,"  00:06:09.920 --> 00:06:12.080 we see that there are some buttons in a disabled state  00:06:12.080 --> 00:06:14.880 that are extremely light gray  against a white background. 00:06:14.880 --> 00:06:19.040 You might be tempted to call that a failure because, in fact it's true that the color contrast  00:06:19.040 --> 00:06:20.240 is way below the threshold,  00:06:20.240 --> 00:06:23.520 but disabled controls are exempt  from the color contrast requirement. 00:06:23.520 --> 00:06:26.240 They get a pass, so there's  nothing to report here. 00:06:26.240 --> 00:06:30.080 We do see other instances of light gray text being used as visual labels. 00:06:30.080 --> 00:06:32.400 We see it in the search field of this dialog,  00:06:32.400 --> 00:06:34.960 and if we go over to the drop down menu we see it here. 00:06:35.520 --> 00:06:38.480 All of those will need to be fixed for both color contrast and  00:06:38.480 --> 00:06:42.480 to ensure that the label is always visible, always visually persistent. 00:06:42.480 --> 00:06:45.520 The last thing that I'll look at in this demo is the use of icons. 00:06:45.520 --> 00:06:49.520 There are some obvious color contrast issues with the white icons against the light areas  00:06:49.520 --> 00:06:50.960 of the main background image. 00:06:50.960 --> 00:06:52.000 I've already talked about that  00:06:52.000 --> 00:06:55.200 in terms of the contrast of the  text against that background image,  00:06:55.200 --> 00:06:58.880 and we have to look at the color contrast of icons against the background in the same way. 00:06:58.880 --> 00:07:00.880 Looking around at some of  the other icons on the page  00:07:00.880 --> 00:07:02.880 we see that there's a field switcher icon,  00:07:02.880 --> 00:07:05.200 and there's the icon used  to open up the date picker,  00:07:05.200 --> 00:07:09.840 and the plus, and the minus icons, and  the search icon in the drop down menu,  00:07:09.840 --> 00:07:13.280 and it turns out that all of those look like they have pretty good color contrast. 00:07:13.280 --> 00:07:16.000 We could analyze all those values -- the color of the foreground   00:07:16.000 --> 00:07:19.040 against the background -- just to be sure, but they're looking pretty good. 00:07:19.040 --> 00:07:21.680 I'll still want to run the analysis  in the Deque browser extension  00:07:21.680 --> 00:07:23.760 to find any other color contrast issues,  00:07:23.760 --> 00:07:26.240 and I'll show that process  in part 3 of this case study,  00:07:26.240 --> 00:07:29.520 but this first visual pass is  important for finding edge cases  00:07:29.520 --> 00:07:32.960 and simply as a common sense reality check before running the automated checks. 00:07:32.960 --> 00:07:35.680 That's especially true when it  comes to temporary, dynamic,  00:07:35.680 --> 00:07:40.240 or responsive content or UI  components or images including icons.