Back to Blog

Transcript: Accessibility Part 2


This is the transcript for The Dirt episode, Accessibility Part 2

[Intro Music]

Tim: Hello and welcome to episode five of The Dirt, this is “Accessibility Part Two”. Last week, we did “Accessibility Part One”, obviously. We thought since it was such a good show, and it got such a good response, that we would do “Accessibility Part Two”, get through some more of the topics. We had a lot we wanted to go over. But first of all, my co-hosts, as always, are Steve and Mark. Steve, from what I know about you, you’re really into fitness. Most people don’t know that, I don’t know why they wouldn’t assume it. What have you been up to lately?

Steve: Well, I’ve been trying to debunk those rumors, which really isn’t going well, seeing what you’ve been saying. But, more importantly this week, I’ve been trying to make this show look a little more professional. We’re up on iTunes now, we’ve got a cover, and we’ve got a Twitter account. We’ve got images on that Twitter account. We almost look like we know what we’re doing.

Tim: Everyone knows you’re nobody until you’re on Twitter, and we are now on Twitter, right?

Steve: Exactly. Well, we’re still struggling for that whole “having more followers than people we’re following” thing, so if you can help us out, that would be wonderful. You can find us @TheDirtShow.

Tim: Yes. I’m also here with Mark. Mark has some announcements that he wanted to let us know about.

Mark: I’m pregnant.


Mark: Sorry, I was watching a clip reel of Arnold Schwarzenegger lines recently, and I just remembered “Junior”. Anyway, sorry. I do have an announcement. I’ve been working really hard with Alex Stetson, our events and marketing coordinator, and we’ve been working on a portfolio review event in the Boston area that I mentioned last week. I’m really pleased to announce that we have a partner who is co-hosting the event with us, and they’re actually going to be hosting the venue, so we have a venue. We’re going to be at the Mass Challenge space, down by the Boston sea port. It’s being hosted by Design Museum Boston. For more information, you can check out the link in the show notes. We’re really excited, it’ll be at the end of the month, October 29th. We’re excited to get everyone in the area to look at some of their artwork for design review.

Steve: That’s going to be great. I can’t wait to get my portfolio torn apart by actual professionals.

Mark: That actually is what we’re going to do. If you bring a paper portfolio, we will actually tear it apart. It’s a feature, not a bug.

Steve: I’m going to make Tim cry. That’s my goal for the day.

Tim: Steve makes me cry every day.

Mark: Par for the course.

Steve: Yes.

Tim: Today’s show is about accessibility, and before we kick things off, we just wanted to review a little bit about what we went over last week. Not in a boring way, but in an exciting way.

Mark: With laser sounds!

Tim: Lasers.

Mark: PEW!

Tim: Thank you. That was our laser effect. So we went over some general accessibility stuff, we talked about why it was important to us, some Section 50a compliance. We talked about the Target lawsuit, very basic things like using Semantic HTML, using alt-text, the importance of it, and when not to use it. What is good alt-text, what is not great alt-text, something about captioning. We talked about skip menus. Skip menus are actually an interesting thing that I think have kind of gone away lately, I haven’t seen them on a lot of sites. Back in the old days of the Web, a couple of years ago, they were all over the place. It’s just this little menu up at the top of the page that gets hidden for accessibility that will jump you to either an anchor or a Div ID. You can use direct Div IDs, I know we’re kind of shying away from those in the object-oriented CSS model where we class the bejezzus out of everything, but it’s an instance where using IDs are really important, and I think skip menus do get overlooked a lot. We also talked about design accessibility, with colors and the color blind, and some button design. We talked about designing a button and using the actual mark up for a button, and some of the accessibility issues when we’re styling links and making them look like buttons. Did we get into form accessibility? Did we get that far?

Steve: Yeah, we got into forms.

Tim: Okay, so the form accessibility thing was one of the larger issues with the last show. I think it was really important. Today, we wanted to launch right into fonts. We talked about icons and icon fonts last time, but we left out some important things about font sizing and even, what’s the word I’m looking for? Not the “font family”, but…

