119 RR Accessibility with Brian Hogan

01:39 - Brian Hogan Introduction

02:09 - What Accessibility Means

06:50 - Making Things Accessible

Transcripts
Video Scripts & Captions

08:35 - Is There a Downside to Making Things Accessible?

Disabling JavaScript

11:28 - ARIA Roles

15:19 - Keyboard Shortcuts

17:50 - Assistive Technologies

24:25 - Accessibility Awareness

058 JSJ Building Accessible Website with Brian Hogan
Sympathy vs Empathy
Pixels vs Relative

29:16 - Tools

35:04 - Web Innovation and Accessibility

Infinite Scroll
URL Changing

39:26 - Backend Technologies

41:42 - Internationalization & ESL

45:29 - Accessibility for People with Cognitive Impairment

47:38 - Hearing Impairment

48:30 - Documentation

50:07 - Accessibility in Apps

53:45 - Accessibility Audits

54:57 - Framework Improvements

59:35 - Accessible Websites

01:01:16 - Resources

Next Week

Book Club: Understanding Computation with Tom Stuart

Transcript

CHUCK: I had a weird dream last night, Avdi, that you were marketing hair care products along with your Ruby Tapas. [Chuckles] AVDI: Interesting. JAMES: That’s a brilliant idea, actually. “Take in some confident code and while you’re at it, this nice shampoo and conditioner package.”[Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.] **[This episode is sponsored by JetBrains, makers of RubyMine. If you like having an IDE that provides great inline debugging tools, built-in version control, and intelligent code insight and refactorings, check out RubyMine by going to JetBrains.com/Ruby.] ** [This podcast is sponsored by New Relic. To track and optimize your application performance, go to RubyRogues.com/NewRelic.]**[This episode is sponsored by Code Climate. Over one thousand organizations trust Code Climate to help improve quality and security in their Ruby apps. Get 50% off your first three months for being a Rogues listener by starting a free trial this week. Go to RubyRogues.com/CodeClimate.]****CHUCK: Hey everybody and welcome to episode 119 of the Ruby Rogues Podcast. This week on our panel, we have James Edward Gray. JAMES: I’ve stopped listening to the new civil wars album long enough to record this episode. CHUCK: Avdi Grimm. AVDI: Hello. CHUCK: **David Brady. [Silence] Josh Susser.JOSH: I think David’s off solving The Halting Problem. He’ll be right back. CHUCK: [Chuckles] I’m Charles Max Wood from DevChat.TV. We have a special guest this week and that’s Brian Hogan.**BRIAN: Hello. CHUCK: Do you want to introduce your self really quickly, Brian? BRIAN: Sure. I’m Brian. I teach people how to make stuff on the web and I make stuff on the web. CHUCK: Awesome. Now you’ve written a few books. You wrote the tmux book, if I remember, and you review a lot of the Prag books. I see your name on a lot of them. BRIAN: Yeah. JAMES: The tmux book is amazing. BRIAN: Oh, thank you. DAVID: Yes. JAMES: Love that book. CHUCK: Awesome. You’re an expert, at least more expert than me, on accessibility on the web. We were hoping that you could explain to us things that we have to do in order to make it more accessible, I guess, to people who have trouble using it one way or the other. JOSH: Can we get a definition? What is accessibility? BRIAN: Well, there are a lot of really bad definitions of accessibility and a lot of them focus on people with disabilities. The definition that I always use with people is ensuring that the website or web application that you’re using is available to anyone who wants to interact with it. That encompasses not just people who are blind who have to use accessibility technology like screen readers to read the page, but it also deals with people on mobile devices that are on slow connections or people on small screens or people with motor impairments, all kinds of things like that. That’s how I like to look at accessibility because on the one hand, I think it’s a better definition because we have much more diverse people we can target but also because it’s a little bit easier sell to people. It’s sad that I have to say that. But it’s a little bit easier to sell to people to say, “You’re not just focusing on the 10% of your users or the 5% of your users that are low-vision or blind or hearing impaired. You’re focusing on a large percentage of people who may live in rural areas with bad network connections and things like that.” A lot of these things that we can do to serve one audience serve all the audiences. Some of the things we hope to talk about today are those kinds of things where a slight change that makes things better for someone who has a cognitive reading disorder make things better for people who use a screen reader. Then of course, it makes things better for everybody else, too. JOSH: Yeah, I remember when the ADA, the Americans with Disabilities Act was first being implemented and there were a lot of complaints about it. Then fully-abled people suddenly started noticing that it was easier to transition from the street to the sidewalk because they had these curb cuts for people on wheelchairs to use. It makes things easier to use for everybody. BRIAN: What I want to see as an industry, we have these guidelines like Section 508 which govern pretty specifically what organizations that receive federal funding have to do for their websites. But it’d be much better as an industry if we didn’t have to have that kind of involvement, we didn’t have to have some laws get passed because we weren’t taking care of ourselves. It would be much better if we could just say, “Hey, let’s make our stuff accessible so someone doesn’t come up with guidelines.” Right now, these Section 508 guidelines that you have to follow if you receive federal funding from the US government, they’re really out of date. They’re supposed to be renewed and they’re supposed to be updated but they keep getting stalled on it. These agencies that have to comply, they really, really have their hands tied in a lot of cases. DAVID: How out of date are we talking? Is this like a teletype? BRIAN: 1999? DAVID: Wow. Okay. JAMES: Has anything changed in computers since then? BRIAN: Well, think about it in terms of what we do on the web right now with a lot of JavaScript and things like that. Think of how much the web has changed since 1999. JOSH: And mobile. BRIAN: And mobile. And you’ve got certain things that you’re just not able to do. Now thankfully, there was some forward thinking in a lot of those things. So you can bend the rules a little bit and you can make your stuff comply. But still, there are certain things in the new proposal that are going to be much better for us. If we could just do this on our own as a developer community, embrace accessibility, understand accessibility, understand that the needs that people have, we wouldn’t have to find ourselves in a situations where we have to comply with grossly out of date legal requirements. JAMES: That’s a really good point. Even people building new places of business and stuff, they should efforts to make their shops not just meet the minimum requirements of accessibility but to make them convenient and pleasant to be in. If you have certain issues, that’s just a good idea anyway. BRIAN: But we’re a lot of times focused on delivering the product really quickly, proving that we have a viable product, things like that. A lot of people think that, “Well I don’t have time to do accessibility.” I’ve always argued, because I’ve been doing this stuff since 1998 or so with accessibility. I’ve always argued that it actually isn’t that difficult to make things accessible if actually plan for it from the beginning, if you think about it. It’s like anything else. If you build a rails application and you just code and code and code and code and code and code and all of a sudden you can’t scale and you can’t update things because you didn’t think about how to design that from the beginning, yes it’s going to be a much more costly effort for you. But if you know about those types of things and you know how to organize your code, you know how to abstract your code from the framework and all those kinds of things, then it can be a much smoother experience for you. The same thing holds true for things like accessibility. If you understand that when you’re creating your content, you need to plan for those types of things ahead of time, it’s going to be much easier. One of the first examples that I give people, this podcast has a transcript and that’s amazing. That’s a wonderful thing to have, because that’s good for the people who are hearing impaired and that’s good for people who are visually impaired. It’s good for people who just are on the subway and don’t have headphones and they just want to read the transcript because they can read faster than hearing a bunch of people talk. It’s good for a lot of different people. If you’ve done a podcast, then you’ve got to transcribe it yourself. That costs money and it takes some time, but it’s worth the end result. But if you’re preparing a video like a screencast, or if you’re doing some kind of a promotional video for your website, then you’re preparing that content. You probably have a script. That makes the transcription process easier. It’s amazing to me how many times I go out to a site and I see nothing on the homepage other than a video and there’s no transcript, there’s no captions, there’s no anything. But I can tell that video was prepared ahead of time. Somebody could just put the script out there and make it available for someone to read that. JOSH: Yeah. So Brian, aside from the extra effort that it takes to make things accessible, is there a downside? Are there things that you have to compromise how you do them that get in the way of doing accessibility? BRIAN: You know, I think maybe five years ago, that was true. Five years ago, it was, “Don’t use JavaScript. Have a fallback solution that will work with JavaScript turned off,” because at the time, a fair amount of people were browsing the web who were using screen readers. They were turning off JavaScript in their browsers intentionally because there were so many sites that didn’t do it right, so a popup would happen. This actually happened on Twitter a couple of years ago and I actually have a video on my blog about this. I used a voiceover on the Mac and showed that I got lost using Twitter using a screen reader. A popup, it would come up and then the focus would be completely lost and the person would be stranded. They wouldn’t be able to figure out how to navigate away from that popup. The simple solution, if you’re going to all of these newspaper sites and other places that constantly have these popups that get in the way of your content and make you lose focus, is just disable JavaScript entirely. Then of course, you go to a page that requires you to use JavaScript and now you can’t interact with that. So the conventional wisdom was make sure you have a solution that works without JavaScript. Now, you fast forward and the screen readers have gotten a little bit better. The assisted technology’s gotten a little bit better. The number of people who disable JavaScript 100% is much lower than it was. I’m still of the mind that as a developer, especially working with things on Rails, because the default stack handles testing controllers and things like that without JavaScript already, that’s still how I develop. I still develop things with regular gets and posts and stuff like that. I know that all my underpinnings and stuff work. Then I’ll go and build the JavaScript layer on top of that. I still develop that way, but it isn’t nearly as much extra effort as it may have been in the past. You certainly don’t have to compromise on how things look. You certainly don’t have to compromise on how things work, especially with a lot of the advances that html5 has with the ARIA landmark roles and the live regions and a lot of the other attributes that you have. Even things like the jQuery widgets are starting to implement those additional ARIA roles that tell you what the state is. It’s an open state or a disabled state or it’s a required form field, those kinds of things. The screen readers can use those additional annotations to really help users out. Now, not all of the screen readers are using these things. They’re not able to interpret those things. But it is nice that we’re getting to a point where we’re even seeing frameworks like Ember and other frameworks actually actively putting these ARIA roles into the code, the boiler plates that they use and into the widgets that they create and things like that. JOSH: Okay. So there was a lot in that answer right there. BRIAN: Yeah. We’ll need to break it down, yeah. JOSH: Yeah. Can you talk about ARIA roles? I’m familiar with these, but probably not super familiar with them. BRIAN: You’ve got this specification. It’s the Accessibility for Rich Internet Applications. It’s essentially a bunch of additional attributes you can add to html5 documents. You can use them to better describe your content. One of the nicest ones is a thing called aria-live and you can use the values that can be polite or assertive. That basically says, “I have a region on my webpage that’s going to update with AJAX. I need to let the user know when that content has changed.” If you think about how a screen reader works, it’s going to read the document and then if you’re sighted, you’re going to see the content in the middle of the page changing. You’re going to see that content. But how are you going to know if you don’t see? How are you going to know that that content has changed? Well the aria-live role that you can add to an element, say you have a list, a bunch of list items, you can add the aria-live attribute to that and it’s aria-live=polite. The screen reader will monitor that region of the page. It will alert the user of the screen reader that that region has changed. That’s a really, really powerful and effective thing. You can do it using the polite. The reason we recommend using polite is so that it doesn’t interrupt what the screen reader’s already reading. The polite value for that will say, “Okay, screen reader. This is new but you can wait. Finish up what you’re reading and then alert the user that content has changed.” If you use assertive, it will interact a little bit more quickly. There used to be one that was even more like, “I will stop everything that’s going on and I will interrupt everything that’s going on and I will tell the user that things have changed.” That’s one. Then you have ARIA landmark roles which you can use to say, “Okay, this is the heading of the page. This is the navigation of the page.” Those somewhat overlap with some of the html5 tags that are out there, but there’s a lot more of them and they can be used in screen readers to help the user navigate around the document much more easily. Then on top of that, you have some really nice things. You have aria-describedby and you have aria-required. Those are things that can say, “Well I have a table and I need to be able to give a summary of the table.” You can say that the table and you can use aria-describedby and you can point that to a paragraph tag that describes the table. So when assistive technology is looking at the table, you can give extra information to the person who’s using the assistive technology about what that table’s all about. There’s a ton of things to look at that you can sprinkle throughout your application that can really improve things. You can use these ARIA roles to help with tabbed navigation so that you can more easily say, “Look, this tab is open. These other tabs are closed.” There are a lot of things like that that you can take advantage of. JOSH: I’ve seen some people try and do CSS styling with the roles as attributes. We were talking earlier about, “Oh, accessibility can make things easier for everyone.” Is there something that browsers are smart about with roles that make them useful for styling for everybody? BRIAN: **Sure. If your browser supports CSS attribute selection, that’d work because they’re defined as attributes on the element. If you’d use like, “Oh, this is [inaudible] email.”**JOSH: But there’s nothing intrinsically special about them BRIAN: No. JOSH: In terms of how the styling works? BRIAN: No. JOSH: Okay. JAMES: What about other measures like, I find myself as my disease progresses and I’m slowing down I find that I value things like keyboard shortcuts way more than I used to, because the simple action of going for a mouse and getting it to the menus and getting where I want it to go just is taking me too much time. I just prefer to memorize the key stroke and trigger it that way. What other measures like that can be done? BRIAN: Thankfully, a lot of those kinds of things are much easier to do now with JavaScript libraries. But the trick is to ensure that the keyboard shortcuts you do create don’t interfere with the keyboard shortcuts that a person on a screen reader might use too. For a while, I advocated using the access key attribute in html and that just doesn’t really work well in practice. So you typically rely on JavaScript solutions. Again, that’s great for a lot of people. A lot of people like keyboard shortcuts for things. A lot of people like to use this. I think that they’re especially handy for people who have trouble using the mouse. We have people who can’t hold their hands still or they only have one hand or they have to manipulate the computer using other methodologies. Shortcuts and other ways of interacting are very handy for that. But we have to be very careful when we do these shortcuts because if we’re relying on JavaScript events to fire things off, we have to make sure that we tie those into the right event handlers. We don’t want to tie them into the wrong event handler and have them not work. That’s one of the trickiest parts about accessibility, is that we can have automated unit tests and we can have automated acceptance tests and all these wonderful great JavaScript testing things, but a lot of the stuff with accessibility comes down to getting some people to use the site and actually running through the site with people, running through the application with people. JAMES: Yeah, that’s a really good point. It’s not really something that’s easily automated, I don’t think. You talked about how it benefits everybody. I have two roles. One as a disabled person where I find keyboard shortcuts helpful because I’m slow and two as a power user of many technical things where I find keyboard shortcuts helpful because I’m that power user. So it does help in that aspect, too. JOSH: So you’ve talked about ARIA roles and we’ve talked about screen readers. What are the kinds of assistive technologies there that people should be aware of? BRIAN: One of the ones that a lot of people aren’t really aware of is for people who don’t have the ability to use a mouse and a keyboard, there are other devices. One of the devices they can use is a wand that’s attached to their head. So they can use that and actually use it in a touchscreen panel. They can tap the screen and tap the element on the screen. That’s a lot like using your finger on a tablet. We as developers can empathize with how difficult that must be to click on things that are maybe too close together, click in little mystery meat icons that just have the icon, don’t have any words. The click target for those is much, much smaller. JAMES: The perfect example of that, in my opinion, is I think it’s iOS 4, the music buttons when you would just bring them up via the home button. They’re terrible. All the time, I would go to pause something and I would skip ahead in the thing. If it’s an audiobook, you jump a massive amount of time and getting back is horrible. BRIAN: Right. So imagine doing that with a very large stylus attached to your forehead on a computer screen. JAMES: Exactly. BRIAN: And that’s a way that people interact with the computer. Another way is there’s a tube that you can use and you suck and blow into the tube and it actually moves the pointer on the screen. That’s another difficult way of moving the mouse. It works, but it’s difficult. Little things like ensuring there’s enough space between links or ensuring that click targets are large enough at a significant distance to do these types of things, those go a long way. They go a long way for everybody because as you get older, your vision’s going to deteriorate and you’re going to have a hard time using that mouse to find that cursor to click on certain elements in the page, too. You’re going to wish that the elements were a little bit bigger for you to be able to click on them. JOSH: **Oh jesus, not some day for some of us. I can’t tell you how sad I am that most web developers are in their 20’s. The penchant for putting light gray on a light gray background at 10pt font size, [Chuckles] it’s like, “No!”**BRIAN: That’s one of the contrast issues that I wish would really go away in modern web design, is this, “Oh, I don’t like your comment so I’m going to display it with some CSS that lightens the text so much that it’s barely readable.” JAMES: Right. BRIAN: Maybe I want to read that comment anyway. JAMES: I don’t know about how everybody else feels about it, but I know that the tendency is to keep things where we can fit as much as we can in the interface. But whenever I go to a site that’s minimal and the font is blown up huge and everything, it relaxes me. I have less to worry about. It’s easier to take it in. I just find that soothing. BRIAN: There’s a lot of science behind that. There’s a lot of science behind typography and how that can influence, just like there’s a lot of science behind the colors that you choose. There’s a lot of science behind that. One of the recommendations is that you should not have any text below 16 pixels, so 16px. Of course, that sparks the big argument of, well should you use relative units or should you use pixels? DAVID: Relative. BRIAN: I’m going to argue until ever that pixels is probably the better way to go, because I’m a low-vision user. I think I can speak from a platform of a little bit more authority on that than someone who has perfect vision can. But when I’m using assistive technology on my computer, I’m not increasing font sizes. I’m increasing the whole screen. DAVID: Oh, interesting. BRIAN: Because the images that you put on the page don’t resize. And people are invariably putting text and information and graphs and all that kinds of things inside images. So the learned behavior that I have for browsing the web is I zoom the whole thing. JOSH: I do that too. The Ctrl zoom on the Mac is great for that. BRIAN: Yeah. I zoom the whole thing. JAMES: **Until you trigger it by accident. [Chuckles]**JOSH: Well, sure. BRIAN: But that’s the thing. What bugs me about this is that people get so militant about, “No, we have to use relative units because accessibility,” and I’m thinking that was true in 2003. But the browsers have changed their default behavior. Ctrl + on Windows used to increase the font size. Now it increases the whole screen. It increases everything. It’s a full browser zoom. DAVID: Interesting. BRIAN: It isn’t the case anymore. If you look, there’s actually a thread on the Twitter Bootstrap forums about people requesting that Bootstrap changes from pixels to ems for their measurements and the Bootstrap guys are like, “Eh, it causes more trouble than it’s worth.” And it does. It causes a lot more trouble than it’s worth because you have to do unnecessary math to figure out how you’re going to make sure that the things reflow around your images. This is something that people are just going to argue about. It’s almost a holy war with this. But my feeling on this is if you’ve got images that you’ve brought in from Photoshop and videos that you’ve brought in that are all in pixels, size your text accordingly, make it readable and focus your efforts on making other parts of the website accessible. JAMES: That was a really good point you made about charts and graphs and stuff having lots of text embedded in them so those particular elements not being readable. I think it’s also good to think about the alternate forms of those data. BRIAN: The thing that ends up happening is a lot times, the text changes but now I lose my reading position because things have jumped around the page now. That happens a lot. That’s something that you can mitigate. But again, what’s the simplest path? What are your users doing? If you can poll your users and figure out how they browse your site, that’s great. Some people do set up default font sizes on their computer for their browser style sheets and that’s another issue that you have no control over as a developer. So that’s why I say always my advice is to focus on other areas of accessibility. If you have a chart and graph on there, you need to provide that information in that chart or graph in some other format as well so that people can get that information that’s important. If it’s important for you to put it on the page, it’s important enough for you to make it available. JOSH: Yeah. That’s a great point. The thing that I think we just have to get to a point with some developers that they’re not actively being hostile to people who want to bump up the font size. Like AT&T, their website for years was they use tables for all of their positioning. If you do the wrong CSS with tables, you can’t zoom them. So I would hit command +, command + and nothing would ever happen and I couldn’t actually read any of the text on the AT&T webpage. Are there are other things like that? BRIAN: **Sure. [inaudible] see now, that wouldn’t really be a problem because that’s going to do a whole page zoom instead of a font change.**JOSH: Yeah. BRIAN: That’s the thing. That’s what I’m saying, is that things have changed. They’ve changed, in my opinion, much for the better. Yes, you have to scroll sideways, but I can tell you, if you’re a low-vision user, you’re probably already doing that. CHUCK: One other thing I just want to jump in here with is that I was very not aware of a lot of this stuff until we had the discussion on JavaScript Jabber about accessibility on the front end. It was really funny because it was like, “Okay, well I need to go make friends with people who use these assistive devices so that I can understand.” It harks back a little bit to the diversity discussions that we’ve had on this show where you don’t really know what the problems are if you’re in the majority of people who don’t have those problems. So just understanding that, talking to you Brian, or we had a chat at the retreat with James about some of the things that he has to do to make things work for him, just understanding that and talking to people and really getting it, it makes a huge difference. It’s like, “Oh, well then I should put these kinds of features in or do these kinds of things because that’s what their tool or their technique allows them to cope with it better. BRIAN: And that’s the whole idea behind sympathy versus empathy. You can write much better applications, you can write much more accessible applications if you have empathy. DAVID: Yes. JOSH: **Yes! Yes! [Laughter]**JAMES: I just started cracking up when you said that because we had a long debate JOSH: It was like a half hour conversation. JAMES: **at the Ruby Rogues on the definition of sympathy versus empathy. So when you said that, I just started cracking up. It’s great. [Chuckles]**CHUCK: Yeah. JAMES: It’s really great. JOSH: Not to distract from your point. Yes. DAVID: **Hang on a second, I’m tweeting something. [Laughter]**JAMES: Brian settles the argument. DAVID: No, that’s actually a really good argument, because like you said, pixels versus relative and I’m like, “Relative,” and the reason why is because I’ve been burned by websites, by blogs that actually have in the CSS font-size: 10px !important. I’m like, “I can’t resize it. I can’t read this freaking thing.” Well that was three years ago. Now you’re saying, “You know, Dave, if you weren’t actually fully-abled, you would be in touch with this community more and you would know that this is no longer a problem.” BRIAN: It’s weird because it all comes down to the tooling that you use, too. If you’re choosing to use an IE 6 browser that doesn’t have that kind of zoom, and in a lot of cases it isn’t even a matter of choice. A lot of times, for the low-vision users, for example my dad has the same eye condition that I have, and he was a Windows user for a long time and I was a Windows user for a long time. Around the same time that I bought my Mac and discovered that, “Wow, Macs have a beautiful full screen zoom built-in,” my dad had to go purchase a program for his Windows machine called ZoomText which costs $400. DAVID: Wow. BRIAN: Look at the price of a computer and the screen reading technology that it takes. You need a very, very powerful computer to run a screen reader fulltime. It’s very expensive. DAVID: So Windows is a much better platform. BRIAN: It’s very expensive for someone who’s blind to have a computer that uses assistive technology so they’re not going to be updating to the latest version of the screen reader and they’re not going to be updating their browser to the latest version because that might break something. So we do have those issues out there. We do have some segment of the audience who simply cannot afford to be on the latest and greatest technology. DAVID: **But Windows is the better platform to profit from disabled or less-abled people. [Laughter]**BRIAN: **I have no comment on that. [Laughter]DAVID: Because you have empathy. BRIAN: [inaudible] For Christmas, I bought my dad a Mac.JAMES: Nice. CHUCK: I was going to say Dave, you almost sound like you’re looking to implement some profitable empathy on Windows. DAVID: Profitable empathy. JAMES: He has been job hunting. CHUCK: [Chuckles]**JOSH: Hey Brian, I have a question about tools. Are there tools to help developers discover where they may be weak in terms of accessibility or to help them craft more accessible solutions? What I’m thinking of is there’s the w3c validator that you point it at your webpage and it will tell you where you’re in standards compliance. Is there something like that for doing ARIA? I know that the validator will tell you when you’re missing alt tags on your images. BRIAN: Okay. First of all, I’ve got to stop you. Can we please say alt attributes? JOSH: Yes. BRIAN: They’re attributes. JOSH: **Yes. Yes, okay. [Chuckles]**JOSH: That’s just my brain on automatic. BRIAN: Yeah, I know. It’s just one of those things like, “Wait, they’re attributes.” Yeah. There are a few interesting tools out there. I’m going through my list here. I know it’s here. But the first line of defense, to be honest, actually is the validator because if you have things that have to interpret your page, then your page better be well-formed. Even if it’s html, it still better be valid. You better make sure that things are closed appropriately and things are scoped appropriately. JAMES: That’s great. BRIAN: **That’s the first line of defense. I can’t tell you how many problems I’ve seen that solve, because an invalid document then means that you’re going to be writing lots more CSS rules that maybe you don’t need because your browser’s acting goofy so you fix it in the CSS. Meanwhile, the document is invalid. You’re in a Rails application for example, your template might be perfect but then there’s content that a user has injected into the page through a CMS that you’ve built or something. All of a sudden the page is invalid and now you have weird CSS going on. What do you do now? There are some tools from WebAIM that you can use, that you can look at. There’s a nice checklist over at WebAIM that you can use and that’s the checklist that I follow when I’m looking and I’m doing an audit. I do occasional accessibility audits for people. It’s usually, “Hey, here’s what you should fix.” One of the trickiest things about this whole topic is you don’t want to come across as hostile to the developers either because they’ll just immediately shut down. You want to say, “Well here are some improvements we could make. Here are some things that you could do differently.” There are some automated tools. There’s a great tool for Mac and Windows called Color Oracle that you can run and it will just take the screen that you have currently in front of you, this is great for not just web apps but for anything you’re developing, and it will show you what the thing looks like through the various types of color blindness. It’s just a little menu bar item. You just click the color blind type you want to test for and it just changes the whole screen and you can see the color blind [inaudible].**JOSH: Yeah, I love Color Oracle. I think that was one of my picks a couple of months ago. The only nit that I have with it is that it’s not persistent. BRIAN: Yeah, I wish that it would stick around so I could fumble with things while it was running. Yeah, I wish that was the case. But for just a quick check of going, “Oh, that looks horrible,” it certainly is useful. JOSH: Has anyone done display profiles? It seems like you could just like, oh well, this is too technical of a sidebar, never mind. BRIAN: Yeah, I know where you’re going with this. That would be good. JOSH: Okay. So anything else in there? BRIAN: I’ll see if I can’t find and actually add it in. The fact is that there are lots of accessibility validators out there, but none of them are really that good. Again, it comes down to what environment is the person who’s using the thing running? You can say, “Well yes, I have these things on my page and I’ve included them,” but if the person’s running JAWS on Windows using Internet Explorer, JAWS is a screen reading tool, if they’re using that on Windows with Internet Explorer, they’re going to have a different experience than if they use that on Windows with Firefox. They’re going to have a different experience if they’re using VoiceOver on a Mac with Safari. They’re going to have a different experience using Window-Eyes or the open source NVDA. They’re going to have different experiences. It’s actually pretty scary to see how, html5 says you can use multiple h1’s on a page, but it’s actually pretty scary to see how the different combinations of Internet Explorer and Firefox and the JAWS and Window-Eyes screen readers actually handle those. Some of them don’t handle them very well at all. I take the automated approach with a grain of salt. I think just a checklist is just better. JOSH: Okay, so checklist. That’s good. I was actually wondering about the whole design process. Is there something like accessibility-driven design? Are there particular skills that designers need to know to be able to produce accessible designs? It seems like if you get to the point where you’re like, “Okay, we’ve done everything. We’ve built it. Now we want to make it accessible,” that that’s not going to give you a really good accessible system. BRIAN: Yeah, that’s true. But the thing is that good designers that have been trained in color theory and typography aren’t going to be making mistakes that cause accessibility issues because they’ve been doing this in print for quite a long time. They understand color contrast and things like that. The tricky issues with accessibility are not really from the design area. It’s easy to just pick some random colors that are going to have bad contrast ratios. But the bigger issue comes down to, “Hey, when I click on this thing, it doesn’t work,” or, “My screen reader can’t see these links you’ve generated with JavaScript,” or, “I can’t tell if that tab is open or closes,” or, “That modal you opened up, I can’t get out of that now,” or, “I’ve lost my focus in my screen reader.” Those are the kinds of real accessibility that are there. Or, “Oh, you loaded the entire page with JavaScript even though it’s a static page. But you didn’t use any kind of methodology to alert my screen reader that content has appeared.” JAMES: Let’s talk about that for a second, Brian. That’s a big change in the web in recent years. We’re using JavaScript for more and more because, well various reasons. Performance, the nature of the web these days, mobile devices, et cetera. And how is that interacting with accessibility? I think at one point, like you said, they tended to just turn it off. It seemed to almost be like the death now of accessibility. But I think things have improved there, right? BRIAN: **Yeah, it’s improved somewhat. But you still have, well it was a couple of years ago Twitter said, “Alright. We’re done with this whole JavaScript thing. We don’t need a whole bunch of JavaScript to display 140 characters. We were wrong. We’re going to switch back.” And I think that was the right thing to do because if you looked at the way it was working on certain mobile phones, the connection could be cut off and the JavaScript wouldn’t show up or it wouldn’t finish loading and the content would never show up. You have a white page. [inaudible] done. To me, that’s an accessibility issue. I wanted to access the site and I couldn’t read the content.JOSH: So you’re a huge fan of Turbolinks? JAMES: [Chuckles]**BRIAN: **I wouldn’t say that far. I wouldn’t go that far. [Laughter]**BRIAN: But what I am a huge fan of is I’m a huge fan of using the tools for their intended purpose. If you’re going to show me content, that’s what html is for. Why introduce additional layers of complexity just because you can? JAMES: If you have to introduce those layers of complexity though, let’s say you’re in a spot where it actually does make sense, then are there ways, and I guess that’s what you’ve been talking about, using these ARIAs and stuff. We can still try to give the browser hints, what’s going on. Things like infinite scroll, I think almost everybody agrees that’s a superior experience in many cases. JOSH: **Yeah, until you try to look at the page footer. [Chuckles]**JAMES: **Oh, yeah. [Laughter]**BRIAN: Well there’s that and there are issues with back buttons, there are issues with how do I get back where if I go back and then go forward again, how do I make sure I maintain position that’s at. JAMES: How do I link to a specific spot? Yeah, sure. BRIAN: **Yeah, there are a lot of issues with that. But yeah, how do you do that? You have to make good use of the ARIA live roles and you have to pray that your users are using assistive technology that can take advantage of those and they’re using a [inaudible] browsing combination. Infinite scroll is a case where you might want to consider having an alternate way of browsing the content.**CHUCK: So one other thing related to this that I’m curious about is in a lot of cases these different frameworks will update. They’ll push the hash information into the URL. Do most of these assistive technologies let people know that that’s changed? Because you’re not actually going to a new page. You’re just changing the hash value. I forget what it’s called. BRIAN: You’re literally changing the URL. You’re changing the local part of the URL? CHUCK: Yeah. BRIAN: It varies. I haven’t tested all of them. When I did some testing with Backbone, I saw that it didn’t seem to tell me that things have changed. But then again, it really didn’t matter because it didn’t impact the way that the screen reader was interacting with the page. It’s definitely something that we need to check, we need to test, and make sure that we’re aware if there’s going to be any issues there. That’s a great point. JAMES: That URL changing example’s good. I like going back to your definition of what is accessibility. There used to be those terrible AJAX sites that never change the URL and was basically an entire application. Luckily now, that’s going out of favor. But accessibility aside, that was just horrible for a user in general. I could no longer link to anything. BRIAN: Or you hit the backspace key on your keyboard to delete something and you realize oh, you just went back in the browser and now you’ve lost your place. I was working with an application just the other day that’s a fairly new application and I actually made a comment on Twitter about that, that it’s like we’re back in the Flash and ActionScript days where we’re just going to break the back button because we can. We don’t know how to do it effectively. We’re just going to do it. AVDI: So that’s a choice that you potentially make on the backend. I’m curious, are there any other backend choices? Particularly in the Ruby on Rails for obvious reasons, arena, are there backend technologies or tools or gems or anything like that, that developers should be aware of that help with this stuff? BRIAN: **I can’t really think of anything from the accessibility side that affects the [inaudible] backend, aside from the obvious stuff like if you’re doing internationalization, make sure that you spell things right. [Laughter]**BRIAN: You’d be surprised. That’s funny and all, but if your screen reader’s reading everything verbatim out of that, if you have a spelling error it’s going to be hard for someone to interpret that. And you’ve got two classes of people, you have two classes of users that are impacted by that. You have people who are using assistive technology to read things audible to them. Then you have the class of people who have reading disabilities or dyslexia, things like that. That’s going to trip them up, too. JOSH: And there are other forms of cognitive impairment. The last big site that I worked on was for people who have schizophrenia. The usability challenges with people at that level of cognitive impairment were really difficult to deal with. Stuff that most people have just absorbed in how to use websites and web applications and can figure out if they haven’t seen it before but just fiddle around with it. That kind of stuff can be a huge challenge in a huge segment of the population. BRIAN: And so the real moral of the story is know your users. When I talk about accessibility to more of a frontend audience, I like to talk about people versus users. Rather than using the phrase, “This is a user the system,” or, “This is a disabled user,” it’s, “This is a disabled person,” or, “This is a person with a hearing impairment,” or things like that. I think that the use of the word person is a little bit more friend than the use of the word user. JOSH: **Don’t you call them customer resources? [Laughter]**BRIAN: Oh yes, of course. CHUCK: Dollars. Packets of dollars. BRIAN: Liabilities. CHUCK: When you’re talking about internationalization, I want to ask about ESL. It seems like a lot of folks, they want to consume, especially in our industry, a lot of the content out on the internet is in English and a lot of the people out there may not speak English natively. One thing that I know that’s helped out a lot at these podcasts is that we put the transcripts up. Then people can go and read them and sometimes their reading comprehension is better than their audio comprehension. Are there other things that we can do to help people who are trying to consume our websites or content when they are doing so in a language that’s not their native one? BRIAN: **I think it’s the same thing that you do when you have people with cognitive impairment and dyslexia, is that you try to shoot for 6^th grade reading level for your main content. That’s not always possible with technical documents and things like that. But if you can shoot for that 6^th grade reading level for your [marketing] copy, if you can avoid using superfluous words because you think you want to, that goes a long way. I’m looking at marketing buzzwords here. I’m looking at the word that I hate the most, which is utilize. I’m looking at things like that where you’re using big words to sound more important.**JOSH: Or colorful words. CHUCK: **But I am more important. [Chuckles]**JAMES: **No, you’re not [inaudible]**JOSH: **Yeah, it’s your website. [Chuckles]**JAMES: What you were just saying there about technical content, I’m particularly sensitive to this issue because my wife and I have hosted a couple of foreign exchange students. One of them came over speaking quite well, being close to fluent. But then occasionally, we would just run into an area where she would basically fall off a cliff and it’s because of hyper-specialized language. A good example with a foreign exchange student is when you take them to a restaurant, because menus have their own language that is just their own thing. They say everything in menu-speak. And it’s not something you learn as a natural part of learning language until you set aside that special time for, “Here’s how menus are,” and technical jargon is that way too, of course. BRIAN: Yeah. And you can’t really deal with that but your marketing page, your home page, your blog even, things like that that are interacting with a general audience, we can all be a little bit more careful there. CHUCK: And it’s not always formats too or vocabulary. I can just chime in on this a little bit. I was a missionary in Italy and I can tell you, I can talk to anybody about religion in Italian. But if I try to talk to a programmer in Italian, about programming, I don’t have the vocabulary for it. I don’t know how to communicate that. JAMES: One of our students was a big math nut and she would go to school and do terrible in math. It was that obviously we use different terminology, but even more surprising, we had different symbols. Like when you have a repeating decimal, in the United States we tend to draw a line over the decimal that’s repeating. I guess that’s not how they do it in Korea where she was from. So she didn’t know that that meant it was a repeating decimal. She came home one time and we were having a discussion about it and I told her, “Ah, this is a repeating decimal.” Of course, we got stuck on that terminology. But once we got around it and she figured out what her concept for it was, she showed me how they draw that and it’s not the same. I didn’t expect that the symbols would vary. BRIAN: Yeah. DAVID: So Josh and/or Brian, you’ve both talked about accessibility for people with cognitive impairment. I’d like to talk a little more about that. As myself being somebody with a daily variable amount of attention deficit disorder, I have to manage my web experience fairly carefully or it will manage me. Josh, you mentioned schizophrenia. Can either of you touch on specific things that you have to do if you know that you’re, not just dumbing down to a 6^th grade reading level, but are there tools that people with these disabilities can use? I hate to use the word disability, because I don’t think of myself as disabled. But I certainly do recognize that there are times when I open up a page with a bajillion things and I never read the main content because I’m in ADD land. JOSH: I can tell you what I was doing building for people with schizophrenia. DAVID: I’d love to know that. JOSH: There are a lot of things that trigger people with schizophrenia. You want to avoid any sort of violent imagery or confrontational imagery. DAVID: Oh. JOSH: Yeah. Also, writing for that 6^th grade reading level was very good. I actually found it, like we were talking about at the beginning of the episode, that trying to target that audience gave me a way of thinking about the content that goes on pages in a really clarifying way. And I think that what we put together was actually better for the site in general. It wasn’t like we had to compromise stuff. But it did require a lot more thinking to keep things simple. You know how they say that most people can keep five to seven things in their head at the same time? No. You get one to three things on a page. DAVID: I know I have a track record of crass humor but I mean this sincerely and genuinely, it’s almost like the epilepsy seizure warnings on video games then, right? You avoid specific things like you don’t flash the screen at somebody if you know you’re dealing with epileptic users. JOSH: Yeah, I guess something like that. CHUCK: I want to change topic a little bit here. We’ve talked about visual impairment a lot on this episode and I understand because we’re talking about the web in particular and that’s a very visual medium. But are there other disabilities that should be considered like hearing impairment or other disabilities that we should talk about that we haven’t yet? BRIAN: Well we talked a little bit about how transcripts help out for the hearing impaired. But one of the things you also want to think about is if your producing a video, normalize that audio. Make sure that you don’t have these really quiet parts and these really loud parts. If you’re going to have background music, make sure that that background music is ducked out so that the speaking part is very, very clear and it’s easy for people to interpret. But number one thing in there is the transcripts and the captions and that’s hard to do but it’s worth it. It’s very worth it. JAMES: **One thing I’ve found that helps me is if you do have accessible features, accessibility features, things like keystrokes, document those. Put them on your webpage. List them as a feature like, “You can run this Twitter client without ever taking your hands off the keyboard,” or something like that because when I’m looking for things now that’s of high importance to me. I may not make it to the downloading your app part because I’ll look at it and be like, “Eh.” Who knows? But if you tell me then that’ll get me to look further and help me know that this is a friendly environment for me. And if you state something like that then I know when I find that one thing I can’t do by the keyboard and it’s driving me crazy, I can probably drop you an email and you’ll probably care. [Chuckles] Just saying those is helpful to me.**CHUCK: From now on James, all of my apps will have vim key bindings just for you. JAMES: **I’m an Emacs user. [Laughter]**BRIAN: **Thus he’s going to make sure he has vim key bindings for you. [Laughter]**BRIAN: **I love that just everybody who comes to me with the vim is better than Emacs because of the mobility argument, that argument is not over. Your argument is invalid. [Laughter]CHUCK: Well it depends on the disability. I think that’s one of the points of this whole discussion, is that for some people certain accessibility and certain ways, it just makes a whole lot more sense. And for other people, it’s different. I want to talk about that too. We told you accessibility for web applications and I’m going to bait-and-switch on you here. BRIAN: [Laughter]**CHUCK: The Ruby community has evolved not only into the web stuff which is still, I think, a major component of what people are writing in Ruby. But you have things like MacRuby, RubyCocoa, RubyMotion. You have people writing stuff for the command line and things like that. We did a whole episode on non-Rails and non-web stuff. But if you’re writing an app for the phone or for the desktop or a command line app, I know I’ve given you three major areas, how do you need to think about those differently from the web as far as accessibility goes? BRIAN: I don’t really think there’s much of a difference, to be honest. You’re still going to have your click targets be a certain size. You’re still going to make sure that you spell things correctly. You’re still going to make sure that your colors are appropriate. One of the nice things about the iOS platform is that it has an amazing accessibility API that you can tap into very easily. So you have a lot there. JAMES: That’s a good point there on the accessibility API on the iOS. What about just a standard Mac application? If you build just a normal Mac application, do users have less tools available to interact with that because it’s not the standard web stuff? BRIAN: If it’s a Mac app using the Cocoa components then VoiceOver should be able to interact with it just fine. JAMES: Cool. JOSH: Oh, duh. Sorry. So David, your question about what we did for the schizophrenia site, this just reminded me. One of the things that we did on a lot of the pages, especially pages that had a fair amount of instructional text on them, was that we had voiceovers. And we actually recorded a human being reading the text on a lot of the pages so that we had very high quality voice narration of the text on the page rather than going through some sort of text-to-speech generation. JAMES: That’s awesome. DAVID: I noticed going through Salt Lake Airport on the way to LoneStar Ruby Conf that they’ve replaced all of the human announcements with Siri or the Google text voice thing. And she’s harder to understand. And my first thought was, “Oh my gosh. Anybody ESL traveling through this airport, they might actually go from barely being able to understand to no longer being able to understand these announcements.” AVDI: **It’s true that in most airports they have good announcers, but most other contexts, a computerized voice would be an improvement. [Laughter]**DAVID: Because it standardizes? AVDI: **Well, any given bus or subway where the announcement is [muffled speech].**JAMES: **Avdi, please report to the [muffled speech].**BRIAN: **Whenever I fly, yeah, I always have that joke with whoever I’m flying with is that every airport I’ve ever been to, it’s always been, “Flight number [muffled speech] is boarding at gate [muffled speech].” [Laughter]BRIAN: [inaudible] you don’t [need].**CHUCK: Well that and whichever city you were in, David, when you experienced that, all those people are robots anyway. DAVID: **The thing that threw me is that the pacing was off. She kept saying, “This flight is now boarding at gate C as in Charlie 13.” [Laughter]DAVID: Charlie 13? What? CHUCK: Yeah, there’s a C in Charlie 15 too. DAVID: Yeah. JAMES: That’s awesome. This is great. It’s very informative. Brian, you’ve mentioned that sometimes you’ve done accessibility assessments for people. Are there other people that do that, a group of people that do that? It seems like that should be a thing. BRIAN: Yeah, there are tons of people that do it. You can probably go out on Twitter and say, “I need someone to do an accessibility audit in my site,” and you’ll find lots of people that’ll do it. JAMES: Seems like that’s a really good thing because then the only thing you have to be careful of is you’re just getting that one particular viewpoint. BRIAN: And the thing is that it depends on how much time and money’s going to be involved in that because part of an accessibility audit could just be that someone looks at your stuff, looks at your code, looks at your user interface, runs some tests on it. But the other part of that could be that they arrange a focus group for you. They have some users with all kinds of different disabilities and different setups and stuff and they can have those people review the sites too. Because one of the hardest things to do is get a pool of users together to test something out. That’s not including if you need people with screen readers or other kinds of assistive technology. Just getting a bunch of regular people together to test out your site and give you feedback on it is difficult enough. So part of an accessibility review could be something like that. JAMES: Do you think there are things that frameworks like Rails and such should be doing more to help push accessibility? Is there more that they could do? BRIAN: [Laughter] Yes. Lots. I’ve considered, once I get a little more free time here in a couple more weeks, I’ve considered doing some initial patches, sending some initial pull requests in on the forms, being able to put the ARIA stuff into the form fields and things like that and seeing if that would get pulled in. I don’t know.**CHUCK: Holy cow. That would be so helpful. BRIAN: One of the things that I’ve put, I’ve submitted patches a couple of times for this and it’s been rejected both times. But I really would like, I like the delete links that are generated by scaffold to stop using JavaScript only to make those work. I haven’t counted that as an accessibility problem in the past. JAMES: Yeah. That’s a good point. BRIAN: **And of course, that will never be changed. I’ve been told that will never be changed. There are lots of changes [they can do].**DAVID: Why wouldn’t they change that? Are they just worried that Google will troll their delete links again? BRIAN: **I don’t really know. I think the solution for that that I would propose is the solution that I use in a lot of my apps which is that that goes to an [eighth] action in the controller which is a delete confirm. It’s a get link that goes to delete confirm then you have to click on a post, a button that’s an actual delete that does that. The other thing I’ve done is I’ll take it and I’ll make it a button too, so that it isn’t a link.**JAMES: **Right. Then Google won’t [inaudible].**BRIAN: Then it won’t matter. Then it will work without JavaScript. But a lot of times I find that I need to delete confirm because I’m deleting something then I can use that delete confirm page to actually bring up a bunch of information, “Hey, deleting this will also delete this, this this,” and I can give a user a nicer experience rather than just an, “Are you sure?” DAVID: Yeah. AVDI: **So you do have advice for backend developers. [Laughter]**BRIAN: Yeah, I guess. JAMES: That’s great. BRIAN: That’s still more of a frontend thing to me. I still think of that as a frontend thing, but I guess. CHUCK: Well, calling into the backend is sort of an API to the backend, I don’t know. JAMES: **That’s a great tip though. Hey Brian, if they turn down your next Rails code request, just come to us, we’ll happily raise an angry lynch mob or something. [Laughter]CHUCK: Yeah. We have a few people who listen to use here. But it interesting that we can raise the issue and talk about it. BRIAN: [inaudible] I like about open source. Don’t get me wrong, I love the fact that these issues are so much easier to hash out in a public forum or even on a pull request, for example. Then you say, “No, I’m not doing this,” and that’s visible. Everyone can see that. I really like that.**CHUCK: I’m a little curious. Are these changes that need to fundamentally go into the framework or are these things that you could put into an engine or some other plugin that would add them? BRIAN: Well I think an accessible scaffold plugin would be easy to do. But then it goes against the heart and soul of what Rails is, don’t use scaffolds. But in more seriousness, I think if I was going to inject an application, the ARIA role for application at the top of the page, that’s something that you could do in the template. That’s something that you could do on your own. That’s something you could do with a helper. But there are things like messing with the forms like adding the additional ARIA, aria-disabled to a form field that’s had the disabled thing passed to it, things like that. It’d be much easier if that was in the framework as opposed to having to get a whole new form builder or plugin with the form stuff with that. JAMES: You could build your own form object, but also having it in the framework itself encourages people to do better. BRIAN: That’s right. One of the things that I’d love to see, I’d love to see that with some of the stuff that I saw from Ember where they were including roles. JQuery UI is including a lot of those roles. So it’s just there and the developers don’t have to think about it. That’s what I want to see with accessibility. I want to see that the developer doesn’t have to think about it so that they don’t argue against it. They don’t ham fist, they don’t argue, “I don’t want to do it because it makes more work for me and it’s hard and I have to do it later and et cetera.” CHUCK: I agree that ideally, yeah, we want it in the framework. I’m just saying, if we can’t get it into the framework, I would put that into my Rails apps if it made it so I didn’t have to think about it. DAVID: I would put it in a gem that basically I could write a web link that said action delete confirm true with page true and it changes it from a JavaScript confirm to a delete page confirm, that kind of thing. CHUCK: So, one last question. Can you list a couple of websites that do really well with accessibility? I was going to ask you to list a couple that don’t, but I don’t want to. BRIAN: No, I’m not going to. Not going to be mean. CHUCK: But some that really do would be awesome. BRIAN: Do really well with accessibility? CHUCK: Yeah. BRIAN: **Well until recently, Google Maps did. They made some changes that I don’t quite understand what’s going on, but is not working [nearly] as well. And I have to say Twitter is a lot better. That’s actually pretty nice now. It’s not perfect by any means, but it’s a lot better than it was. In my tests, I’m not getting lost anymore with my screen reader. So those are the two that really come to mind. Of course, a lot of the blogs that I see where people are using WordPress and things like that, those tend to be pretty good. A lot of the canned blogging software tends to be pretty good.**CHUCK: Awesome. JAMES: That’s a good point. One advantage to using a tried and true product is hopefully they’ve thought a little bit about accessibility. BRIAN: I have to say that one of the accessibility concerns I had is GitHub. For the longest time, they didn’t have a usable mobile view. They just didn’t. If I wanted to just look at the readme on a mobile device, it was very hard to do that because of the way that they just left it as the default. Now they have a mobile view. I consider that, for certain types of content, I consider that to be an accessibility issue as well. Yes, I can pinch and zoom on there, but it’s getting to the point where I shouldn’t have to anymore. JAMES: Yeah. Great point. JOSH: I have probably a last question for us here. I think we’re getting short on time. But what are the good resources for people learning about accessibility? Aside from this podcast. What should we be reading? BRIAN: I think the WebAIM website is really good. I like that. A lot of nice articles. They’ll do surveys every once in a while. They just did a recent survey on screen reader and low-vision users and talks about how they interact with the web, like are they zooming their text or are they zooming the full screen or are they using JavaScript? There’s a lot of great information on that. There are some guides there. There’s a couple of really great presentations. There’s the webaxe Podcast. It’s a pretty good podcast, too, to keep you up. And if you follow their Twitter account, you can get some pretty interesting insights, too. JAMES: Not as good as our podcast though, right Brian? BRIAN: **Of course. [Laughter]**JAMES: Just checking. Just checking. CHUCK: Alright. So the screen readers work exceptionally well with this audio file that you’re listening to right now. BRIAN: They do. Another one you can look at is html5accessibility.com, which talks about a lot of the issues that are going on with HTML5 and the browser issues and interactivity with html5. CHUCK: Awesome. JAMES: Awesome. Thank you, Brian. CHUCK: Yeah. It’s funny how many times we come back to empathy, talking over the last several months. But it’s a point DAVID: **Can we be done with that? Seriously guys. [Laughter]**JOSH: Do you have empathy fatigue again? DAVID: **Yes. [Laughter]**CHUCK: Alright. Well let’s go ahead and do the picks. David, I’m going to make you start. DAVID: Okay. So I have a secret, which is that I’ve been participating in this podcast with an assistive device. I’ve been working with a client that is dealing with accessibility. I’ve been chatting with him through this entire podcast about the various things. I’m actually going to do something new, which is I’m going to pick something that I have not completely vetted yet myself. So basically, I’m going to be a proxy pick here. And that is a book called ‘Strategic IT Accessibility’ by Jeff Kline. It takes on the approach of, at the medium and large organization level, how do you enable accessibility rather than trying to go to a single developer and say, “Hey, make this accessible.” Brian, you’re welcome to tell me that that’s a bad pick if you’re familiar with it. But the guy that I was talking to in the back channel highly recommends this book and says it’s really a good high-level view of getting away from some of the technical stuff but getting into how you have to think about this at the entire organizational level. I wanted to have a relevant pick for that. As a second pick, egghead.io is a website that has screencasts for AngularJS. I picked AngularJS a couple of months ago and egghead.io has a whole bunch of very tiny screencasts on how to use Angular. If you’re interested in Angular and you don’t understand how some of the pieces work, like how the dependency injection framework works and that stuff, he’ll start you off with the real basic stuff and work you up to very advanced stuff and it’s a really good website. So those are my picks. CHUCK: Awesome. Josh, what are your picks? JOSH: Well, I don’t have any software picks this week. But I have some reading picks from my younger days and we were talking about naming earlier and I jokingly quipped that I blame Ursula K. Le Guin for my penchant for naming things. But it’s kind of true. I read this book of hers called ‘A Wizard of Earthsea’ when I was young and it’s a classic. I think, Chuck, you and I have probably talked about that before in our discussions about good fantasy reading. So there’s a whole trilogy that starts with ‘A Wizard of Earthsea’ and it’s one of those wonderful books to give to you teenage kid. See how amazed they are at a new way to look at things. So that’s a good book. Then along the same lines of names being important, there is that wonderful novella by Vernor Vinge, ‘True Names’ which is, everyone credits Neuromancer with being the beginning of the cyberpunk movement back in the 80’s. But I think ‘True Names’ is actually the first cyberpunk novel. They have people hacking in virtual worlds and it was definitely a good read. I’m going to pick those two things. Maybe next week, I’ll have something a little more technical for you all. Done. CHUCK: Alright. James, what are your picks? JAMES: **Well, a cool thing happened on the internet recently and that’s that Kathy Sierra is back. She disappeared off the internet for a while, much like Y did from r community due to people treating her poorly. I’m not going to go into all the details. But the good thing is she’s back. Kathy Sierra is a game programmer and she built things you probably know like the headfirst series of books and things like that. She’s really just great, smart person. She has a new blog that you should check out. The very first post on it is great. It’s called Your App Makes Me Fat and it’s about how an application can drain a user’s cognitive resources. So it’s exactly about what we’ve been talking about for the last hour. It’s very good. She has a new Twitter account. She’s @seriouspony on Twitter, which is awesome because she alternates posting these deep kind of technical ideas or startup ideas or things like that along with pictures of Icelandic ponies. I’ve really enjoyed following that because every now and then you just get this awesome picture of this pony running or rolling in the grass or whatever and it’s great. And I’ve already learned a ton from following her on Twitter. I didn’t know what the Zeigarnik Effect (I don’t know if I’m saying that right) was. She tweeted about it and I ended up having to look it up. It’s actually quite fascinating. It’s about how you can deal with procrastination and stuff like that. Great source of just thought-provoking stuff. It’s Kathy Sierra and she’s back. I’m grateful to DHH for making me aware of that.**CHUCK: Awesome. Avdi, what are your picks? AVDI: I’ve got a whole queue of picks for once. But I’m not going to bore you with all of them. I think I’ll just pop about three of them off the queue and save the rest for another time. First of all, it’s possible somebody’s already picked this, but there is a project called Ruby Warrior that I think Ryan Bates started and it’s a game that you play with Ruby. You program a virtual warrior to make its way through a dungeon and react intelligently to the dangers it finds there. I had played around with that a little bit in a pairing session. I did once. It was really fun and that was the last that I knew of it. But recently, somebody took that and ran with it and made a whole website where you do the same thing, only it’s totally interactive. They actually show you the map that this little warrior is moving through and you have the code right on the screen and you can live code and it’ll evaluate the code and make the warrior do what you tell it to do. It’s super cool and I haven’t actually had time to play with it much, but it looks like a ton of fun. The five minutes I did spend playing with it were super fun. Okay. Next up. There’s this thing called ‘Object Playground: The Definitive Guide to Object-Oriented JavaScript’ and it’s a combination of a really well-done video about how objects work in JavaScript with this super cool visualization technology where you can basically type some code in and it will live-visualize the whole JavaScript prototype chain and a lot of associated information. Really neat to play with and very handy for grokking the sometimes abstruse JavaScript object-oriented model. I think I’ll just do one more off my queue here. Ran across this neat video from one of Peter Cooper’s mailings. It’s a demonstration of APL, the programming language APL which stands for A Programming Language, from back in 1975 and I suspect that this is one of the first screencasts ever made. In fact, it’s less of a screencast than a typewriter cast because the top part of the screen is the demonstrator’s head and him talking and the bottom part of the screen, they use some primitive technology to cut in a different camera which is pointed at the teletype that he’s working at so you can watch him as he codes on a teletype and it’s printing out. As a professional screen caster, it was one of the coolest things that I’ve seen in a while because this is the first screencast or nearly the first. JOSH: It was hilarious to watch that and also really impressive and humbling. AVDI: Yeah. JOSH: **But yeah, I really chuckled at some of his claims about how easy to use a lot of that stuff was. [Laughter]**JOSH: Easy to remember symbols. AVDI: Yeah. Alright and that’s enough for today. CHUCK: Alright. So I’m going to do a couple of picks here. This one’s for David. I don’t know if you know about this, but there is going to be a conference in January in Salt Lake City, Utah and it’s called ng-conf. It is an Angular conference and it’s going to have the Angular team there. You can find it, like I said, at ng-conf.org. DAVID: Cool. CHUCK: I know some of the guys that are helping put it on and it looks like it’s going to be really awesome. So if you’re interested in learning Angular, you want to. I’m going to be there. I’m probably just going to be there as an attendee because I’m not super familiar with Angular. But anyway, if you want to meet me, David might or might not be there. But a lot of other awesome JavaScripters that I know are going to be there. You can go to that and learn more about Angular. If you’re into Ember, we talked about Ember because it has the ARIA roles and things like that built in, another local guy named Ryan Florence, he’s pretty big in the Ember community, he’s put up Ember101.com and he’s been doing free screencasts on how to get into Ember. If you want to learn Ember, that is a terrific way to go. I asked him about charging for it when he was on the JavaScript Jabber Show and he basically said, “The internet’s given me a lot for free and I’m giving it back.” So it looks like this is going to be free forever. It’s an awesome resource for that. Finally, Rails Ramp Up starts today, and by today I mean a week ago when you get this. DAVID: Two weeks ago, actually. CHUCK: Or two weeks ago. Whatever. I get confused because our schedule got confused. But yeah, two weeks ago. So anyway, you can probably still register, but that’s not what this is about. I found a new platform for putting up my videos that I’m really excited about and it has worked really, really well. It’s called Wistia.com. And the issue that I had with Vimeo was that I felt like I was violating their terms of service by putting private videos up there. They don’t want you to do that for commercial lockdown site stuff. But Wistia is just, you put it up there and then you can embed it wherever you want, however you want. And they have a whole bunch of different options for embedding, calls to action, sign up of my mailing list, all that stuff, into the video. So you can get that in there too. I’m probably going to be reworking a lot of my marketing videos to use Wistia and use those features. Really, really like it. Those are my picks. Brian, what are your picks? BRIAN: Oh, I’ve got a few. The first one I want to do is about a month ago we released the second edition of the HTML5 and CSS3 book that I wrote a couple of years ago. So you have a second edition with lots of new material in there and a little bit more on accessibility. I actually spend a little bit of time talking about how to put captions into the videos and how to do accessible tables and things like that. Sprinkling a little bit more of that throughout the book this time has made it, I think, a better book. So I have that. The other one that I want to bring up is actually another book that I have nothing to do with, but I actually think it’s a wonderful book. It’s called ‘Pro HTML5 Accessibility’. It’s by Joshua O’Connor. It’s a really nice tour because it does talk about some of the things that you can do and it talks about some of the alternatives to things that you can do. It’s a very handy book to have around if you’re trying to do things on the web and you really want to focus on making them a little more accessible. So I do highly recommend that. The last pick I have is for a game. The game is called Beat Hazard. I am a huge fan of games that involve music. Beat Hazard is dual stick shooter. It’s like a Geometry Wars type of game. Or if you go way back, Robotron type of game. But it uses your music library to build the songs and build the intensity of the weapons and things like that. It’s pretty cool-looking. It’s a lot of fun to play with. Music from your library rather than some hokey music that somebody came up with for the video game. But the other thing is it’s available on almost every platform. It’s available on the Xbox, in the Indie network, it’s available on Steam, it’s available on iOS and it’s available on Android. So you can get it anywhere. It’s just a blast to play. CHUCK: Sounds like fun. Alright. Well, I think we’ve covered everything. Next week, is it next week? Because we’re scheduling around stuff. Is next week the book club? Or is that in two weeks? JAMES: Yes it is, next week. DAVID: Well we are recording book club next week, but it will be JAMES: It will be next week from when they hear this episode as well. CHUCK: Okay. That’s what I was checking. DAVID: Okay, we’re airing LoneStar next and then this episode airs after LoneStar. JAMES: See, if you cannot tell, we are all horribly confused by our new regular schedule. DAVID: **Are we still a Ruby podcast? [Laughter]**JOSH: **Apparently time has gone non-linear on us. [Laughter]**JAMES: But yes, it will be next week on one chapter from the end of the book. It is so much fun. I cannot wait for that conversation. CHUCK: Awesome. Alright. So since we didn’t say what it is, it’s ‘Understanding Computation’ by Tom Stuart. So go get it. Go read it. And we’re looking forward to having that discussion. DAVID: **And go get it and go read it now because one week is barely enough time for you to scratch this book. It is heavy-duty. That’s the second time I’ve warned you children. Go read it. [Laughter]CHUCK: Alright. Well thanks for coming. JAMES: It’s all fun and games until somebody gets their eye poked out by a proc. DAVID: By an infinite Turing machine. CHUCK: Alright, well thanks for coming, Brian. It was a great discussion. I learned a lot and hopefully we can make an impact on the web and make it more accessible to people. BRIAN: Thank you for having me. This has been fun.