 Okay, so, sorry for that brief delay, as you have mentioned, I'm from Toronto, and I've been to work with the RICG since about October 2012. The RICG is the Responsive Images Community Group, or it used to be, now it's the Responsive Issues Community Group, because we are expanding our horizons. But I'm going to talk about images and HTML, even though this is a CSS conference, so hopefully you get something useful out of it. I want to talk about performance on the web, and what we can do to improve performance and why it's important. So, the first thing I want to talk about is this anecdote from Chris Zacharias, who wrote this post called Page Weight Matters. Back in 2009, he was at, oh, there we go, he was at YouTube, and he noticed that the page weight on the video viewer page was really high. It was about 1.2 megs, and there was like a billion requests, and it was a performance issue, so he created this project that he called Feather, which was designed to reduce the page weight to under 100K, once you take out the video, obviously, and reduce the number of requests. So he did this, and what he found was this really perplexing result, which was that the page load time, the average load time of the page went way up instead of way down, which is super counterintuitive. And then he realized, or somebody there realized that if you take geography into account, you can explain the difference. So what was happening is that regions with slow internet that before previously could not load the page at all were now able to. So people who were never able to access the videos could finally do it, and even with this low page weight, it was taking them two minutes to load the page, but before it would have taken over 20, so they just never bothered. So just by improving performance, they were able to open up their market to this whole new audience, which I think is really powerful, and when you frame it in terms of making your stuff available to new users, it can be a little more interesting than just looking at stats about bounce rate and stuff like that, although those are interesting too. So this is a quote from Brad Frost, that good performance is good design, and that's just something I want to have us keep in mind as I go through this and talk about performance. So if we care about performance, which hopefully you do now after that super brief intro, why talk about images? What's the deal with images? They've been around for 22 years with the exact same image tag in HTML, no change. So why bother changing them now? What's going on? This is data from HTTP archive from June 1st about the average web page size. I don't know if you can read that, but the total average web page size is over two megabytes now, and 1.3 megabytes of that or about two thirds comes from images. We have a lot of images, and they're very heavy. And this is getting worse constantly, so this is also data from HTTP archive. The blue line is the average size in kilobytes of images on a page, and the red line at the top is the average number of image requests. So, oh, and it's from, I think, 2010, November 2010 until June 1st this year. So as you can see, the number of requests has stayed pretty much the same, averaging about 50, low 50s, mid 50s per page, which seems like a lot to me, but whatever. But the average byte size for those images is just constantly growing, and it's what's causing this. Like, we have this huge, these huge pages with these giant images that are performing really badly. But who cares? At the same time that we have this increasing page weight, we have this big explosion in mobile online. People using cell phones to access the Internet often in places with terrible connections. So that's outside the U.S. If your market's inside the U.S., who cares? Same thing can happen here. Like, once you get outside of a metropolitan city or metropolitan center, connection speeds can be bad. Connection speeds or connections can drop in and out. It can be really frustrating. Even in the city, I'm from Toronto. It's a pretty big city. We've got like 4G, wireless, whatever. If I'm on the subway and I have just like a split second to connect to a site, if it's going to load really slowly, I'm not going to get anything, or maybe I'll get like a few bytes and I don't get the content that I need. So performance really matters for everybody. This is some data from Pew Research that's from 2014. 64% of Americans used the phone to access the Internet. And not on this slide, but from 2013 they released data that said 34% of Americans use the mobile device as their primary way to access the web or their only way to access the web. So we really need to care about mobile and what's happening with performance on mobile. And although mobile is a convenient category, it's not a single target, right? This is an illustration from OpenSignal about Android fragmentation showing over 18,000 Android devices that had been released as of August 2014. So not taking into account iOS or BlackBerry or any of that other stuff, just Android. So we're in a situation where we're serving these giant images to everybody regardless of what device they are, what screen size, what they're viewing context. We're not taking any of that into account. And we had a good reason to do that. Anybody here that is a designer or even that isn't a designer wants their site to look good and wants images to look nice? And our problem is that in order to do that we have to serve these big images. Back when Ethan Marcotte first started talking about responsive design, this is the way he recommended serving images. And it makes a lot of sense. I'm sure you've all done this. You take an image, you throw a big image at the browser and let it scale it down, keep the aspect ratio intact everything and it looks really great. If you have a big enough source image it's going to work no matter what the screen size is. It's going to work no matter what the layout is. And it's going to work no matter what the pixel density is or DPR, device pixel resolution. I'll probably throw that term around so I should define it. So that was one solution to this problem of wanting stuff to look good everywhere. As long as we serve an image that's big enough and let the browser worry about it, the images will look great in any context. But then stuff like this came along. This is a retina iMac. This thing has, I don't know the full resolution but the horizontal resolution is 5120 pixels. That's a lot of pixels. So if I'm a restaurant say, and I'm building a restaurant website, as a restaurant I love putting huge giant pictures of salad on my site because nobody knows what a salad looks like. So I'll just take a 5120 pixel wide photo of a salad and put it up there and it's going to look great for everybody, right? Max width 100%. Cool. But then you get users like this. So I took this screenshot in Paris which is a big metropolitan center and you might expect to have great internet. But it didn't. I kept seeing this everywhere I went, this E, this edge connection, it was horrible. So I was in Paris with my wife for our anniversary and we wanted to find a nice place to eat and every single restaurant website we went to wouldn't load because of these giant eight megabyte photos of salad. So this is like a real situation where these restaurants, these businesses were losing out on our business, on our money because of a slow non-performance website. And in addition to you as a site owner losing money, your users are going to lose money too. So this is a website that a guy named Tim Cadillac built called whatdoesmysitecost.com. It's really cool. You can throw in a URL and it'll calculate for a given region based on what data rates are there, how much it costs to load that page. I threw in vogue.com because I was feeling fashionable and it came up as almost eight megabytes. And you can see in these different countries how much it cost. So in US dollars in Vanuatu, just to load the vogue home page, it cost over $2.50. One page load. That is insane to me. So that's a really cool tool to help you figure that stuff out if you have a heavy page. And this is the kind of thing we all have real experiences with or many of us have real experiences with where we might have a data cap and if every page is two megabytes, it's really easy to go over that data cap and start spending real money just to load web pages. So those are all file size issues with huge images but there's other issues too that I won't get into in too much detail. But a bigger image means you're going to use more battery life. It means you're going to use more time to decode the image for the browser to decode it. You're going to use more memory which means you have fewer apps open at the same time. So it's a real problem. So in addition to just wanting images to look good everywhere, which is, it's legit, we have this harder problem that we want images to look good everywhere but also not to just kill our users. We want them to still have a good user experience. So that's where responsive images come in. So this was our solution before for our initial problem. Serve one big image and let the browser scale it. This is a better solution that can hopefully help us solve the other problem. Serve an appropriate image to each user. And this goes in line with this whole philosophy of responsive design as a whole, right? So serving an appropriate look and feel to every user. Now we'll serve an appropriate image to every user. And so let's define what appropriate means. There's going to be a bunch of use cases that I want to look at. So the first three are ones I talked about. Different screen sizes, different layouts, different DPR, pixel density. Another one is image type, MIME type, or file type. So some browsers, Chrome and Opera, for example, support WebP, which is an image format that, at the same subjective quality, will have much smaller file sizes than JPEGs. So if a browser supports WebP, it makes a lot of sense to want to serve a WebP to that browser because you're cutting down on the number of bytes, saving memory, all that stuff. And then the last use case is called art direction. So what art direction is, is basically serving a different image based on layout or based on some condition. So in this example, this is Obama's dog, Beau sitting in front of the White House. On the desktop we have a lot of room, a lot of visual space, so it's okay to show some of the background. But then on some of these other devices, since Beau is the focus, we crop out some of that extra information and get like progressively more zoomed in on Beau. That's what I'll be talking about in terms of art direction. So I know this is a CSS conference but, and you know, this may be a kind of controversial statement to make, but using CSS to solve this problem is a bad idea. Why is that? It seems like a good fit. We have media queries, we can do a lot of this stuff if we throw images into like CSS background image or whatever. There's a few reasons why it's a bad idea. The first is there's this thing called the preloader, which has been called the single biggest improvement ever made to browser performance. So it's not the kind of thing we want to ignore. What it does is it'll be, when the browser loads a page and it gets to a blocking resource, say like a JavaScript, it'll start up the preloader and like go through the rest of the page to look for resources to find, such as images. And it really speeds up the rendering of pages. If we put stuff in CSS, if we do all our images as background images in CSS, those don't get picked up by the preloader. So we have a huge performance disadvantage right out of the gate. CSS background images are also meant for styling, for decorative purposes, not for content images. And what I'm really talking about here are content images. So you can't have alt text for a CSS background image. So if the image doesn't load, or if you're dealing with a user who can't see the image, they don't get that alternative information. They can't consume it in the same way. Also this, I'm not going to stand by this statement, but I believe CSS background images aren't picked up by search engines either, like Google image search. I'm not going to guarantee that's still the case, but they're at least treated differently. So if you care a lot about SEO and you want your images to get picked up by search engines, that's another reason why doing this in CSS is a bad idea. But the first one, the preloader thing, is really like the clincher. It's why we don't want to do that. For the same reason JavaScript's a bad idea. It completely negates the benefits you get with the preloader. And it also will fail in context where JavaScript isn't available. So if a user has JavaScript turned off, search is not all that common, but more common if something breaks on the page, like a browser plug-in breaks all your JavaScript, or there's conflicting stuff from an ad network or something like that, which can happen. So JavaScript's not a great idea either. So a bunch of smart people realized all this and decided we should come up with a markup solution, build this into our HTML, and they came up with this responsive images specification. URLs here, I'm going to go through the markup, but I recommend you take a look at it. It's fairly comprehensible as far as standards go. It is still a standard and kind of not written for the average developer, but it's not bad. So let's talk about markup. So the first thing I want to talk about is resolution switching. So providing different images in the context where users have screens of different resolutions. So this might be something like delivering a different image to an iPhone 3 than an iPhone 6, which has a retina screen. It's more dense pixels. So this is an image element. You start with a source and an alt, and that's what we've been using for 20 years. And this is how you would do it as a responsive image. So you start with your basic image stuff, your same attributes as before, your source and your alt. But now you have this new attribute called source set. And what it is is a comma separated list of different image files that the browser can choose from. And beside each one, you give this X descriptor it's called, where you say what density, what pixel density it's targeting. So in this example, wolf600.jpg would be served to most people with like a normal one X display. So most laptops, some older phones, a 2X display would get this wolf 1200.jpg which would still display at the same size as wolf600.jpg but it would be like less blurry because it's a high resolution image. And then if you want to get crazy and future proof, there's phones out there that are coming out with 3X, 4X resolutions, you could start doing that. And there's some older devices that have sub 1X resolution so you can even provide like a .5X if you want. One thing that's important to remember with source set is that these are suggestions you're making to the browser. You're saying I've created these files, I think that they should be used in this context, but it's up to the browser to determine which one to pick. And I'll come back to that a little bit later. So now that you have all this responsive junk in here, you could probably change your source so you're not serving the big giant 4800 pixel version to everybody. And in older browsers that don't support source set, they can just get this kind of like middle of the road of 1X600.jpg. So you end up with this situation where browsers that support responsive images get to choose what's most appropriate based on the user's viewing context, and browsers that don't will just fall back to the old source attribute and display that. So let's talk about viewport switching or switching which image you're delivering based on the size of the viewport or size of the window. Again, you start with a normal image element, and now we have some new things. So same source and alt, but now there's this new attribute called sizes. And what sizes is it's a description to the browser about how big the image should display on screen. So the browser is getting this information in the HTML before any of the CSS is downloaded or parsed or anything like that. So it doesn't know what the layout is. It doesn't know if you've sold, if you said in CSS that the image should be 50 pixels wide or whatever. And it hasn't downloaded the image yet, so it doesn't know what the actual dimensions of the image are. So sizes gives it a hint saying, I'm going to display the image at this size. Are you guys familiar with VW units? Is everybody here okay with that? Yeah, okay. So if anybody's not sure about a VW unit, it stands for viewport width and it's basically 100% the width of viewport or the window regardless of what the parent element is. So in this situation I'm saying that this image element is going to display 100% the width of the viewport. And then we give it a source set, but this time instead of an X descriptor it's a W descriptor. So it's still a comma separated list of files but now I'm telling it how big each of these images is. So wolf 300.jpg is 300 pixels wide. Wolf 600.jpg is 600 pixels wide. So the browser now knows how big the image is supposed to display and how big the images in the list are and it knows which one is the most appropriate to choose. If I'm on a 600 pixel wide phone, then the browser might choose the 600 pixel .jpg because I'm displaying it at 100 VW and that's a good choice. The other thing is the browser can now take pixel density at the density of the screen into account too. So it knows that information, it knows that if I'm on a 600 pixel wide display with a 2X resolution, it doesn't make sense to download wolf 600.jpg, it makes sense to download wolf 1200.jpg so it's going to do all that math for you. If you have a display with a 1.387 whatever X display, the browser can do all that and choose the best element to display. Those are the same slides. So sizes can be used almost to any CSS length unit. So you can say 100 VW or you can say 600 pixels or you can even throw calc in there and say well it's 100% the width of the viewport but it's got some padding on the side so we'll subtract and the browser will figure that out for you and still pick the best one. The only thing you can't put in there is a percentage because then it gets confusing about what that percentage is referring to since the browser doesn't really have that information and layout might change and stuff like that. So percentage is off limits but anything else you can put in there. Yeah, do you have a question? Yes, so I will get to that presently. So that's all well and good if you have one image in like a static layout that's not changing but we have responsive images or sorry responsive layouts a lot of the time. So in this case with the desktop the image is going to display about 33% the width of the viewport. On this tablet about 50% the width of the viewport and on the phone about 100% the width. So you can do stuff like this, you can throw media conditions in there. You can say that at a minimum width of 1000 pixels I wanted to display at 33 VW, at a minimum width of 600 pixels, 50 otherwise 100. And then the browser in each of those contexts as things change is going to pick the best one for you. And again because this is a source set it's up to the browser to make that choice. You're just giving it recommendations and giving it some information but it will make the final decision. Okay, let's talk about file type switching. Normal image. Now we start seeing the picture elements in this new element that was introduced as part of the spec. So the way picture works is you have an image as a child of the picture. The image element has to be there. It's mandatory. If you don't have that everything's going to break. It's doing the heavy lifting. So picture as a parent of image and then we have these source attributes or sorry these source elements and this will look familiar to you if you've ever done HTML5 video or audio where you have like a parent element and then some sources for the browser to choose from. The way source works here is we give it a type attribute with the image's MIME type and then source set where we can throw in a list of files. So you can still do W and X selectors within source set here. You can combine it with the type if you want. But the important thing is the browser's going to go through the list of sources and choose the first type that it can support. So here we say if it's a WebP display 4800.WebP otherwise it will fall back to this image and display the JPEG. You can add in multiple sources and say well if you support WebP show this. If you support JPEG XR which is supported in Internet Explorer and also has better performance than normal JPEGs then display that. Otherwise fall back to the normal JPEG. So in this way we can provide different options based on what formats the browser supports. The thing that's different with source from source set is that this is not a hint to the browser. It's an imperative. You're saying display the first one that you support full stop. The browser has no say in what to do. If it supports WebP it's definitely going to display that first one. And then the last use case is art direction. So all my examples so far have had the alt text to RadWolf. This is the RadWolf. This is PartyGod from Adventure Time which is a very good show. So if we have PartyGod and we want to display this image of PartyGod in this example on the left you get a pretty good view of him. You can see what's up. But on the tablet and on the phone PartyGod is like really shrunk down in the corner and you can't really see what's going on. So we probably want to do some art direction and do something like this instead where we get closer crops. So you can see the main focus of the image. So you do that. Again you start with a normal image and we have the picture element again. So we have the image as the child, picture as the parent and source elements again. Now instead of the type attribute we have this media attribute where you can again put in a media condition and a source set with a list of files potentially where the browser will again choose the very first one that matches. So because these are source elements this is not just a recommendation. It's an imperative telling the browser definitely show the first one that matches. If you have a minimum width of 1,000 picks you're going to show WolfCrop big. If you have a minimum width of 600 picks you'll show WolfCrop small and then otherwise you'll fall back to just the normal JPEG. So by doing this we can match these up with the media queries we have in our responsive layouts for CSS and get different art direction depending on what layout is being displayed to the user at a given point in time. So that's actually it for markup. For the basics. You can combine all these things. It gets a little bit hairy. So you could do something like this. This is basically the reason why responsive images got a bad rap at first because this is horrible. Nobody in their right mind wants to do anything like this. It's terrible. This is combining art direction and file type switching and viewport and resolution switching and all of this is just to display one image on screen. So it's got awful and I don't recommend you do this. But the nice thing is if you ever get yourself into a situation where you need that type of fine grain control you can do this. You're probably going to have a bad day but you can get it done. Most of the time this is what your responsive images are going to look like. Most of the time you don't need to do file type switching. The differences between a webp and a JPEG are going to be fairly small. Most of the time you don't need to do art direction. That's like a sort of unusual use case. It happens but you don't need it. So you'll have an image. You'll have source set with a W because then it'll handle resolution and the size of the viewport and you throw some of your media conditions and sizes and that's going to cover you like 90% of the time. So it's not too terrible in my opinion. It's still a little heavier than a plain image but you get very powerful performance benefits out of it. So I personally think it's worth your time. So that's the responsive image specification link again and I will post these online by the way. As I said that was just sort of the basic syntax. So if you want to get into more weird bizarre use cases there's this great article that just came out this week called When Responsive Images Get Ugly by Taylor Hunt and he talks about things like how displaying an animated GIF on an e-ink display might not be a great idea because of refresh rates and stuff so what to do in situations like that and gets into sort of like more real practical edge cases which are very interesting. So I recommend this article a lot. So the specs out and you can use this now there's actually support in browsers which is exciting because most of the time when I give this talk that's not the case. So in Firefox as of version 38 you can use source set and sizes and picture in Chrome and Opera as of Chrome 34 and 21 source set and sizes and as of Chrome 38 and Opera 25 you can use picture. Opera is lagging behind a little bit. You can use a subset of the source set syntax so you can use the X descriptors but it doesn't support the W descriptors yet and picture is still in development. For Internet Explorer or Edge as it will soon be known source set and sizes are in development they're working on getting it working and picture is under consideration so as Leo was mentioning you can go and vote for it if you think you want it implemented. I kind of think they're going to implement it like based on some of the talk and questions that are being asked I think it's going to happen but they haven't officially announced support yet. So for those browsers that don't support it yet older browsers there's a polyfill called picture fill that's by Scott Jell some others at the filament group and then other people have come in to contribute quite a lot and it's really great. You can use the exact markup as defined in the specification and picture fill will handle everything and just make it work. I highly recommend it if you need a polyfill but you might not. You might decide it's not worth it for you and your users so to help you sort of like make that decision whether the polyfill is worthwhile Scott wrote this article to picture fill or not to picture fill which is a good read and can help you sort of make that decision. So real talk time, responsive images are kind of a pain because of stuff like this you have to actually export all these images. If I give the browser a choice between 10 different images to download that means I have to create those 10 different images and that kind of stinks. So I created this tool. If any of you use grunt you can build this into your workflow. What it does is you can pass it one large image it'll resize it for you to any dimensions you ask it to. It'll run it through image optimizers which again I'll talk about soon to make the file size a lot smaller. If you have an SVG it'll rasterize the SVG to ping so that you can throw it in for older browsers that don't support SVG and I actually don't remember if I pushed this live yet but I've been working on a feature that will rasterize PDFs as well so if you want to generate thumbnails for PDFs it'll do that for you too. If grunt is not your thing I have a PHP version that you can incorporate into say CMS or something that you're doing it works more or less the same it doesn't have quite as many features as the grunt one but it can still do your image resizing and optimization for you. And then I didn't build this one and actually I haven't even tried it yet but I've heard it's very good. It's another grunt plugin called responsive images extender and this will actually generate the responsive image HTML for you. So if you just have a normal image tag and you tell it what you want to do it'll go and replace your HTML and make your life a lot easier. And if you work in WordPress at all the RICG has been working with some people at WordPress to build this responsive images plugin which again handles a lot of this stuff for you. You don't have to change anything in your markup you just have an image and this will go in and replace everything and do all the resizing for you. So it's pretty nice. So that's responsive images but in the title I said I also wanted to talk about responsible images. So what do I mean by that? Responsive images are a part of that. It's a huge help for performance. But there's also some other things you can do like image optimization which I mentioned a second ago. So image optimization is when you basically run your image through a program that will make it smaller without hurting the quality. It'll losslessly optimize it. So it might do things like strip metadata or change the encoding or something like that. But it can have a huge effect on the size of your images. It can really cut down the file size. There's a bunch of different tools out there that do it. These are some that I like. So image optim and image optim are not the same despite the very similar names. Somebody's got to get on the PR there. Figure it out. So the first one image optim with a big I and big O is a GUI for the Mac. It works really well. If you run a lot of images through it, it'll make your fan spin up like crazy and you can like heat your house with it. But it works really well. Image optim with the underscore and no caps is a command line thing that works on Linux and Mac and I think Windows but don't quote me on that that does basically the same thing. But you can call it from the command line. SVGO GUI again is a GUI that you can use to optimize SVGs and then SVGO is a command line version of the same thing. So depending on what your needs are, GUI or command line, if you want to integrate it into a workflow you can choose whichever one makes the most sense for you. For SVGs you may also want to do something like this if you use Apache which is make sure you serve your SVGs with GZip. It'll make them faster. It's pretty good. It doesn't really take a lot of effort. You can throw this in an HTML access file. You can throw this in your Apache config if you use something like nginx or something else there's ways to do it with that too but a lot of people are on Apache so I put that up. The next thing I want to mention is deferred image loading or lazy loading. So this is the eBay homepage and this is what's above the fold when you go on my laptop so there's a few images here whatever. This is the whole page that's a lot of images. I'm sure you can't really tell what's going on here because it's really really long and there's like a bazillion images but most of the time people are just going to see this. They're going to come in, they're going to do a search or they'll click on one of these calls to action or whatever and not need to see any of these so what eBay does and what's a good idea for a lot of people is to do what's called lazy loading to wait until the user scrolls to a certain point before loading the images so that the user that's just viewing this doesn't have to load all these but as they scroll they can start filling in these gaps. That's going to be a great way to cut down on bandwidth and wasted bytes. So there's a lot of great scripts out there. If you just google lazy loading you'll find a million things. This is a really great one called lazy sizes that works with all the responsive image syntax I just talked about. It's by a guy Alexander Farkas who's been doing a lot of work with the RICG and I highly recommend this. Another thing you can do is to use a CDN and do appropriate caching. CDNs are a huge topic but if you have access to one you recommend using it it's going to help things get delivered more quickly and it'll help with caching and if you have control over your own caching you can look at what makes sense for your user so if there's an image that's not going to change for a very long time like say your logo you can set a really long expires on the cache for that image or for some types of images and then users won't have to keep downloading it once a week or whatever. They can just have it stored in their browser cache and have access to it very quickly. So these are all performance things, these four that I just talked about because it's something I care about a lot and because you've given me a platform I also want to talk about accessibility with images. So if you're looking at image stuff anyway it's a good time to take a look at accessibility and see what you're doing and if you can improve things. So one thing you can do is look at appropriate color contrast and make sure images work well for people with color blindness. So let's talk about contrast. This is an example of terrible contrast where it's a pie chart and it's got different shades of gray and it's really difficult to see where those distinctions are. So if somebody has low vision or if this was being projected instead of displayed on a nice monitor you would lose a lot of that information and it would basically be useless to people. Even if you can see the distinction between these different wedges figuring out which of these grays, maps to which the grays in the legend is going to be very difficult for anybody even with great vision. So this is an extreme example but this kind of thing happens all the time where low contrast will really affect how your image is interpreted if it can be well. And then in terms of color blindness this pie chart has better contrast. It's easier to see the difference between the wedges but somebody who's color blind like myself will have a hard time maybe distinguishing the wedge colors and definitely mapping the wedge colors to the legend. So I'm going to do a bit of an experiment here. I have on the next slide a version that's supposed to be what color blind people see as. To me this slide and the next slide look identical so I have to trust other people that there's actually a difference here but hopefully you can tell me if you see a difference. So here we go. Different? Yes? Is this harder for you to match the colors? Do you think? Yeah? Yes? Either way it's important to just remember that not everybody can see things the same way. And if you want to test out how your images are going to look to somebody who's color blind there's this great program called color oracle. It runs on windows mac and linux at least on the mac shows up in your menu bar and you can switch between different types of color blindness and it'll alter your screen to show you how people with color blindness perceive what's on screen. So you can use it to check your images and make sure they'll make sense for everybody. So instead of those other pie charts this is like a little bit better of a way to handle it. The colors are contrasting a little bit better. They may not be great yet but there's better contrast. They're all distinct so somebody with color blindness is going to have a little bit better of a time distinguishing them. And instead of having a legend at the top where you have to match the colors you have the values right alongside each wedge so you're not using color as the only way to convey that information. You're actually presenting it in a way that somebody even with no color vision would be able to see okay well this wedge is associated with this value. So just by making small changes like that you can make a huge difference in how people interpret your content. The next accessibility related thing I want to talk about is text based alternatives. So we're all hopefully very used to using alt text on our images but there's a lot of other ways you can do that I'm not going to go into detail on all of these but there's various ARIA attributes. There's the long desk attribute which is super controversial but it exists. You can wrap things in descriptions in links or wrap your image in a link to a longer description. You can put stuff in fig caption and then you can put content within your SVG because that's accessible too. So as I said I'll post these you don't need to copy down these URLs but here's a bunch of information about how to provide good text based alternatives for your images for people who can't see them or have difficulty processing them. This can be a huge help. And the last thing is to just use fewer images overall. If you cut an image out that's one less image that the user doesn't have to load. Leah just gave a great example of how you can replace pie charts like the one that I just showed you with CSS and maybe a little bit of JavaScript if you want to use your polyfill. It's going to have a huge performance impact. Any time you don't have to download that image, any time you can do the rendering with just markup it's going to be great for your users. So keep it in mind if you can cut an image try to do that. And the last thing I want to leave you with is just this quote from Brad Frost again. Good performance is good design so as you're building your content just try to keep performance in mind. Try to keep users on a slow connection or an older device in mind and hopefully you can make somebody a little bit happier and earn a new customer. That's it. That was responsive images and please come talk to me if you have any questions.