Steve: You mean the font face.

Tim: Yeah. There we go. So, Mark found a really interesting font that he wanted to bring up, so I’ll hand it over.

Mark: So, this came up because I was thinking about as you’re designing and making your site accessible, obviously there are things we promote to use across the baseline, but if you are a reading-heavy site working on making your text readable, if you’re an image-heavy site or a form-heavy site, having an area to focus above and beyond, and for Insta-Paper, which is one of my favorite apps, it’s an app for iOS, and actually for Android now, as well. It’s a reading app, and that’s the focus of the entire thing–reading. And Marco Armant [SP], the developer, has recently gone on a bit of a campaign similar to what Tim is saying, about how it is so easy to make things accessible, so why not? One thing he did in a recent version of Insta-Paper in late September was add an additional font called the “Open Dyslexic Font”. This font is really fascinating. It’s design, with the heavy scoops at the bottom of the font, might look a little strange at first, but it’s designed to, as Marco puts it, “Its bottom-weighted characters are designed to reduce letter swapping and increase differentiation between similar-looking letters, which improves readability for people with dyslexia.” So, it’s a pretty cool font. We’re throwing a link to it in the show notes. Again, the font is called “Open Dyslexic”.

Tim: You know what I think it looks like? It looks like a haunted house.

Mark: It’s a little “haunted house-y”, it may look a little sideshow, but if it’s making a significant difference for someone who would otherwise have great difficulty getting through large bodies of text, it could be a great, easy fix to make this an option on your site.

Tim: And it would be super easy to implement. If you just want to toggle a class, there is some extra weight of the font itself, if you want to just toggle a body class and change the font that way. You could also asynchronously load in the fonts, load in a completely different style sheet. Then you’re kind of– what am I looking for here?– relying on Javascript.

Mark: So, credit where credit is due. The font is by a fellow named Abalardo Gonzales, and it is a free font. There’s great licensing information on the site and again, it’s, we’ll put that link into the show notes.

Tim: I’m glad we brought up dyslexia, because the last show, we talked about blind and I think we talked about deaf, and color blind, but we really didn’t talk about dyslexic users, and I think it’s probably a really big audience. I think it’s fairly prevalent. I don’t have the statistics, but…

Steve: Yeah, most of the people I know who are dyslexic are a little bit private about it. They just don’t want to talk about it that much, because people have some misconceptions about it, but I know a lot more dyslexic people than I know blind or deaf people, so I would think that the incidence in the population would be a little bit higher. So when we get into areas like font design–traditionally, font design is based very much on letter forms and human writing for the letter form shapes. This dyslexic font completely does away with that, which is interesting. Instead of relying on archaic ways of determining what something is going to look like based on handwriting when we’re in a digital medium, this designer has actually looked at how the reader perceives shapes when they’re looking at them, and they’re designed accordingly. Even though it looks a little strange as a result, it’s functional. That’s what’s more important, here.

Tim: I’m really glad the new style of web design, I guess we’ll call it, is erring on the side of these larger, more legible fonts. I remember, back in 2006 or 5, when we were using like 10 point font when we were building sites, and you couldn’t read it. Design aesthetics took a front seat, and everything else took a back seat, and I’m glad we’re kind of– not that we’re moving in the other direction, you have to make this design look nice, but you also have to make it accessible and usable and everything.

Steve: I think a 10 point font on a website tends to be a number one indicator of a print designer who’s just become a web designer,

Tim: Exactly.

Steve: Because, I have a print background and 10 points is generally considered the default because 12 points just looks horsey when you print it out. So when you jump over to the Web, that’s the first thing you do. It can look really nice when you use small fonts, but it’s not readable.

