JavaScript Jabber

JavaScript Jabber is a weekly discussion about JavaScript, front-end development, community, careers, and frameworks.

Subscribe

Get episodes automatically

058

058 JSJ Building Accessible Websites with Brian Hogan


Use this link and code JAVAJAB to get 20% off your registration for FluentConf 2013!

Panel

Discussion

00:55 – Brian Hogan Introduction

01:48 – What Accessibility Means

02:56 – Making Websites Accessible

06:06 – “The Right Things”

09:00 – Tools & Techniques

14:56 – Manipulating the DOM

16:54 – Screen Resolution

19:24 – Typeahead

20:58 – Testing

23:11 – Resources

25:00 – Dealing with different kinds of impairments

  • Transcripts
  • Text
  • Color

28:08 – Ease of Accessibility & Empathy

31:41 – Interactive Pages

35:26 – Making things accessible vs not making things accessible

  • Making experiences better for everyone, period

42:09 – Resources Cont’d

42:46 – Understanding Others’ Difficulties

Picks

Next Week

JavaScript Jabber: jQuery Mobile with Todd Parker

This episode is sponsored by

comments powered by Disqus

TRANSCRIPT

MERRICK:  Fine, don’t come to my talk. CHUCK:  I won’t. I won’t even come to the conference.[Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.] [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.] CHUCKHey everybody, and welcome to Episode 58 of the JavaScript Jabber Show. This week on our panel, we have AJ O’Neal. AJ:  Coming at you semi-live from ORM. CHUCK:  Joe Eames. JOE:  Hey everybody. CHUCK:  Merrick Christensen. MERRICK:  What’s up? CHUCK:  I’m Charles Max Wood from Devchat.tv. And this week, we have a special guest. And that is Brian Hogan. BRIAN:  Hello. CHUCK:  Since you haven’t been on the show before, do you want to introduce your self really quickly? BRIAN:  Sure, my name is Brian Hogan and I’m a web developer and I like to spend a lot of time hacking on code in Ruby and JavaScript. I also am an author. I’m a development editor with The Pragmatic Bookshelf. And I have a fabulous new gig where I get to teach brand new programmers how to get started programming now. So, that’s what I’m doing myself. CHUCK:  So where’s that at? AJ:  Cool. BRIAN:  That’s at a little technical college in Eau Claire, Wisconsin called Chippewa Valley Technical College. CHUCK:  Oh, cool. Yeah, speaking of your reviewing books for The Pragmatic Bookshelf, Ruby Rogues, we actually interviewed Bruce Williams and John Athayde about The Rails View this morning. They mentioned you, and I was like “Oh, we’re talking to him in a couple of hours.” BRIAN:  Oh, those are some great guys and that’s a great book. CHUCK:  Yup. So, the reason we brought you on the show is because, at least in my case, I know absolutely nothing about building accessible websites. And it seems like it’s a topic that would be interesting and hopefully, there are some insights that we can gain so that we can make our websites easier to access for people who have disabilities. BRIAN:  Okay. Well, and the first thing I always like to tell people when I talk about this topic, is that it really isn’t just about making them accessible to people with disabilities. It’s actually making them accessible to anybody who wants to interact with the content. And so, that might mean that if you spend all your day developing your stuff on a MacBook Pro with 16GB of RAM and a really, really fast processor and all your JavaScript tests working just great and snappy, how’s that going to work for somebody on a mobile phone? How’s that going to work for somebody on a mobile phone with a limited data plan? How’s that going to work for somebody on a mobile phone when the connection drops in the middle of loading all the pages? How is that going to work to people on different screen sizes, different geographical locations, all of that? And that’s all part of what accessibility really is. It’s making sure that people who have an interest in working with your content or buying your product have the ability to do that. CHUCK:  Ah, got it. So, I’ve used some tools like YSlow and things to kind of get an idea for making things load faster which, in a lot of cases, means that you’re cutting back the amount of bandwidth that you use to make it run and you’re streamlining some of the dependencies and things like that. But I get the impression that there’s more to it than just that. So, what kinds of things do you typically tell people to start doing when they’re starting to worry about this kind of thing? BRIAN:  Well, the first thing I always ask people to think about is what’s the most important part of their content? So, if you’re looking at accessibility from the standpoint of the very basic, starting from the beginning, a lot of people think that accessibility is this very, very expensive thing and it’s not something that you can do if you’re trying to rush a product out the door, or if you’re trying to get that MVP. But what I’ve learned in all the years I’ve spent doing software development is that once you build that prototype or whatever, you’re shipping it. That’s really what you’re going to end up launching. And it turns out that if you start out thinking about the basic needs of people at the very beginning of the process, accessibility really isn’t any more difficult than doing unit testing or doing other kinds of things as part of your software design process. And so I ask people, what’s the content? What’s the most important thing? What do people need to be able to do? And then everything else around that is sort of window dressing and you start looking at the people who will be working with your product and you start understanding what their needs are. For example, it’s really difficult to design something for a blind user, if you don’t really understand the kinds of tools that blind users use and you don’t really understand the difficulties that they have. And the other thing I try to do, which is it’s really something that I believe is very important, is to try to think of people as people rather than users. Just start creating that empathy bridge for your self. So, if you’re thinking, “Well, I have a blind user,” that might not work as well as if you say that, “There’s a blind person that wants to access the site.” So, it’s just a little bit of a change in vocabulary. So, you start identifying those things. What are you going to have? Are you going to have pictures of your products? Well, how are you going to convey the information that’s in that picture or that graph that you’re doing, or those other visual elements? How are you going to convey that information? So again, it starts with the content. How are you going to get that content and make that important? AJ:  So to me, that just sounds like something you want anyway. Because how many times have you been to a site where you hit Ctrl+F to find the thing that you’re looking for but you can’t because it’s only described in an image? You know, like the information is there, but it’s not accessible just because it wasn’t thought like, “How is somebody going to try to find it?” BRIAN:  And that’s it. That’s exactly what we’re getting at, is it’s not really thinking about, “Oh, we have the extra stuff we have to do to make our site accessible.” It’s, “If we do the right things, we’re going to make it right for everybody.” It’s going to be such a better experience for everyone overall. And if you know all these things, it’s not that much extra work for you. And like you said, yeah, you’re going to make that content much more discoverable, much more easy to find. And that’s what people want. CHUCK:  Yup. MERRICK:  You keep talking about the right things. Can you elaborate on that? BRIAN:  So, you kind of have to look at the different types of people that are going to be working with the site. So, if you have a blind person, they have different issues than someone, for example, with motor impairment. We have different ways that people access websites. We have people who use screen reading software which reads the text on the screen and sometimes work with the browser to show maybe in an audio fashion or with a device called the VersaBraille where the Braille shows up on a little, some kind of interface. I’m trying to describe it over the radio, it’s very hard to do that, but go look up what a VersaBraille is and you’ll see a picture of one, like a Braille display. But you have these. They’ll interpret the page that way. But that’s a different need than someone, for example, who has some motor impairment problems and they can’t really work a mouse and so they use keyboards or they use other displays like a wand that’s attached to their head. And they would lean towards the screen and actually touch the part of the screen they want to interact with. And you start thinking about that class of user, and you can make the connection between that user and a person on like a tablet. And you start noticing that, “Oh, you have to make the touch areas a little bit bigger so they could hit those touch areas on a tablet.” And you realize, “Well, I have to do the same thing for the person with the wand attached to their head.” So when I say the right thing, what I’m really getting into is once you understand the needs of the people who are going to be interacting with your site, you’ll know how to serve them better. We started doing this thing when Apple came out with the iPod Touch and the iPhone, they had the Safari browser out there and the idea was that, “Oh, all the existing sites will work because this is Safari.” But what we had was that everybody kind of pinching and zooming and so we discovered that well that screen is really small, is pinching and zooming really the right way to do it? Maybe not, so we started coming up with these other techniques like Responsive Web Design, mobile-only sites and things like that, in order to serve the needs of the users. We discovered those things by studying the people who are using our stuff. AJ:  I just want to introduce a rant real quick. I hate mobile sites. I hate them so much. CHUCK:  [Laughter] BRIAN:  I don’t think there’s anything wrong with that sentiment because that’s actually what people who are blind have been dealing with in certain sections of the web for quite a while. They’ve been dealing with text-only versions of sites, which is, if you’re talking about accessibility, is probably one of the worst things you can do. Because a lot of times, the content really doesn’t make it over from the regular site to the text-only site, or the regular site to the mobile site. It’s really hard to do that. It’s really hard to keep to two different sites in sync. That’s why you see things like Responsive Web Design, but what you’re getting at, you really want to let the person who’s coming to the site decide what kind of format they want to see that thing in, rather than forcing them one or other, one type or other type on them. CHUCK:  So, I hear about techniques like adding alt tags to images and things like that. And interestingly enough, that works to a certain degree, depending on what the tool is the people are using. But I also see things like logos and background images that have text on them that are actually background images, even in the CSS. So, there’s no way to add an alt tag or anything like that to it. And I can definitely see that being a problem as well. BRIAN:  Yeah, you know there are some really good techniques for doing that, for handling that kind of situation though. One of the oldest techniques was this — I even forget what it’s called now, the FIR, Fahrner Image Replacement trick. And you can, essentially you take some text, you put some text on the page and then when the CSS loads, you just take the text and move it off outside of the viewport so that it’s not seen. And if you do it right, if you do the technique right, the screen reading software will still read the text but nobody will see it because it’s outside of the visual range. And you have to hide it a certain way. There’s actually these off-screen display tricks you have to use for CSS so that the browser — so that, well (a) Google won’t penalize you for doing spammy stuff, and (b) that the screen readers will actually still read it aloud. Because like for example, if you just use ‘display: none’, most screen readers will say, “Oh, that’s not meant for me to read so I won’t read it.” But you can handle those kinds of situations. I still would really, really like to see people not try to put text in CSS backgrounds but sometimes, we have no choice. CHUCK:  Yeah, usually something like that I see it in logos and stuff. So, it’s not the main content, but it’s still there. MERRICK:  I also think that web fonts are going to mitigate that issue a lot. CHUCK:  Why is that, Merrick? MERRICK:  Because a lot of background images exist primarily because they’re using some sort of font they can’t get into the browser. So, they’re like, “Ahh, man, we don’t want to compromise on the design. So, we’ll cut up this image with the font in it and put that in.” So, as web fonts become more prevalent, you won’t have to make images of those things and screen readers can just read it like any other text. And it’ll also react to when you command+ and you make the font size bigger, things like that. BRIAN:  Yeah, I’d agree with that. It’s one of the issues that I still see people going and doing the image route is that they don’t have the rights to distribute the font, so that licensing for the font becomes a little bit more of an issue for them. So they still put it in a graphic because then they can make the graphic available and it’s not technically distributing the font for download. MERRICK:  Yeah. BRIAN:  But it is a much better approach though, if you can get the font licensing. Because that’s why things like Typekit and other stuff out there makes that much better for people. MERRICK:  Yeah, it’s also just easier to develop. [Chuckles] BRIAN:  [Chuckles] Yeah, absolutely. CHUCK:  So, is command+, or Ctrl+ if you’re on a PC, to zoom, is that considered an accessibility feature? BRIAN:  Accessibility feature? I don’t know. I know that there are people that use it. There’s a great study, the WebAIM website has just released a survey for screen reading user, or on that. They did a screen reading, using one, in [inaudible] last year. They released the results of that one. But they just did one for low-vision users. And it shows the percentage of low-vision users that use that technique and it’s actually pretty high. But from the survey, there’s actually a pretty close number of people that also use the technique where they just actually zoom the entire page. And that’s actually the technique that I use. I actually use full screen, occasionally. I actually have a low-vision disability myself, and I typically don’t use that font size thing because it tends to mess everything up and because if I’m looking at a graph or an image with some text on it, it’s not going to make that larger, it’s just going to throw it off and I have to go and try to figure out what part of the page that jumped to. So, I typically either do the full page zoom or on the Mac, I use the built-in screen magnification, the full-screen magnification on the Mac, to see things. AJ:  So, Chrome has a tool where you can set the pages to be 110% or 150% and I use that for doing my screencasts and I also use the command+ all the time, just because 12pt font is terrible to read, even without a disability. CHUCK:  Yeah, but I’ve seen the Ctrl+ or command+ actually, like Brian said, move things around because they’re set to relative positions or the page width is set to a certain width and then when you zoom, the page width stays the same but since everything resized, then it stacks differently because it’s floated differently, and things like that. MERRICK:  That’s what he was talking about earlier, though, when he was talking about how when you’re making something accessible, say that example, you would use ems instead. And you’d use ems for your line height, et cetera, so that way the page would float better with different default font sizes. So that way, when somebody with a visibility issue makes their font size bigger on their phone, that’ll cascade down into your web app. BRIAN:  You know, and I hear that advice used a lot, and it doesn’t really translate well from my standpoint, as a low-vision user, because you’ve still got all your images there. And your images are all still defined in pixels. And they don’t really resize, and so I still end up having the text get larger, but now it’s much harder to read because now there’s and image breaking up the flow on the site. There’s actually quite a bit of sites that I do encounter that problem with. And, I sometimes think, this is actually kind of a useless technique. It’s actually sort of developer yak-shaving. Just leave everything in pixels and let people zoom the whole page. If you get a word document you can’t see, you don’t typically go and select all the text and increase the font size. You just hit the plus button on the thing that zooms that entire word document or the PDF document. MERRICK:  That’s absolutely true. You’re right. CHUCK:  So, the other question I have is a lot times, we’re manipulating the DOM with our JavaScript. Are there any issues translating that over to some of these screen reading tools or zoom tools or anything like that? BRIAN:  Oh, there can be. It used to be that you’d say, “You know, if you want your stuff to work right, then just avoid JavaScript altogether.” And the idea of a progressive enhancement approach would be that you would make things work without JavaScript and then you’d add the JavaScript on top because the theory was that screen reading users would have JavaScript disabled for one reason or other and you still want things to work. And that’s not as true as it used to be. It’s true to some extent, but it’s not really the case anymore. The bigger problem is that a lot of the screen reading software tends to work better with Internet Explorer than with Chrome and Firefox and you have a lot of developers out there doing all these cool JavaScript things and they’re focusing on Chrome and Firefox. But the number of people who use screen reading software, they’re not using those browsers. That’s a different issue altogether. So, screen reading software has gotten much better at working with the DOM and we have things like the new ARIA Live roles and HTML5 where we can actually tell a screen reader, “Hey, this part of the page might change, so watch it for updates and interrupt me when they change.” And that actually works pretty well, but it’s up to the developers to actually put those roles on the elements and understand how they work and understand what browsers and screen readers they’re going to work with. So, it is possible to do this in a very nice and clever way. And it’s been neat to see some of the JavaScript frameworks doing that. If you look at what Ember does, when you’re adding certain things in it, certain elements on pages. I’ve seen the source code for Ember actually shows that it’s adding some additional roles to elements when it creates them. And that’s kind of neat to see more and more developers doing that with their JavaScript, using the ARIA roles and things like that. AJ:  Ryan, I hope you’re listening to this. CHUCK:  So, the other question I have is, you talked a little bit about people who kind of use a wand, you know, they have to interact with the target area on the webpage. What I’m wondering is, do a lot of these folks set their resolutions to lower resolutions? Because I’ve seen websites go into higher and higher base resolutions and things like Responsive Design are somewhat new. And so, they may or may not actually resize to something that these folks can use on their browsers. BRIAN:  Yeah, you’re right on. They tend to keep resolution a little bit lower than that. And that introduces yet another interesting issue. Now, they have scrollbars, they have to go left and right. And so, that makes things even more difficult if you don’t have a mouse, and how do you do that? Plus, if you’re going to be with one of these wands, you’re going to be sitting a little bit farther away from the computer than you would normally, too. So, that is definitely some considerations to think of. It’s always been the case with technology that the people with disabilities, they’re the last ones to be able to interact with things. The blind users were doing great for a long time when we had just text-based GUIs or text-based interfaces. And then, the Windows GUI came along and everyone didn’t know what to do for quite a while. It still kind of takes time to catch up. But even with those types of things, there are still these little aggravations that get to you. One of the worst and most irritating things you can run across is using a screen reader on a website and they have somebody use the pipe character to separate navigation elements because you hear that read out to you. It’ll say, “About vertical bar, products vertical bar.” [Laughter] BRIAN:  It’s the most irritating thing in the world and you hear, with one of the screen readers, I won’t call its name out but it’s very popular. When you’re shutting down Windows for example, it would actually say, “Windows is shutting down, dot, dot, dot,” because they use the ellipses after it but they don’t actually use an ellipses character, they just used dot, dot, dot. And so, we have to be very mindful as developers. That’s why I said that it’s really important for us at the beginning of the process to think about the types of problems that our users are going to encounter. Because then, we’ll be more careful when saying, “Oh, I want to use the latest whiz-bang technology because all of my friends are doing it and I want to do it too because I don’t want my developer friends to laugh at me for being behind the times.” CHUCK:  Yeah. MERRICK:  So, I got a question for you. As Chuck said, it sounds like there’s not really any APIs you can access. It’d be great if you could, right, if you could say, you know, ScreenReader.read because I’m thinking of things like TypePad. What’s the best way to handle something like a TypePad where you have a user typing into input and they have options? How do you let them know about the options? Do you put a role on a parent tag? I mean, how would you handle those kinds of super dynamic things? BRIAN:  Very carefully, and you have to test the crap out of them. You can do that. There are a lot of different ARIA roles for those different regions. If you look at the specification, they exist. Now, the trick is, of course, just because the ARIA APIs and things like that actually exist, doesn’t mean that the screen readers are using them yet. That’s the trickiest part, and it’s actually the most aggravating part. Because I’ll spend an afternoon putting together this interface that works under one screen reader and I see it fall on its face when I just change the browser from IE to Firefox. But that’s really how you would do it. You would try to describe the individual, the extra choices and things like that, with the particular ARIA role you’re trying to do. And that’s about the best you can do. And the second best thing you can do is just provide an alternative interface for that. Don’t make someone use that. And if you code it right, if you code it carefully, if you can code the simplified interface first and then add the TypePad stuff on top of it, and really build it that way and plan it that way and letting someone fall back to the less flashy interface, is still a viable option for you. CHUCK:  So, you’re talking about testing all of this stuff. How do you do that? Do you go and install the accessibility software on your machine and point it at whatever it is that you’re trying to test? Or are there particular techniques that you can use to test them? BRIAN:  Yeah, how do you test? Well, it’s not going to be like unit testing, that’s for sure. It’s not going to be an automated process, that’s for sure. That’s the roughest part. So JAWS, from Freedom Scientific, is one of the most popular screen reading software out there. And they have a demo version that runs for about 40 minutes or so, and then you got to restart your computer and you can run it for another 40 minutes. So, it’ll pretty much run indefinitely, and that’s kind of their answer to, “How do I test websites?” Their answer is, “Go download our demo version and run it until its time expires and then reboot your computer.” AJ:  Isn’t there a site where you can purchase a type of user to test something? It seems like there would be a place where you could hire a blind person to test your site. BRIAN:  Yeah, and I believe there’s lots of different places like that. I have some people that I know personally that I can have them test things for me. But again, that’s great when you’re done. But what do you do while you’re developing? It’s just like everything else, you don’t want to spend a whole afternoon, and you’re doing up your CSS and stuff, and at the end of the day pay someone to look at it in a browser for you. You want to be able to, at least at some point, do this yourself as you’re going. Because (a) I think that it’s something that you want to do as a developer anyway, but (b) it’ll help you get a little bit more insight and empathy into what’s going on. Try to use your site with a screen reading software. If you have a Mac, just try to turn on VoiceOver. See how far you get. VoiceOver is by far not the greatest technique out there for testing stuff, but it is a technique and it will give you some fascinating insights into how some of this stuff actually works. Plus, you have to remember that a person who is using a screen reader is going to be much more proficient at using the screen reader than you are. So you have to kind of take your own downsize that you come up with, with a little bit a grain of salt. So, it is a good idea to try to find some real people with some disabilities that can test your stuff out. JOE:  So, what about when you’re going to do a project and you do want to make it accessible? Maybe you’re going to take a measured approach and not do everything, but you do want to do some stuff, but just knowing what you can do and what’s going to be achieved and what’s going to get expensive in the list of all the things you could do and need to worry about. Most developers, I’m sure, don’t even have a clue. Is there like a checklist? Is there some place you can go so you can see, “Well, if I just do these five things, I’ve already majorly increased the accessibility of my site,” over what I would have been without doing anything? BRIAN:  There’s a couple of resources that I typically point people to. The first one would be the site, the WebAIM site. So, that’s webaim.org and they’ve got a lot of good resources on there. But there’s also the WCAG, the Web Content Accessibility Guidelines, and if you can follow those, that’s a pretty good start. It’s a pretty good checklist. But the other thing to think about is if you’re building something, and this is actually where a lot of my work goes, is if you’re building something for a government agency here in the US, and that’s for any agency that receives Federal dollars, really. Then there’s another thing you want to look at, which is Section508.gov, because that’s actually the Section 508 of the Rehabilitation Act that covers, there was an amendment to it back in 2001 or so, that covers exactly what you must do for accessibility for these types of sites. And it’s very specific. Now, Section 508 is supposed to be getting an overhaul, but it just seems to be stalling. And so, it’s a bit eye-opening when you look at the types of restraints you have for working on these types of sites that receive Federal dollars. But that’s a couple of good checklist you can do when you’re just trying — you want to try, you want to start down that path. CHUCK:  So, we’ve been talking a lot about people who have vision impairments and I think for a visual medium like the web, I think that makes a lot of sense. But you have mentioned some of the other disabilities such as, let me think here, you talked about mobility, things like that. What do we do for some of these other folks, like mobility impairments and things? BRIAN:  Yeah. Well, let’s think about what we’re doing right now, we’re making a podcast. How does a person with a hearing disability participate in this podcast? CHUCK:  They read the transcript. BRIAN:  There you go. And that’s another thing to think about. If you’ve got a really cool demo video of your awesome new startup-y website, do you have a transcript for that? Can you put one up there? Can you make it just a little bit easier for people to participate in that content? That’s kind of the number one thing you can do for the people with the hearing impairments. And for the motor impairments, that’s the same kind of thing. We talked about the head wands, but their issue is it’s harder for them to hit those targets. If you happen to have a lot of links inside of a paragraph that really aren’t easy to hit, and I see that happen in blog posts a lot where they have a whole bundle, they’ll make each word a link for some reason, and it’s really hard for a person with a want to tap on the right word. So again, it comes back to thinking about what issues they’re going to have and thinking about them before you go and do something other than trying to figure out after the fact. JOE:  I can’t tell you how many times I’ve been aggravated by poorly designed sites that are hard to hit with a mouse, with somebody without any motor disabilities. BRIAN:  Yeah, and it comes back to if we pay attention to accessibility as a whole, which means access for everybody, then we make the experience better for everybody. Another thing to think about is the color blind. People with the various types of color blindness have problems distinguishing between certain colors. And if you’re trying to use color as a way to draw someone’s attention to things, it’s a pretty good idea to have another way to draw attention to that also. And it’s typically where the idea of, not only do we got to make the text red, but we’re also going to put little asterisks. One of my favorite things is the built-in way the Rails framework handled the form validation that’s built into, when I saw the first scaffolding video. Because I thought, okay, I know a lot of developers are going to hate that because not only does it list the things that are wrong on the top and then it outlines all the fields and I know a lot of developers are going to hate that. But when I first looked at that, that’s actually how the Section 508 guidelines want you to do it. They want you to give a summary description at the top of the form of all the things the user did wrong. And then, you have to mark individual fields. And so, that’s a great way of doing it, with color and without color. CHUCK:  Yeah, that makes sense, the with color and without color. And speaking of hearing impaired, I’m really gratified now that we have all the transcripts for pretty much all of the episodes of all of the shows that we do. At least, we’re doing some of this stuff right. But one thing that I want to point out here is that you’re making it sound a whole lot easier than I thought it would be, because I kind of had it in my head that this was this kind of scary, daunting thing and you have to do this complete overhaul in order to make it work for accessibility. But it seems like most of the things that you’re talking about are relatively simple things to just be aware of as you put your stuff together. BRIAN:  Yeah, that’s the hardest uphill battle with this. This is why books on accessibility don’t sell well, because people here go, “I’m scared,” or, “It’s going to be a lot of work,” or, “It’s going to be too expensive,” and it’s really not. It really comes down to empathy. That’s really what it comes down to. Every time I talk about this at a conference or wherever, that’s what I start off with, is empathy. Let’s talk about the difficulties that people have. Let’s think about the difficulties they have, so that those could be in the back of our mind when we go through these things. And one of the disabilities that we don’t really think about too much that does happen to cause grief for people is, the people with cognitive or learning disabilities. Is the text on your page, is it spell-checked? Is it grammatically correct? Is it easy to follow? What’s the reading level of the text on your page or the copy? Is it easy to follow or is it full of a bunch of big superfluous words? Because you have reading comprehension issues, you have people with dyslexia. The type of font that you choose might make it harder for someone to pick out the words. And so, those are the kinds of disabilities that we don’t really think about too much, but it also causes problems for people. And just by being aware of those types of things, as we’re writing our copy, we might think about that, “Oh, do I really need to use this word or can I use a simpler word to describe what I’m doing?” Or, “Hey, did I spell-check this?” Because not only is going to make it hard for someone with dyslexia if I spell things wrong, but it’s also going to make the screen readers trip over themselves when they try to interpret the words. So just thinking about those things, that’s where most of the upfront work comes from. Now, there’s, of course, going to be some technical challenges and going to be some things that you’re just not going to be able to do. But any step you take is better than no steps at all. CHUCK:  Yeah. And I mean, you know, reading level to a certain degree may have something to do with your intended audience. But everything else that you brought up, I completely agree with. And the thing is, it doesn’t just make it hard for people with disabilities to read, because I don’t have a learning disability that, at least not that I know of, but you know… JOE:  I beg to differ. CHUCK:  [chuckles] Yeah, thanks. Anyway, but at the same time, if I’m reading a blog post or page content and it’s misspelled and things, it trips me up. AJ:  Same here. CHUCK:  I understand what you’re trying to say and I understand the message you’re trying to get across, but I have to stop and start every time I see something that I don’t expect to encounter, such as a misspelled word. And so just in general, you should, I think for people without disabilities, you should be doing that. But the tools and people who have comprehension problems where they look at the word and if it’s misspelled, it makes it entirely impossible for them to discern. Yeah, you just don’t think about a lot of those things but they’re definitely things that we need to take into account when we’re building these things. MERRICK:  Yeah. I think that programmers are probably tend to be more towards the autistic and of the spectrum, and that makes it more difficult for us to discern words that aren’t spelled correctly because we have to reanalyze the context, perhaps more than some other people. I have that happen all the time. CHUCK:  The other thing that I wonder a little bit about is you have pages that are highly interactive pages. So static text, it seems pretty straightforward that you know, your screen reader, you could zoom, or however you deal with that, you have a method for coping. But some of these pages are becoming highly interactive. And we’re seeing these rich frontends. And so, the DOM elements may not even appear on the page in the order or arrangement that they’re actually in if you read the source for the page or load the DOM itself. So, how do you deal with that kind of thing? How do you make those pages accessible? BRIAN:  It comes back to those things the ARIA Live roles where you can actually specify this region of the page and its children are dynamic and they will change. And so, the screen readers are supposed to be able to then subscribe to that section of the page and alert you that elements have changed in there. Now, it sounds like it’s highly complicated but this is actually kind of a solved problem for other areas of the user interface. Microsoft Word, for example, is a pretty highly graphical program. And it’s very interactive, and yet people can use JAWS and other programs to interact with that. People can use JAWS voice commands to manipulate things in Windows. And they can maximize Windows and run programs and launch things. And they can be very proficient at that. It’s just that we don’t really have good adherence to web standards as it is. One of the things that’s always kind of surprising is that there’s been this, for the last ten years or more, there’s been this push of ‘don’t use tables for layouts, don’t use tables for layouts’. And one of the reasons was that it’s a bad idea. The other reason was that it’s an accessibility issue. Well, here we are ten years later and people are still using tables for layouts all over the place. Even so on the most popular sites that programmers go and use, use tables for a layout. AJ:  [Coughs] Amazon, [coughs] Amazon. BRIAN:  Well, I was thinking Hacker News, but that’s beside the point. The point is… [Laughter] BRIAN:  The point I’m getting at here is that the screen readers have gotten good at reading tabled layouts. They don’t have nearly the trouble they used to have. Now, it’s still not a good idea to do them, but the screen readers have been forced to adapt to it. They’re always playing catch up, but they’ve been forced to adapt to it. And if you look at the HTML5 specification, you can actually use, it says in the specification, you can actually use tables for layout if you give it the ARIA role of presentation. I don’t think you should do that, but you can. And so, when you’re thinking about where we’re going with the web, I think what can happen is if we can get more developers to think about accessibility, to think about accessibility issues, then we can get things into Chrome and we can get things into WebKit, we can get things into the other browsers to build better APIs to make things more accessible for people. But right now, we don’t have developers really being aware of the kinds of problems that people have and so they’re just pushing ahead, pushing ahead with their JavaScript frameworks and making more dynamic user interfaces for the average person. So, the more we can get people thinking about these issues, I’m a little bit hopeful that maybe we can build better ways for this to happen in the browser, just like we have built better ways for people outside the browser. I know a couple of people who are completely blind and they write software. One of them uses Xcode all day long to build applications for the iPhone and for the Mac. And he can write programs, he can write software. That’s much more difficult than a shopping cart with an automatic updating quantity, or some regions of the page changing in an Ember app. JOE:  That’s amazing. CHUCK:  Yeah, that is really impressive. One other question I want to ask you is, and I don’t want this to come across the wrong way, but I’m going to ask a very insensitive question. And that is basically, since most people are people who don’t have these disabilities and there’s only a small minority of people who are going to have some of these disabilities, when is it worth doing and when isn’t it? Or more, I guess more appropriately, can you make the case for putting this into your web application? BRIAN:  The way I always do it is, if you’re doing it right, nobody thinks you did anything at all. If you plan for it from the beginning, you’re going to make the experience better for everybody. The side effect will then be, “Oh, look, it works for people with disabilities also.” It really comes down to how difficult is it to go and describe your images better using alt attributes? How much more difficult is that? How much more difficult is it to build things that have additional ARIA roles on them? Where the developer is at a disadvantage is the developer has to work within the constraints of not only the project he or she has been given, but also in the constraints of the platform in which they’re working. If you’re building something for the iPhone, you’ve got a wonderful accessibility API at your disposal that you could use. There’s absolutely no excuse for someone who’s building and iOS application to not make it accessible. It’s so easy. And there’s so many great tools at your disposal on that platform. In the web, much more difficult, much more difficult. But we need developers to start thinking about it in terms of how can we make this better or how can we build better tools. If things like WebKit are an open source browser, then let’s get more developers thinking about how we can make this easier for someone so that people aren’t asking this question. I mean, look, how much more, if you want to open up a business, how much more easy would it be to not have a ramp for a wheelchair person? We may only get one person with a wheelchair every couple of months, but we have a ramp because the law says we have to. I would much rather have an environment where we don’t have to have laws telling us we have to do. We just do it because it’s the right thing to do and it makes things better for everybody. If I spell my content better, great! That means everybody can read it. Everybody’s reading comprehension level goes up. If I don’t just use color for everything, if I actually use words, if I put transcripts in for this videos or for these screencasts, then if I don’t have my headphones handy, I can sit there and I can read the podcast while I’m on the train or something. I can get the gist of your demo video if I don’t want to play the video right now because I don’t have headphones. I can do these types of things and the experience is better. CHUCK:  Yeah, that makes a lot of sense. And the thing is, and I’m just going to add a few things to what you said, and that’s basically, for example the ramps. I mean people look at them and they think wheelchairs, just like making these websites more accessible means the screen readers can read them more easily. But when it comes right down to it, my dad is not in a wheelchair, but he had a hip surgery go bad and he has difficulty walking. So, if there’s a ramp, he’s taking the ramp. So, it really does pay off for people who don’t have what we would consider maybe legally, they’re not legally blind, they can see some things or they can see things up close. My grandfather, he doesn’t necessarily have a disability in a technical sense, but he’s so old and he’s got issues with his eyes to the point where when he uses his computer, he’s got the resolution turned all the way down and he’s still leaned over in a couple of inches from the screen. And so, when we make these things available, we’re making it available not just to the people who have the disabilities or who can be classified as disabled, but we have it for people all along the range. And like you said, we make it available for other people to use in ways that we may not have intended but may work out and pay off for them as well. BRIAN:  Absolutely. When I got my — I was a PC person, a strong ardent PC person for the longest time. And then, 2007 a good friend of mine came to visit with his brand new shiny MacBook Pro. And he knew about my vision problem, he’s known for years. And he said, “You have to see this.” And he showed me the full screen zoom, the ability to zoom the full screen and pan around with my mouse. And it was all I could do not to just jump across and grab my PC, go and order a MacBook Pro from Apple, and then throw it out the window. I haven’t gone back since. And I use that zoom thing every single day. I use it every single day. But I’ve also used it during conference talks to zoom parts of the screen. I want to draw people’s attention to parts of the screen and I’ve seen other presenters who have no vision difficulties whatsoever come up to me and ask me how to do that, and I’ve seen them then use it in their presentations. My wife, the other day, had some teeth pulled because she’s going to get some braces and she couldn’t talk after that. And so, I showed her how to use the say command on the Mac so she could ask questions and talk. These types of things are available to us. And my dad taught blind students for many years. And he taught a lot of students that were blind because of other disabilities as well. And he would always tell me that we had to be mindful that the disabled is a club that anybody can join at any age, at any time. We need to keep that in the back of our minds too. CHUCK:  Yeah and I just want to also point out, there are a couple of features on my iPhone and on my Mac that are accessibility features that I use on a regular basis. One of them is the triple click on the iPhone. It’s handy. Basically, I can open up an app for one of my kids and then triple click. And what the triple click does is it locks it so that they can’t leave the app and go to other apps. So, that’s one thing. Sometimes, I just have one headphone in and so I’ll go into the accessibility features and I’ll say, “Hey, pan everything all the way to the left.” And so then it puts all of the audio into the left or the right and that way I can have one headphone in and be listening and have the other and then be listening for my kids out of my other ear as I’m driving down the road or something. A lot of these features, you know, you can get the LED flash for alerts, which is kind of a nice feature on the iPhone. There are a whole bunch of these that just pay off and make it easier to use for anybody. So, I think you’re absolutely right. And it’s a perspective that’s just kind of dawning on me right now which is why I’m so excited about it. BRIAN:  That’s awesome because we need to get more people excited about this then. CHUCK:  And hopefully, having this conversation will really push that ahead. So, one last thing that I want to ask you, and you may be saving some of these for your picks. And if so, you can just hold on to them. But do you have any resources that you recommend for people to go and learn more about accessibility? BRIAN:  You know, I would say study the WCAG, the Web Content Accessibility Guidelines. I’d say study those. That’s a great place to start. It’s a great place to get started. There are some pretty cool books. There’s a book from Apress, I believe, called Pro HTML5 Accessibility. That’s actually a pretty good book. And we have a book from The Pragmatic Bookshelf too called Design Accessible Web Sites. It has some good information in it. CHUCK:  Awesome. So the last thing is, and I know we’ve asked you for tips and tricks, but are there any other just tips or things that people should be aware of or take as good first steps as they embark on this journey of learning to build accessible software? BRIAN:  There’s really nothing more important than understanding the difficulties that people have. Once you understand those, I can’t say that enough, once you understand those, you can start to be more mindful about what you’re building. If you say ‘click on the green button to continue’, just stop and think about that for a moment. What does that mean to someone who can’t tell green from yellow or green from red? What does that mean to them? What does that mean to a person who can’t see the screen at all, using a screen reader, when it says ‘click the green button’? What does that mean to them? Just think about those types of things. And that will help you to drive the content of your user interface in a different direction. CHUCK:  Terrific. Alright. Well, we’ll get to the picks then. Thanks for coming, Brian. It’s been really, really enlightening, really educational. BRIAN:  This has been a blast. I love talking about this stuff, especially with developers who aren’t trying to spin the conversation trying to shoot me down. [Laughter] BRIAN:  You’d be surprised. It’s a very defensive topic sometimes. And so, I always try to approach it from the standpoint of we’re not going to make you make a site that looks like it’s from 1996 with accessibility. We’re going to say, “No, we’re trying to make this better for everybody, make this experience better for everybody.” CHUCK:  Yeah, it makes a lot of sense. JOE:  Totally. CHUCK:  Alright. Well, let’s do the picks. Joe, do you want to start us off? JOE:  You bet. Alright, so my first two picks are two games. They’re iOS games. They are on other platforms as well. They’re coming out tomorrow, which will be maybe a week before this podcast gets released, so they will already be out. The first game is called Leviathan: Warships. Just Google that and watch the demo for it. It’s like, by far, the best trailer for a game, ever. And it’s a cool little strategy game where you fight with warships and it just looks totally awesome, so excited about it, tomorrow. Then the other one is Star Command, which is basically Star Trek simulator for your iOS device. I think it’s for Android and it might also be on PC and Mac. And it just looks awesome, very comical but supposedly really great game play. So, two really awesome games coming out, great iPad games or tablet games but they also run on other devices as well, other platforms. Then my third pick is going to be the conference That Conference. No, I’m not talking about a conference that I said that, I mean the name is ‘That Conference’. Very strange name, but it just so happens that there’s a couple of people on this podcast that are going to be speaking at That Conference. And it’s really awesome. It’s held inside of a huge, huge, huge indoor water park in Wisconsin, at the hotel that has this huge indoor water park attached. And so, if you can afford to go, it’s on a variable number, a lot of different topics. So, if you can afford to go, it’s a really awesome conference. Actually, last year was awesome. I can let our guest speak more to that, but both Brian and I will be speaking at That Conference. So, registration is just opening up now, or will be very shortly and you can buy tickets. It looks just like a great conference. I’m excited to speak at it, very privileged that they chose me to speak at it. CHUCK:  Cool. AJ, what are your picks? AJ:  Well, I’m going to pick Lowe’s Never Stop Improving. [Laughter] AJ:  You might not know this, but well, if you’ve ever moved, you probably do. They have moving boxes there. And they’re like, $0.69 for the small one. But the cool thing is, if you go and try to get the same boxes for packing and shipping, like seeing the large packing and shipping box, if you go to OfficeMax or Depot or Staples or any of those, they’re like $4 or $5 a box. But at Lowe’s, they’re like $0.69, $1.50 for the different sizes. Way cool. And also, I want to pick Friends. Love them. Love having friends, love helping people out when they need help, love being helped when I need help. Got to get you some friends. If you don’t have any, you’re doing it wrong. CHUCK:  Awesome. Alright. So, my picks this time, first off, I’ve been kind of hooked on this game on iOS. It is Ticket to Ride, which is actually a board game and this is just Ticket to Ride Pocket on my iPhone, and it’s a lot of fun. I’ve been enjoying playing it against the bots. I can also play it against my wife on her phone. And then, I don’t have to set up the board or put any pieces out or anything like that. So, really been enjoying that. Another app that I really like on the iPhone is called 4 Pics 1 Word, and it shows you four pictures and then you have to figure out what the word is that they all have in common. Some of them are really tricky and some of them aren’t. But it’s a fun game. And then, the last one that I’m going to pick is a TV show I’ve been watching lately, it’s called Continuum. It’s on the Syfy channel. I’m about six or seven episodes in. It’s not the best Syfy show I’ve ever seen, but it’s an interesting one and I’ve been enjoying it so far. So, I’ll put that out there and you guys can go watch it. It’s on Netflix, that’s where I’ve been watching it. And Brian, what are your picks? BRIAN:  Oh boy, my picks. First of all, I got to say that That Conference was actually the first pick I had, because the registration starts up on May 15th and everyone should go because it’s going to be awesome. And it’s family friendly too. Since the water park you get, you’re going to stay at the hotel, you get your free passes at the water park and it’s just great to be able to go to a conference, bring your family, bring your kids. And there’s other people there, other developers with their families and their kids. And so, that creates a really cool dynamic too. Definitely go. There’ll be some awesome presenters, awesome keynotes, definitely check out the site ThatConference.com. One other pick is I’ve been spending an awful lot of what free time I have playing with AngularJS. And wow, that’s a framework that’s got me excited. I haven’t really been this excited about a framework since I started playing with Rails in 2005. It’s just making a lot of the things that I have to do much easier. And I’m spending a little bit of my time looking into how it works for screen readers. Yeah, there’s some work to be done. But I think some of the things that I want to do to make sites that are dynamic yet accessible are going to be fairly easy to do with Angular. So, I’m very excited about that. And lastly, one of the things I want to bring up is, there’s a program that I’ve been using for about maybe four years or so for my iOS devices. It’s called Presentation Manager from a company called Woojijuice, I guess. But it’s a Keynote remote, it’s for the Keynote presentation software. But you can really get a good handle on your presenter notes in the palm of your hand. You can see your notes, you can change slides, you can blank the screen, you can control the computer’s audio. And it has been just this wonderful tool that I’ve used for almost every conference talk I’ve given since I started using it. I use it in my classrooms. If you do a lot of speaking and you really want to have some good control over the presentation in the palm of your hand, it’s a great app for that. CHUCK:  Awesome. Alright. Well, that’s the show. I just want to point out too that due to all of our listeners listening, if you go into iTunes in the US store and you look in the top podcasts, I believe JavaScript Jabber and Ruby Rogues are both in the Top 50. So, thank you all for all of your reviews and ratings in iTunes. If you leave us more, we’ll move up. And we really appreciate that so we can get the word out on these kinds of episodes. But whatever the situation, thank you all for being terrific listeners and we’ll catch you all next week.

x