- [Voiceover] Alright, this is a quick demonstration of some responsive design concepts and some of their accessibility implications. I wanted to start off with just looking at a really specific example of some responsive images. There's different types of images that we have that we use on the web, and this is one particular type that I think creates some issues with responsiveness. If you take a look at this, this is an image of the solar system, of our solar system. There's a few different things that happen here. If we make this a responsive image, which means that we allow it to flex with the width of its container, you'll see one thing that happens is we start to get to the point where we make it flexible, but it gets to the point where it becomes so small that it's not really usable anymore and it becomes really difficult to read. This is a kind of image that, even though we can make it responsive, I think we don't really want to make it responsive. This is something where we consider this to be a content image. There's words and important things in there, that if that image is scaled, it actually doesn't provide the flexibility that somebody needs to be able to read that. As the text size gets smaller, spatial relationships generally stay the same, but the overall space that somebody has to look at this image gets smaller as well. So, we've been playing around with different ideas, and one of the things that we've come up with as another means to deal with responsive images is to actually just say "lets not make them responsive". One of the things that I believe pretty strongly about this is that some images, because they're content images, should be just kinda left alone to be explored. Now, we're often making these things scale because we don't want to blow out the viewport. This piece of content is so wide that it blows out its container, and so in order to avoid the scrollbars, we think, "well, let's make that image scale". When we think about the idea of somebody getting at the content in this image, we think that there's some alternatives that we could actually look at. So, for one of these content-type images, we've created this other little mechanism. If you see just down below here, we take that same image and as it gets to be too wide for the viewport, we allow it to create that horizontal scrollbar so that people could explore it. And then the other thing that we allow is, or that we create, is this little call to action that says "pop this thing out on its own". Part of the reason that we're doing things with responsive layouts is that we don't want to blow out that viewport. So, what we've done here is create a little mechanism that allows somebody to look at that same image without the constraint of the horizontal scrolling and can deal with that scrolling within the browser as a whole. So, we pop that out into a new window to allow somebody to explore it without any of the constraints of the viewport or the container. We want to look at that as a potential alternative for working with responsive images. By the same token, we're also looking at that same kind of a behavior for something like a table. There's been a lot of work done by different developers out there to create responsive tables, and some of them maintain accessibility, a lot of them don't. Some of them break tables apart into two separate tables: one table for the header and one table for all the rows of data. We wanted to take a look at this and say maybe this is actually a good case for creating a responsive table that uses the same kind of mechanism as the image that we just saw. So, as the viewport shrinks, we still maintain that scrollability on that table, but if we want to be able to use this in a way that is not constrained by the things around it, or constrained by the viewport. We can actually pop that out into a new window as well, and just look at that table on its own, rather than having to try and rearrange the table. So, while there's different mechanisms for this, we've kind of started to take a look at what those things look like and abstracted it out to look at some different possibilities. One of the possibilities that you've probably seen before is to take a table like this where we've got several columns and several rows, and take that and break it down into stacks. If we take this table and start to shrink the viewport, we end up getting to the point where we see this stacked arrangement take place. So, each row, you see here the first row is Engine Control System, we've got those columns of data, what ends up happening is we take those column headers and we repurpose them to create these effectively name-valued pairs so that now we have one table that effectively represents each row, where we're styling it into this stacked arrangement so that the table is maintained. We end up with this slightly different representation of the data. Now, this is okay from an accessibility perspective, but one of the things that we need to understand is those two different types of use cases. One, where somebody's actually exploring the table and looking for a particular piece of data, and the other is doing that comparison. While this still works from a display perspective, and we can maintain some semantics here, the act of comparing is not necessarily as straightforward as it would be if we had the entire table to look at. Again, we're doing this partly because we've got that constrained viewport. So, we've looked at this as an option as well, and going right back there to that other example, we've created this example and this script to effectively listen for those breakpoints, and we get to the point where when it becomes too narrow and we get into, say, a mobile viewport, we can take that and pop that out, and look at that data entirely on its own without really needing to worry about the constraints of the viewport. This maintains the original integrity of the table, it maintains all of its accessibility, maintains the explorability, but doesn't have that visual change that we've come to expect with responsive and responsive designs. So, I think that this is something that we see as a viable alternative. It's not the only way to do responsive tables, but if you think of the different types of tasks that somebody is trying to complete when they're looking at a table like this, we think that this really helps meet those original goals and allows people to not be constrained by that viewport or the container that is holding the table.