Mark: Yeah, to a point it’s almost a funny form of skeuomorphism, to a point where the conversation about skeuomorphism in the design community right now is this notion of bringing over leather, or things that look like physical, metal buttons. And, yes, that’s skeuomorphic because of the idea of taking a design cue from something physical and bringing it into an abstract world where it’s no longer required, but to a point it also applies to something like font styling, and if you’re bringing in something that was a requirement, a necessity, something that is a hallmark of a print world into the Web world, it’s understandable bringing it in, but it’s showing that maybe you’re not thinking about what makes this medium different, what makes it special. And so, across the board, I like just thinking about what makes this the best. How can I make this the best experience for this device and this situation? Scaling up fonts for these kinds of devices is a great way to start.

Tim: Yep. So, the next thing we wanted to talk about was Ajax accessibility, and we very, very briefly touched on it last week. It’s kind of a difficult thing to conceptualize, because you have an initial page render, and then a screen reader goes through stuff. How do you tell a screen reader that a content area got updated without refreshing the page? It’s been a problem, it’s being solved. I don’t know that it IS solved, it probably isn’t 100% solved, but we have paths to make these Ajax interactions more accessible, and it’s in the Wai-Aria spec. We just call it ARIA. You can do regions and roles. Roles we’re using in HTML5, I think they might be in the boiler plate. I don’t use the boiler plate, but it’s on the–

Steve: I’ve seen a couple of instances.

Tim: On the header, it will say “role=banner”, something like that.

Steve: I believe I’ve seen a couple of instances of it, it’s not pervasive, though.

Tim: Yeah. So there are a few of them, there aren’t a ton of these roles, but there’s enough to where you can mark up a site and make it actually meaningful. Before, where we were using divs all over the place, and a div is a div, is a div. There’s no real difference from a semantic standpoint, this div versus this div, versus this div. You put an ID of “Header” on it, but a screen reader really can’t– what are they going to do with that? To my knowledge, they don’t read IDs and classes, that would be ridiculous.

Steve: Especially if you’re relying on classes to make your JavaScript work properly. If you’ve got a whole bunch of classes on an object, an element, then a screen reader reading that is going to cause a real problem. So, I know at my last job, we talked a lot about naming things semantically, and it’s great from a development point of view for keeping us organized, but just using semantic class and ID names does nothing for the people we’re using semantics for, in this case.

Tim: Right, and we took it a little further last week when we were talking about semantic HTML, and HTML5 helps that a little bit with the structural elements: header, footer, section aside, article, nav, what have you, but you can even go further than that, because you can use multiple headers on a page. You can use multiple everything on a page. There aren’t very many HTML elements you can only use once. I think, off the top of my head, “Title” is the only one that you can only use once.

Steve: As far as I know, that’s the only one that will cause a validater to throw a hissy-fit.

Tim: Yeah, so it’s not helpful to only have one, like if we have headers and you only use the one, that’s not helpful. You can use them over and over again, so you need a way to distinguish, in an accessible way, that this header is the mast head, or the banner, or the top of the page, basically. And the way we do that is with an ARIA role, and the role in this case is “banner”. There’s also roles for navigation, there’s menus and menu items. There’s footers, but it’s not called “footer”, it’s called “content info”, that’s the rule for a footer. I wouldn’t call it a footer, but it’s the stuff at the bottom of the page, with the copyright information and stuff.

Steve: I actually don’t know a lot about these, yet. This is something I just started looking into. Are those roles defined, or is that something that you can put in there and the role gets read back regardless of what you put in?

Tim: They are pre-defined in the W3C specification.

Steve: Okay.

Tim: And there’s a set number of them right now. They do work, I’ve used them with Max Voice-Over. I haven’t done it in a while. It’s usually an exercise I like to do at least once a year, open up Voice-Over and try to navigate a site, just to remind myself that I’m amazing.

Steve: I was actually trying that with the apprentices yesterday. It was eye-opening. It was the first time I’d ever done that. It was…

Tim: It’s difficult.

Steve: Yeah.

Tim: The first time, well not the first time we did it, but the last time I did it. I was teaching a class at a design school nearby. I was just in front of the class and we opened it up and we went over the ESPN website, I think, and then we went over something that was super accessible. Not that ESPN is not accessible.

Steve: It’s information dense.

Tim: Yeah, I haven’t evaluated it, but it’s a heck of a thing to go through, obviously. But then we went through a site that was properly marked up with the roles and everything, and aside from the fact that I’m really not super comfortable using the software, it made a world of difference, having those ARIA roles on there. You could actually navigate, you could jump to the navigation. It was usually marked with Nav, the element, but there can be multiple ones of those, so marking a role “Navigation” is super helpful.

There’s also, for Ajax accessibility, when you’re updating an area over and over again, we have “live regions”, is what we call them. I don’t have them written down and I always blank on the word, the term. It’s ARIA Live? No, ARIA Atomic, that’s what it is. So the attribute is “aria-atomic” and you set it to true/false. It’s a binary, and what that means is it says, “Hey, screen reader. FYI, this area is going to update” as you’re interacting with the page, so you know to come back to it. Also, you can set the sensitivity of it to “polite” and “aggressive”, so you can say that the area is going to update, but be polite about it. “Polite” and “Assertive” are the actual attributes. So what you can do is, if you set it to “Polite”, which is the normal thing, to set the update to “Polite”, and it will say “This area is going to update, but I’m not going to tell you until you’re done” or “It’s not super urgent for you to come look at this, you can finish what you’re doing, sir, and move on.”

Steve: That’s polite.

Tim: So it said “sir”. And Atomic will actually say “Hey, whoa, you have to come back to this and take a look.” It’s super disruptive. It’s… not Atomic. Why do I keep messing up the words? It’s “Assertive.” It’s Aria Live Assertive.

Steve: It’s like my cousin. She has to run into the room every time she does something new, and tell everybody.

Tim: So if we throw her into a computer screen and get her to scream, it’s the exact same thing.

Steve: Oh yeah, perfect metaphor.

Mark: Should we get her as a guest panelist?

Tim: She just yells in the background.

Steve: I’d really rather not have her in here.

Tim: Just like, “I have to go to the bathroom!” way in the background.

Mark: I love it.

Steve: We’re going to be lucky if we get that much warning.

Tim: So [chuckling], she’s in the corner. This is kind of disturbing


Tim: So, accessibility when the page doesn’t refresh is always an issue. We’re trying to solve those with this ARIA spec and the live regions, but a challenge that we come across a lot is coming across SVG and Canvas. It’s a problem we had early on in Flash, as well. Flash kind of solved some of the accessibility issues, they introduced where you can tab through Flash interface now, but as far as I know, Canvas and SVG are not super accessible. We were recently working on a project–Mark was actually recently working on a project where we needed to use SVG charting.

Mark: Yeah, that’s correct. Steve and I worked on a project where a big part of it was developing charts and creating charts in the browser, and Jen, who is one of our software developers here at Fresh Tilled Soil, was going through a whole bunch of different charting libraries, JavaScript libraries for handling charting in the browser, and had some great discoveries in terms of, as we got the discussion going, how do you make sure this visual data is also really accessible for folks?

Steve: Yeah, it’s sort of a sticky issue because, the reasons we chose SVG charts for this were because we’re working with two different display types, where we can’t control the resolution. Working with standard iPads and the new retina iPads, and so we need to be able to render these shapes and vectors using data we’re pulling from Jayson, and we also need to be able to style them effectively, so we can use very similar styling rules to what we’re already using CSS for throughout the rest of the application to control what the particular shapes in these charts look like. I’m not entirely sure how accessible they are, however we’ve talked about a lot of methods for how we would create accessible charting using SVG. I think one of the methods we discussed pretty heavily was inserting all of this data into tables so that it’s properly accessible within the page, and then using JavaScript to pull that data out of the tables, and replace the tables with the shapes and the charts.

Tim: I think that’s a good model, actually. It keeps all the data accessible, and it is data, so it makes sense that it would go in a table.

Mark: Yeah, it’s already tabular data to begin with.


Tim: Most likely.

Mark: Yeah. You’re not just throwing stuff at the wall to see what sticks. You have the information, so it’s just about presenting it in a nice way.

Steve: Right. I’ve seen a couple of implementations this way, people have made a couple of attempts to do it. They’ve done some interesting work, but I haven’t really seen any heavy duty, here’s a perfect model of accessible data in a table, translated over to a more appealing visual format, so I think that might be a project that would be good for us to work on at some point in the future. I think we could contribute something there.

Tim: Yeah. I also wanted to let everyone know the actual charting options we looked into. We looked into building a custom SVG/Canvas-based chart, and that was really hard, so…


Tim: So we looked into high charts, as an option, and we also looked into Rafael. I thought Rafael was actually really good, I think we ended up settling on high charts, it was more flexible or something, where Rafael was more “You build this yourself, but we’re going to give you the tools,” like a Jquery version for chartings.

Steve: Yeah, my understanding was that Rafael was just a good way of rendering these shapes, where you still had to deal with all the intricacies of charting it on your own.

Mark: Yeah, it gives you the tools to do what you need to do, where I think high charts will actually give you more specific tools, right?

Steve: That’s my understanding of it. This was really more of Jen’s role in the project. I bounced some ideas off of her and made sure that I wasn’t creating anything that was going to give her 4 months of headaches trying to build it.

Mark: Just 2.

Tim: I feel like I’m going to sneeze.

Mark: Just don’t do it on the mic, because we all use that mic. I mean, no one is licking the mic, but still, you don’t want to get your germs all over it. I’m sorry, this is just…

Tim: This is a community mic, and I do have it in my mouth–

Mark: –a lot. More than you should.


Mark: We’re just going to move on, because it’s a good thing this is audio and not video. You don’t want to see Tim with that mic.

Tim: You want to see this Formal Friday get-up, though. That, once again, Steve is not participating in.

Mark: Although he’s wearing a collared shirt today.

Tim: I know, I noticed that first thing when I came in and he was making a single cup of coffee.

Steve: I have a client meeting today.

Tim: There you go, there it is. So I think that graphing is always going to be a challenge, and we are doing our best to solve it. I think that using the tabular data is a really good option. We’re leaning more towards an API based development, but it’s always important to build out that data with some sort of server technology, so that when the page renders, you have the data right there and you’re not just relying on JavaScript to build out the information.

Did we want to talk about games? Before we started this podcast, we were talking about gaming, and how to make gaming accessible. Gaming and animations, really. We’ve seen those cute little animations online, and there’s a lot of cool things with HTML5 canvas for gaming. I like bringing up stuff that we don’t have the answer to, because we’re not– I mean, I’m super smart, but we don’t have the answers to everything, and I think that gaming is really difficult. We were talking about it earlier, and Mark brought up that some games lend to accessible interfaces, and some of them don’t. How do we make them as accessible as possible?

Mark: Yeah, and so… the way I came into this is, I can only imagine Super Mario Bros, and I’m going to go back to just straight up original Mario, trying to jump over the pit, land on the goomba, etc, etc., becomes a little difficult when you cannot see said goomba. That said, something like chess or Monopoly, these are games that work on a very clear structural level, and you can communicate verbally, and in fact, you can look back in decades of newspapers where there was a chess column, and people who played chess by sending a letter. Anything that works itself well into text and this kind of system, can lend itself very well, I would imagine, to an accessible system. Something that’s very sensory/reflex/trigger based presents a lot of barriers, but I wouldn’t necessarily count it out entirely.

Tim: Yeah, I don’t know how you would play, for example, “Gears of War” in an accessible manner, but people are already playing chess by describing to each other the moves that they’re doing.

Steve: What about that game, did you guys see “Big”? Did you see the movie “Big”?

Tim: A long time ago.

Mark: With Tom Hanks?

Steve: Yeah, that game that he was playing, it was primarily text-based. It was like, “You’re walking into the cave. What do you want to do?”

Tim: Oh, I know the name of this. A bunch of my friends are obsessed with it.

Steve: But you know what I’m talking about.

Mark: MUD?

Steve: I don’t know the name of it, but stuff like that. I wonder if something like that could be transferred over to something like Mario Bros, where it’s not that you’re running, it’s that you hit a command and then you run, and then you hit a situation.

Tim: What you’re talking about is a text-based adventure, which works because there’s a description of a scenario which is occurring and then a list of choices you have to move through that scenario.

Mark: Yeah, I think a lot of this comes down to there’s accessibility today, and accessibility tomorrow. So what we see for tomorrow is, we already see across android phones, iOS devices with Siri, we’re seeing voice recognition become more powerful every single day. And, sure, it’s easy to make fun of and say, “Ha, Siri. I asked it what time it was and it told me that I look handsome today.” It’s like, “Well, thank you, Siri, but that’s not really what I asked you about.” But in the end, this technology really is phenomenal. Speech recognition and speech synthesis are getting exponentially more powerful by the day, and the more they get deployed, the better they get, because the more data they have to pull from. So I think, as we’re going to see things like voice recognition, gestural recognition, all these things change, we’re going to see interfaces change and we’re going to have more and more ways to interface with computers, and interface with them reliably.

Tim: Yeah, I’ve seen a really interesting use of voice and gesture interaction lately. I downloaded an app for my iPhone called “Ways”, which is basically a GPS, it bills itself as a social way to beat traffic together, but the heart of the application is a GPS, and it has a couple of interesting features built in. One of them is that, based on your speed, it detects that you’re driving and therefore should not be typing things and disables the ability to type, but it adds the functionality back in through a few different ways, like you can enable voice control to enable simple commands. There are two ways to indicate to the interface that you want to enable voice control that are low-distraction ways of doing so. The first is that you can wave your hand over the screen, and I think the little camera that detects how close your face is to the screen is used to detect that wave and activate voice control. The other way is to quickly tap three fingers on the screen, so you can use a quick, gesture-based interaction that isn’t used for anything else in the application to say “Hey, start listening”, which is pretty interesting because, when you’re driving, it’s a very high-distraction environment, and so creating a method of alerting the device that it should be waiting for input with as little distraction as possible is not only good UI design, but it’s also a lot safer for everybody. And that brings up the point that accessibility isn’t always about disability, it’s also about high-distraction environments in a lot of cases. I think that driving, in particular, not to harp on the driving stuff too much, but it’s an area where people are not designing accessible interfaces as much, particularly when you see things like a touch screen embedded into a dashboard. That’s not useful.

Mark: Great for a passenger, not so much for a driver, and by putting it there for the passenger, you’re just inviting the driver to do the same. My mom has a 2006 Prius. Great car, love the car. The main way of interacting with the radio, with the temperature, with all these various controls, is through a touch screen. There are steering wheel back-ups, with physical buttons, but the touch screen is the nice, big, inviting, colorful way to do it. Even when you’re driving, it shows a chart of where the energy is moving around, like the brakes are now causing the battery to recharge, you’re seeing this go around and it’s this pretty picture to look at while you’re driving. So I agree that the over-dependence on these non-tactile-feedback, non-audio-feedback systems is part of this whole discussion.

Steve: I know that when I’m driving, I’m always looking for other things to pay attention to.

Mark: It’s a game for you.

Tim: I honestly believe that putting a touch screen into a car as the main method of interacting with various controls is a criminally offensive design. You should not be doing that, because the tactile feedback is what allows you to accomplish the things you want to accomplish on the console without getting distracted from the main task at hand, which is driving and NOT crashing into the person in front of you.

Steve: So, speaking of gestures and everything, I sent out a link around the office earlier this week, maybe the other page turning thing? It was a book that uses this new JavaScript method called “Get User Media” and it goes into your camera and it detects gestures, so you can be reading this book and if you wave your hand in front of the camera, it will actually turn the page. And once again, using hand gestures on a podcast, so I’m not sure if that’s helpful. It probably isn’t. But, you wave your hand in front of the camera and it turns the page. You can actually flip your head and do it, it’s super sensitive right now, but as the algorithm improves, hopefully we’ll get stuff like that in a car. It would be amazing.

Tim: There’s some really specialized, highly customized software that can already do things like that. There are ways to interact with a computer entirely through the movement of your eyes. There are cameras that are sensitive enough to detect not only that your eye is moving, but the direction and the manner in which it’s moving, and then control the computer using that data. So this gets into the area of enabling use for physically disabled users. People who might be paralyzed from the neck down, they’re not going to have a lot of traditional methods of interacting with a device. Possibly voice interaction is available, but frequently it’s not available. So being able to capture the tiniest amount of movement a person is capable of using can open up access to them in a way that was previously inconceivable.

Steve: So high-distraction is certainly an angle to come at accessibility that, before we put together these shows, I hadn’t really thought of. You think of the normal, disabled user stuff for accessibility, but there’s also something we talked about in the first episode, and you should totally go back and listen to it because it was an amazing episode.

Tim: It was mind-blowing.

Steve: It was about bandwidth accessibility and progressive enhancement in making sure all your content is always available, which I think is super important. It’s something that I push for a lot and I think it kind of takes a backseat when we start piling on JavaScript and everything and we don’t realize that people are accessing this stuff, oftentimes, from a constrained bandwidth. Whether it be a dial-up connection, and they do exist. I know people listening to this right now are probably not on a dial-up, but I promise you that not only do a huge amount of the population not have computers, a large part of the population are still on constrained bandwidths and mobile devices.

Tim: Especially in rural areas, where a lot of the utilities don’t have a lot of incentive to build out into that area, these people are essentially stuck with dial-up for the foreseeable future. Not a good position for them to be in, but there’s really not much chance of that being solved, so that’s where performance and how it affects accessibility really starts to rear its head as being incredibly important and something we’re frequently ignoring. There’s been some talk lately about the performance issues that some people say are inherent to responsive design, and my answer to that is that a poorly developed site is a poorly developed site, whether it’s responsive or not. We have a responsibility to do a good job, and you optimize as much as much as possible for people who have limited bandwidth and limited access.

Steve: That’s good. We should have a whole show on that.

Tim: Sure, let’s do it.

Steve: Right now?

Tim: Right now.

Tim: We’re going to do another hour and a half on that, so get ready. No, but there’s not only dial-up and everything, there’s also just mobile. Mobile is growing, we know that. There’s constrained bandwidth there, and this is something that I wanted to specifically bring up about accessibility and responsive design, with that meta element, the view port element. I read an article recently, called “Stop using the view port tag”, and it wasn’t telling you necessarily to stop using the view port tag, I think that was more a marketing tagline, but the guts of the article were to stop using it until you understand how to use it. Don’t use it if you’re not using a responsive design, and it’s a problem with–I don’t want to pick at the HTML5 boiler plate, and I don’t even know if it’s in there by default right now, but they used to have a view port tag in there by default.

Steve: The view port tag is still in there, and it used to have user-scaleable set to “No”, but it doesn’t have that anymore, now it’s initial view at 1.

Tim: Great, so, the other problem with the view port tag is, if you’re using it and you’re not using a responsive design, it will zoom your website and make it unusable. The secondary problem is, when you are doing a responsive design, and a lot of people are guilty of this, and you turn off user zooming, I think it’s called “user scaling”?

Steve: Yeah, it’s “user scaling”.

Tim: And you can turn that off. When you turn it off, you prevent people from zooming your interface, and that’s kind of a big deal. We can zoom on the desktop with cmd plus until your heart’s content, and you don’t want to overwrite browser behaviors that are really helpful. I’ve seen some people use these devices that have low visibility, and they put their screen right up to their screen, like it would burn my eyes to look at something that closely. But they do that, and a lot of times it’s because people turn off zooming. I will say, it’s a little inconvenient, I believe, when you rotate the phone, it will mess up the zoom level.

Steve: Oh yeah, user scaleable set to “None” is actually what people are using to prevent that bug, and that is not by any means an acceptable use of it. There is a JavaScript library that detects that you’re rotating and enables it only during the rotation, which is a clever trick, I think. But if you’re only throwing that into your website because you’re afraid of how it looks after it rotates, you’re doing a huge disservice to a pretty sizable segment of your users.

Tim: Right, so we’re saying do not turn off zooming on a responsive design, and certainly don’t use the view port tag if you’re not– well, I’m not going to say don’t use the view port tag, because it does have other uses beyond responsive design. It actually will add a nice little padding around your site on a phone if you set the view port to, instead of– I’m totally blanking on this.

Steve: Instead of 1.0? Oh, you’re talking about initial zoom.

Tim: Yeah, so you can set the view port to a hard 1024, and it will actually clean up some of the cruft around the edges, so use it, but know what you’re using sort of thing. Don’t just throw it in there because it’s in the boiler plate.

Steve: Yeah, Tim’s saying just don’t use it unless you have an idea of what you’re up to.

Tim: Not that you don’t have an idea, but…

Steve: Some people don’t.

Tim: Right. And we found out an interesting– it’s not a bug, the thing with the zooming, from before we started the show? It was in a responsive design when you’re doing command plus,

Steve: In a flexible design.

Tim: Sorry, sorry. Flexible design. The, oh what was it?

Mark: We were zooming in on a design that was using percentage widths for the page, and as we zoomed in, the percentages stayed consistent but the content didn’t scale with it accordingly, so while your 50 25 x 25 columns stayed nice and proportioned, the text would go up and up until you were fitting a character per line, and it became illegible.

Steve: Yeah, and I think one of the things we were thinking about, and it turned out to not be available, is if you could use media queries that were based on zoom level, you could actually use the responsive techniques we’ve been using to size for mobile devices to go as far as sizing for a user zooming in on a desktop device, so you could anticipate what that person was trying to achieve, and change your layout and style accordingly. Unfortunately, zoom level is not available in media queries, but I think we’re going to take a look after this recording session into other ways of handling that problem.

Tim: We’re going to solve that. But if you solve it first, we share.

Steve: Okay, so I think we’ve taken up enough of your time and we want to end this on a high note while you still think that we know what we’re doing, so thank you for listening to us today. Mark and Tim have a couple of events to talk about before we sign off.

Mark: Yeah, so we’ve got a few events coming right around the corner soon. On October 18th, the morning of the 18th, there is an event called “No More UX Nightmares: Simple Designs for Complex Needs”, and Richard Bannenfield, our CEO, is going to be speaking at this event that’s in Waltham. He’ll be speaking about design solutions for UI projects. We’ve got another event that Tim’s going to be speaking at, “Environmental Design on the Web”,

Tim: It’s going to be amazing.

Mark: It’s going to be pretty cool. Tim’s been working on this talk for a while, and we’ve been chipping in a little bit to try to help him on it, it’s a really neat talk about where we go next with responsive and what’s coming up in web technologies. It’s a pretty neat talk.

Steve: It’s all right.

Mark: It’s all right, yeah.

Tim: It’s amazing.

Mark: And, on October 25th, we’re going to be hosting with Wayfair, down on Huntington Ave in Boston. On the 25th, we’re showing a private screening of a documentary called “Design and Thinking”. I’m really excited for this event, and I know tickets are running out, so if you’re interested, you’ll definitely want to check this one out. All the links for these events are on the blog post and in the show notes.

Tim: And we also have a second event on October 25th. Our own Paul Greenley is going to be talking about performance on the web for mobile devices at the web performance meet up in Boston. We’ll put those notes at the end as well. So, I think we’re going to get out of here. Thanks for listening, and we’ll try to do better next time.


Author Tim Wright

More posts from this author

Sign up to receive updates from our blog

What we do Expertise

From concept to design, we'll partner with your team to deliver amazing product and website experiences.

Recent Projects Work

See the results of our most recent digital product and website engagements.