SY: Welcome to the Code Newbie podcast. I'm your host Saron, and for the past three years, I've interviewed amazing developers on this show. We've done 146 episodes and it's been great! But I think it's time to switch it up. We're moving to a seasonal schedule. We'll be on every week, for eight weeks, which means that after 146 episodes, this is the first episode of our very first season. So, let's try the intro again. [00:00:34.02] Welcome to Season 1 of the Code Newbie podcast. I'm your host Saron and today's show is on a topic that I find both fascinating and terrifying. Accessibility. Ok, it's not that scary, but here's the thing. Yes, I want everyone to be able to use all the things I build, and of course I don't want to leave anyone out. Obviously, that's a bad thing. But if you're new to accessibility and you don't really understand it, like me, it can feel like yet another overwhelming tech thing I need to add to the very long list of all the other tech things I still need to learn. So, to help us navigate the world of accessibility and hopefully make it feel more - accessible - I invite Stephanie Slattery on the show.

SS: [00:01:30.20] I work for Click Studios in Chicago.

SY: She's a front end engineer and -

SS: I especially specialize in accessibility.

SY: Back in January, she applied to speak at Code Land, our very first Code Newbie conference. And when I read her proposal, I thought, this should be a workshop.

SS: First, off the bat, it was an amazing opportunity to run that workshop.

SY: People loved that workshop!

SS: (Laughs) It was so much fun, like you said, I did get a lot of positive feedback on it.

SY: So she's here to school you - and me - on accessibility tools.

SS: The things called sip and puff devices can be used by people who are paralyzed.

SY: Guidelines.

SS: Within the WCAG has a list of different ways you can succeed. It also has a list of different ways you can fail.

SY: And why this topic is so important.

SS: If you don't do it - you, a programmer who's working on whatever it is you're making, if you don't do it, then who's going to do it?

SY: But first - a word from our sponsors.

[00:2:22.05] One of the first things you do when you're learning to code is set up a tech blog, which means you need a great domain name. Finding the perfect domain is ridiculously easy with Hover. They've got over 400 domain extensions to end your domain with, they've got the classics like .com and .net, they've got tech friendly like .design, .tools, and .tech. And, they've got delicious ones like .pizza and my personal favorite, .coffee. To find your perfect domain name for your tech blog, go to Hover.com/newbie to save 10% off your first purchase. That's Hover.com/newbie.

[00:02:57.04] Incapsula. If you're learning to code, you're probably spending all of your time getting your app to do what it should do. So after a ton of work and time and banging your head against the wall, you finally get it to do the thing you want. But, the page takes too long to load. Or, it goes down for a second. Or, even worse, it gets attacked by some bot net. What do you do? That's where Incapsula comes in. They sit between your servers and your users, inspecting every packet, filtering and blocking and protecting you and your app. They make sure you and your awesome app are safe and reliable - so you can focus on coding. And, they're offering our Code Newbie listeners a chance to try it out for one month for free. Just got to Incapsula.com/CodeNewbie. That's Incapsula.com/CodeNewbie. Link is in the show notes.

[00:03:48.05] So, when we talk about accessibility - I'm going to read this definition that you put on a blog post that I really, really liked. It said, "Web accessibility is the practice of removing barriers that prevent people with disabilities from accessing the web." And I know you have a slightly expanded version of that. What's that version?

SS: Yeah, like you said, it's the practice of removing barriers. It's also in general the design of products, devices, services, or environments for people who experience disabilities.

[00:04:12.11] SY: So what I love about that definition is the part where you say people who experience disabilities, because I think that when we talk about people with disabilities, it sounds like a permanent relationship, but one of the things I've opened up my eyes to and begun to appreciate, is that you can moments where you are disabled as well. Like if you break your arm or maybe you're healthy one day, and then you get a little bit older and you don't have the fine motor skills. So, it opens up the possibility to include you. Even if you don't have a disability today. So I appreciate that.

SS: Folks in the disability advocacy world like to say that we're all just temporarily abled.

[00:04:54.06] SY: Yes! Ugh, I love that statement so, so, so much. I absolutely love that. So, when we talk about the categories of disabilities, there are five categories that you mention in your blog post, and they are visual, hearing, motor, cognitive, and seizure, and I think that when most of us who aren't as familiar with accessibility, when we hear about that term, I think the visual one is fairly obvious, the hearing one too, and I think we think of people who can't see and they need screen readers and that's kind of it. But it's bigger than that. Tell us about these other less popular categories.

[00:05:30.08] SS: Sure! (Chuckles). So the first one you mentioned was visual. And like you said, people do tend to jump to people who have complete blindness as their idea of what a disability is. But visual disability also includes things like partial blindness and low vision, as well as color blindness is a thing that we'll hear a lot of discussion about in the web accessibility space, but that really is a type of disability, color blindness. The next thing I would say, like you mentioned, is hearing disabilities, so this includes capital D Deaf people, people who are hard of hearing, and also people with things like hyperacusis, which is a sensitivity to certain frequencies and volume ranges of sound.

SY: Oh!

SS: Yeah.

SY: Oh, I've never heard of that one before.

SS: I know. Isn't that interesting?

SY: Yeah.

[00:06:16.05] SS: You also mentioned motor disability, so this includes things like paralysis, cerebral palsy, carpal tunnel syndrome - you might be surprised to think of us as a motor disability, but it very much is. Repetitive strain injuries, also something called dyspraxia - this has to do - it affects your planning of your movements, it makes it harder to coordinate motions that happen together. In general, when we're thinking about web accessibility, motor disabilities can impact a person's ability to use a mouse, or give them a slow response time, or limited fine motor control. So, it might be kind of hard to tap like a small space on a touch screen. Things like that. [00:06:59.06] Cognitive disability includes all kinds of different things. The two main subcategories are cognitive impairments and learning disabilities. Cognitive impairments are things like head injury, developmental disability, and autism, whereas learning disabilities can include things like dyslexia, ADHD - these can cause things like distractibility, or an inability to remember or focus on large amounts of information at one time.

[00:07:23.07] SY: For the cognitive example, how...so, for example we talked about motor, we're talking about use of the keyboard, use of touchscreens and how to use a mouse and stuff. For cognitive, what are we talking about? Are we talking about layout of the page, is having things that are more text heavy than image, like is that?

[00:07:41.04] SS: So this has to do with the layout and the content of the page. It also has to do with things like using clear language, avoiding uses of idioms and colloquialisms that might be confusing. This also includes essentially cognitive overload, so if you're presenting a ton of information, all at once, very quickly, that can be pretty difficult. [00:08:06.25] And in general, these are things we see a bit less of on the web, because those are also just really bad user interface design. You know? (Chuckle). We don't want to overwhelm any listener with too much information or too many confusing words or too much jargon. But in a lot of cases, it's very important to be very clear for accessibility purposes.

SY: And the last one we have is seizure.

[00:08:34.03] SS: This is more of a symptom, but in general these include disabilities that can cause seizures, caused by strobing, flickering or flashing effects on a page. So if you've seen those old geocity-style websites that have a blinking banner, click here or whatever.

SY: Oh, those are the worst.

SS: Yeah, right? This is again something that we see less of these days. If you have a hover effect somewhere, that does some flashing cool thing, it's really important to follow guidelines about restricting how quickly things flash, or even what color things are flashing in. Different colors of light can trigger seizures in different types of people.

[00:09:12.03] SY: Interesting. So, we're going to talk a little bit more about how we as developers can create things that are more accessible, but there's also technologies that were created specifically to assist people who were experiencing these disabilities, and screen mirror is kind of the obvious one. What are some of the other ones we may not have heard of?

[00:09:29.04] SS: So, I always find that when I talk about web accessibility, people are surprised that people who are completely blind or people who are totally paralyzed from the neck down are using a website. And that's through awesome assistive technologies that have been developed. So you mentioned screen readers, which are awesome. They read essentially the HTML of a page and present it in audio form. There are also things, hardware wise, like large print and tactile keyboard that make it easier to read keyboard keys or to press those keyboard keys or to feel where they are without looking at them. There are also a lot of different input devices beside just keyboards and mice. There are also things like eye gaze and head mouse systems. These are super cool - they track the eye movements of a person to receive input. So instead of using something to control a mouse, you're moving your eyes and it's tracking what you're looking at. There are also head mice. So, think of if you imagine a button that would be placed next to your head, or a sort of a touchpad, you can control things like that without using your hands. Also, things called sip and puff devices. These can be used by people who are paralyzed as a way to suck in and blow out air as a way to give different inputs to a computer. Super cool. Or even things just like closed captions - that's an example of an assistive technology.

SY: That is so cool. I had no idea there were so many solutions. That is amazing.

SS: Oh yeah, absolutely. And there are a ton more that I didn't mention.

SY: [00:11:13.02] So, in a talk that you gave, that was titled "Web Accessibility 101: Why it Matters," I saw the title of that and I said to myself, do people really have to be convinced that things should be accessible? Have you had to fight that battle of convincing people that this was important?

[00:11:29.05] SS: Oh yeah, very much so. Yeah. The first sort of stepping point of convincing people is explaining that this is even a problem. People don't realize that there are people with all those types of disabilities we mentioned. They just don't know, right? And a lot of the times I'll find that once people realize that people want to use their technology, they're willing to just go for it, make something accessibility. But being kind to people doesn't always pay bills, and so a lot of the times I'll have to convince folks that there's monetary value in this too. So, interestingly enough, in the United States, about one in five Americans have a disability.

SY: Wow, that's a lot. That's a lot of people!

[00:12:12.01] SS: Yeah. That is a lot! That's as of 2010. So that's about 57 million people. I don't know about you, but if I were making a website, I wouldn't just exclude one fifth of all browsers people use. That's an awful way to make money, right? So building things in an inaccessible way - ugh, that's not going to be good for a bottom line. Also, those one in five Americans control about 175 million dollars in discretionary income.

SY: Oh, that's a real number.

SS: Yeah, right? (Chuckles).

SY: That's like a serious number.

SS: That is a serious amount of dough, right? The other thing that I find is a very helpful way to convince people that accessibility matters is that it's the law.

SY: [00:13:06.13] That's the next thing I was going to bring up. Are there legal repercussions to not making - yeah.

SS: Very much so. So there are, in the United States, a few different laws that deal with accessibility, specifically in technology and the web. There's the rehabilitation act of 1973, and in short, this law was passed as part of the disability rights movement, as a way to ensure that the federal government and companies and organizations that receive federal funding or do contractor work for the federal government, are accessible to people with disabilities. It's technically a labor law, but it's been modified over time to deal with information technology in general. Of course, that only applies to you if you're receiving federal funding. Not everybody is. So more broadly, we have the Americans with Disabilities Act, that's also called the ADA. It was passed in 1990 and that in general says that things need to be made accessibility in the United States. The thing is though, like I said, it's from 1990, the internet was not so much a popular thing back then, so it doesn't really specifically mention web accessibility. Over time though, it's been made pretty clear that the ADA does apply to website, even those that are private and receive no money from the federal government, and even those that don't have anything physical that they do. [00:14:33.25] This has come up through lawsuits, essentially in the United States, the main way to ensure that companies and organizations are compliant with these laws is by suing them.

SY: Yeah, that sounds right.

[00:14:47.07] SS: Yeah, yeah! I know we think, aw, America, everybody's just suing each other left and right, but really this is the way that consumer protection works in the accessibility space, through lawsuits. Now, a lot of the times organizations will try to contact a business if there's some accessibility problem with their product. And sometimes that's all it takes. A company will go, oh great, awesome, we're sorry, we'll fix that. Most of the time though, it takes a lawsuit being served to a company, and frequently those will be settled out of court. So we don't hear about them a lot. It's the ones that do ultimately go to court, like Southwest Airlines, or Netflix, that make this publically known.

[00:15:31.05] SY: I was not familiar with the Netflix one. Can you tell us about that?

SS: With the Netflix lawsuit, there were videos on their website that didn't have appropriate captioning, and as part of the Americans with Disabilities Act, you need captions.

[00:15:48.03] SY: Ok. So, I'm a company, I don't want to get sued, I want to do the ethical right thing, I want to make my stuff accessible. Where do I start?

[00:15:57.09] SS: Listen to people with disabilities. Both internally, have diverse hiring practices. Make sure you have people with disabilities represented within your company, right? Engage external folks with disabilities to give you feedback on what is it you've created. There are a lot of awesome nonprofits that do work in this space, and are happy to help you out with that. And in general to do the same thing you would do with any other user of your website. Engage in user testing and test your product, really listen to people with disabilities. There are also best practices. The major, major one that in fact all those lawsuits I mentioned usually rely on - this is called the Web Content Accessibility Guidelines. This is also referred to as the WCAG, or the Woo-CAG.

[00:16:53.02] SY: That's so much fun to say!

SS: I know, it's a fun word. WCAG, right? So, it's currently in version 2.0. This was made by some lovely folks called the World Wide Web consortium, or the W3C. These are the folks who make the rules of how the internet works fundamentally, how the web works.

SY: They sound pretty important.

[00:17:10.05] SS: Yeah. Very important, very cool. All of their notes and writing about all these sorts of things are all available online, so you should go check 'em out. But the WCAG itself is this pretty long document, it's pretty huge -

SY: Yeah. Dense stuff.

[00:17:28.10] SS: Yeah, and it goes into a ton of detail about different guidelines. So, in the WCAG there are four overall sections, big guidelines that you have to follow. They are perceivable, operable, understandable, and robust. Within the WCAG, and within those overall big four sections, there are three different conformance levels and you can think of these sort of by the nicknames they're given. The lowest level is called Level A. People refer to this as the things that you must do if you want to be accessible. Next one up is Double A, these are the things you should do if you want to be accessible. And the highest conformance level is Triple A, these are things that you might do in order to be accessible.

[00:18:18.06] SY: So, as I was looking at the guidelines, before looking at them, I thought they were going to be kind of ambiguous. I thought it was going to be something like, make this easier to read, or have more images, and that was going to be it. And I was thinking, how could anyone possibly implement this? But they're actually very, very specific. When I counted, I believe I counted 61 guidelines total.

SS: That sounds about right.

[00:18:45.01] SY: And I want to go through two examples. The first one - the very, very first one, 1.1.1, - which says, non-text content - and this is level A, this is a requirement, and it reads "All non-text content which is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below" and then it has some more stuff in it. [00:19:06.10] So essentially, this boils down to - don't forget the alt-text. Is that right?

[00:19:10.02] SS: Yeah. Definitely a part of it is don't forget the alt-text. This also includes things like, like you said, alt-text on an image. This also has to do with audio and video in a very broad sense. A lot of these guidelines actually overlap, so you might as part of 1.1.1 be worrying about having a text alternative to a video or to some sound.

SY: I forgot about the video part.

[00:19:35.07] SS: There are also a bunch of other guidelines about that too. So they kind of interconnect. If you're conveying information in any sort of sensory capacity that isn't text, this might include color, this might include physical relationships between things, so if you say, "To the right of this, blah blah blah blah blah," and if you're not perceiving things visually, you're not sure what's right of something else. Yeah, it's interesting. And again, there's another like little sub-guideline about that in here too.

[00:20:10.05] SY: Yeah, and I was really relieved frankly to see how detailed it got. And actually has even some bad examples, good examples. It really works hard to make it easy for software developers and people who build website to implement these guidelines and really make it accessible.

[00:20:25.08] SS: Yeah, it does. Every single guideline within the WCAG has a list of different ways you can succeed at achieving this. It also has different ways you could fail in the same way, and examples of how to succeed, and examples of how to fail. [00:20:42.06] The other thing that's worth mentioning too about all these, just as you're looking through them - the current version of the WCAG, that 2.0, was written in 2008. And the web has changed a lot. It's about almost 10 years old, right?

SY: That's a while ago.

[00:20:55.01] SS: So there are a ton of things that the WCAG mentions that one, people don't really do any more, and the WCAG doesn't cover some things that we do a lot today, like the mobile web. It doesn't mention differences on mobile devices at all. It also doesn't mention touch screen devices at all. A lot of this is taking what the WCAG says, and sort of applying it to your situation and to the modern technologies you are using.

[00:21:24.05] SY: So you mentioned that 2.0, this version of WCAG, came out in 2008, and I noticed that. I felt that when I was looking at some of the guidelines. The other guideline I wanted to get into is 2.4.8, called location - and this is a level Triple A, so it's nice to have a not an absolute requirement. And it reads - "Information about a user's location within a set of webpages is available." So at first, when I read this, wait, are we like geotagging things? Are we tracking people? That was my idea of a user's location. But it's really talking about site maps, breadcrumbs, navigation, always knowing where in the context of the web site you are. And when I was digging into this and looking at some of the examples, there were two things. One, it felt like a lot of the examples are kind of out of date. You know, I don't think we use bread crumbs as much, I can't remember the last time I saw a site map on a website, but even if those things were used, they kind of go against the aesthetic that we've associated with modern web design, where everything is clean and we're trying to strip things away and be really minimalist. So, I'm wondering, does that happen often, does following or trying to follow these guidelines, does it conflict with the aesthetic and the design practices that we like to champion?

SS: [00:22:43.01] Yeah, that's a really good question. This is actually one I get a lot after I'm speaking about accessibility or running a workshop. People will say, oh, that's all really cool, but doesn't that mean my site will be really ugly? (Laughs).

SY: Yeah, or just busy!

[00:22:55.03] SS: Yeah, right? It's true that sometimes, building a website accessibly might come against the beautiful visual idea of your website, like this example of breadcrumbs. You might not want to have breadcrumbs cluttering up your gorgeous user interface design. There are luckily not a lot but definitely a few examples of sites that meet really strict accessibility requirements, so this Triple A conformance level, that are also really nice looking. To me, when you're going for the strongest conformance level, Triple A, it's something of a design challenge, which I don't know, I think can be fun.

SY: Yeah, I was going to say, when you put it that way, it sounds exciting.

[00:23:41.04] SS: Right, right. So a good example of a site that meets this highest conformance level and looks pretty nice in my opinion, is the site for the organization called 18F. I believe the url is 18f.gov. They're so awesome.Think of them like the federal government's web-consulting firm, that's in the federal government. So it's their job, or at least they're trying, to make government websites look consistent and be usable and look like they exist in the modern era and not 20 years ago, right? They do awesome stuff and -

SY: They really do.

[00:24:20.00] SS: Yeah, and because they're part of the federal government, they have to meet the ADA super clearly, so they have the strictest accessibility requirements. Their site looks like a modern, very nice website - and meets all of these high level accessibility requirements. So with this example specifically, the idea of showing a location on a website, when we think, like you said, of breadcrumbs, we think of a list of how we got to a page you're on, and it generally might look cluttered. This guideline though does list other techniques that it calls sufficient for making your website accessible and meeting this guideline. So, the other one, like you said, is a site map. Site maps are, luckily, pretty easy to make using more technology you use to make things on the web, and they're also really good for SEO purposes, for search engine optimization, right? So, it's pretty easy to make a site map as a way to meet this guideline and put a link to it in your footer and call it a day. You've met this accessibility requirement.

[00:25:21.07] SY: Nice! Nailed it.

SS: Yes, exactly. So there are definitely ways, thinking of the modern web, to meet these requirements and still look cool.

SY: So, assuming I understand these guidelines, I'm able to meet them, I review my website, I think it's meeting these guidelines, I think I'm doing a great job - how do I know? Is there a test or something I can put my website through to figure out what I did well, what's missing, that sort of thing?

SS: [00:25:49.25] Totally, yeah. There are luckily a bunch of different automated tools you can use to check your website. They're going to give you a good sense of what the scale of your problems are accessibility-wise, and sort of validate if you've done things well. In general, you'll put the url of your website in the tool, hit a little button, and it'll take a minute or so and spit out a bunch of information about your website. The thing though about these automated tools is that they're reading your HTML. So there's a guideline, for example, that has to do with constructing headers correctly. So both having them visually look like a header as well as using appropriate header HTML text. And so, if this tool is going through, checking your website, and you have a header but it's not in a header tag, this tool doesn't know to check it and doesn't know that it's a header. So these tools might say, good job, you did your headers right, but you did them so wrong that the tool doesn't even realize they're there. So, they're definitely a thing that should be used in conjunction with your own best knowledge of accessibility and referencing the WCAG. [00:27:02.11] When I'm doing an audit of a website for accessibility, I will definitely use those tools because man, that is so much quicker than reading through HTML and validating it by hand.

SY: Yeah.

SS: But it's also super important, even for the things that a tool can check, to double check it yourself. Sort of get a gut check, did this actually do things correctly.

[00:27:19.02] SY: Yeah, that reminds me of writing just regular tests that you would write for a web app, right? You have your specs, you run it, it provides you some level of a safety net, makes sure things are working, but at the end of the day, you still have to give it to real people, you have to QA it, you have to put it on __. There's still a lot of actual testing that needs to happen as well.

[00:27:38.04] SS: Exactly. Going back to what I said before, the best way you can make sure your site is accessible, is to listen to people with disabilities. (Chuckles). It's all well and good to run your tool through a checker and to use all these best practices and follow the WCAG and read a ton of blog posts about accessibilities. But doing all of that - it's still possible for your site to not be accessible to some people. And really talking to the people who you're making the website for, that you're caring about when you care about accessibility - that's the best way to make sure your site's accessible.

[00:28:14.02] SY: When we come back, Stephanie shares how you can make your coding projects more accessible - hint, don't just start reading the WCAG - what she wishes she knew when she first learned to code (this one is really good), and how, even with all these knowledge, sometimes she still feels like an imposter.

SS: I'm like, oh, I'm not an expert, why are they letting me do this? Right?

SY: After this.

[00:28:35.08] Building your website is a ton of work. And pushing it live and showing it off is an awesome feeling - but when you're done, you're not really done. You've got to make sure it stays up and it stays safe. Incapsula can help with that. They protect more than 4 million websites every day. From individual bloggers and personal apps, all the way up to Fortune 500 companies. They work to keep your site up, so you can focus on coding. And as a Code Newbie podcast listener, you can try them out for a whole month for free. Just go to Incapsula.com/codenewbie. That's incapsula.com/codenewbie. Link is in the show notes.

[00:29:12.09] Did you know that when you register a domain name, your contact information, including your phone number, email, and home address, is published online for marketers, spammers, and hackers to find in something they call a "who is" database? And if you want keep that information private, you gotta pay up. Unless you get your domain name from Hover. Hover includes free "who is" privacy for all supported domains to keep your information confidential. And when you sign up with them, you don't have to go through page after page of add-ons and opt-outs that you don't want or need. Hover focuses on just domains and email, so you can focus on finding a great domain name and get back to documenting your coding journey. To find your perfect domain name, go to Hover.com/newbie to save 10% off your first purchase. That's hover.com/newbie.

[00:29:58.05] So you did a workshop on accessibility, and specifically on how to do an audit at Code Land, which is our first tech conference that happened this April in New York City, and if I remember this correctly, I'm pretty sure your workshop was one of the first to fill up completely. People were so excited about it, and I heard really, really great things about it afterwards as well. So I'm wondering, what was it like for you as the teacher? Was there anything that surprised you or your felt like people maybe struggled with or connected with in that process of better understanding accessibility?

SS: [00:30:31.07] First off the bat, it was an amazing opportunity to run that workshop.

SY: Oh good!

[00:30:36.05] SS: It was so much fun. Like you said, I did get a lot of positive feedback on it. And whoa - so, like a lot of other folks in tech, I definitely deal with imposter sydrome and feeling like, oh I'm not expert, why are they letting me do this, right? (Laughs). And so going into that workshop, I was feeling like ok, I have this, I have this under control, I can do this, I know what I'm talking about. And definitely the mix of folks who were in that room was so cool and also intimidating. So there were folks there who were just transitioning into coding and into development, and they care a lot about people with disabilities, and they wanted to learn about accessibility at the beginning of their code newbie journey, and do it right from the beginning. And there were also folks who work at like Microsoft who were amazing and if they're listening, you are all awesome people and asked so many good questions. But it was like, oh no, someone's boss at Microsoft sent them to my workshop - don't they know I don't know anything about this, oh no!

SY: (Laughing)

[00:31:49.02] SS: Yeah, there were also some awesome folks from Adafruit, and all these companies I really admire, and I was like oh no! I have to do this right now. So everybody deals with imposter syndrome no matter where you are in your journey. We talked about what is accessibility, how do we know - we talked about the WCAG, and then we had a bunch of example websites that are crappy websites, websites that haven't been updated since the year 2003 and do not look good, as a way to practice auditing things for accessibility. Because as you might have mentioned before, there's the idea that oh, well, accessibility and good looking websites are kind of at odds, and let me tell you, these were some awful looking websites that were still not accessible. (Laughs). They were not good. But they were also surprising, right? I found that a really good way to practice auditing something for accessibility is to just pick a website - and don't pick a really huge website that a lot of people use, like Amazon, right? Amazon, if you want to do a good job of learning how to find problems in accessibility, Amazon is like expert level. [00:33:11.27] Because I'm sure they have a team of folks who care a lot about accessibility and they are going to be as accessible as they can. Pick some local website, like your, I don't know, some hockey organization, or some random school club, or some small website that doesn't necessarily have to care a lot about accessibility and doesn't get updated a lot and go through it and use the WCAG and use automatic checkers as a way to practice finding problems with websites.

[00:33:40.05] SY: And I'm assuming the ideal outcome for that is after a couple of audits, after getting a little bit more comfortable with the guidelines, being able to integrate that into my development process right off the bat, instead of creating something, then checking it, then realizing that I missed these things, now let me add it in.

[00:34:00.09] SS: Exactly. You're doing an audit, both if you're new to a team, you're new to a code base and you want to know if it's accessible. But a lot of the times you'll do an audit after something already exists, after you've already been sued. (Laughs). I've found that it can helpful to do kind of tiny accessibility audits as you're going through and as you're making a website. There is a client I have currently, who we're building them a whole new website, and they have some pretty strict accessibility requirements. So as part of that, every week we sort of look at a snapshot of the code, and are going through and doing an accessibility audit. There are also a bunch of automated build tools, that can automatically check your site for you, similar to those tools I mentioned before. You can set them up that way just every way you merge code, the same sort of way that you'd automatically run your tests and see if the code is correct. It can automatically run some accessibility checking and tell you if that cool new thing you did broke your site's accessibility

[00:35:01.10] SY:Oh, that's super helpful.

SS: It is so cool. Yeah.

SY: So I want to get into your personal story. How did you get interested in accessibility?

[00:35:11.05] SS: My background is actually originally in psychology.

SY: Woo, psych majors!

SS: Yeah, woo, psych majors. In undergrad, I had started as a physics major and transitioned to psychology. And in undergrad, I was super interested in this field called psychophysics, which sounds so cool right, it sounds -

[00:35:32.01] SY: I don't think I ever heard of that class!

SS: No, it's so cool, it sounds like something a cartoon supervilllain would do, psychphysics, right?

SY: (Laughs). Yeah, that's exactly what is sounds like.

[00:35:43.05] SS: Exactly. So obviously, that's why I wanted to do it. So, it's a field that is sort of the overlap between physics and psychology, that deals with how a person receives stimula from the outside world - so they're seeing something, or they're hearing something, and how their brain processes it and perceives it.

SY: Oh wow.

[00:36:02.07] SS: It is so cool, right. Specifically, my big area of focus is thinking about color - how do different people perceive color, how do different cultures and the different words they use for colors change how they remember color and think about color. It's super cool. But so, that's my original background and I ended up deciding to transition into web development a few years out of college, graduated from dev boot camp here in Chicago, and since then really I have focused on accessibility. Also, in undergrad I was involved in a big interdisciplinary project at the Illinois Institute of Technology, where I went, that had to do with evaluating trains and buses here in Chicago, so part of the Chicago Transit Authority, the CTA. [00:36:53.24]. And determining how accessible their audio announcements were, so the sort of announcements they make on the train of "The doors are closing," or -

SY: Wow, I never thought of that.

[00:37:07.00] SS: Right, or telling you how long it'll be until the next train. Audio announcements like that, right. And we did this whole huge project where we went around Chicago, every line on the CTA, and a bunch of bus lines, and took measurements of how loud background noise was.

SY: Oh, yeah.

[00:37:27.03] SS: Yeah, because within the ADA there are requirements. Essentially, if you look at the difference between the background noise of a space, and the volume of the audio announcement, they have to be different enough so that that way you can hear it and understand it. So as part of this project, we went and took measurements all around the city of Chicago, and wrote up a whole report, and did a bunch of cool math to figure out how compliant the CTA was with the Americans Disabilities Act around audio announcements. Super cool. So then, that's pretty much when my eyes were opened to the ADA - this is really cool. I care a lot about accessibility! So then when I transitioned to being a web dev, I was like ok, how do I care about accessibility here? I have people in my life with disabilities, specifically I have someone close to me who has a cognitive disorder and a seizure disorder. So I'm very cognizant of that. As well as my husband is color blind, so I'm very used to day to day, looking at things and color and helping him out, to the point where I can't not think about it, right. [00:38:39.17] So, again, that's something that transitions really well to the web accessibility world.

SY: Do you recall your first accessibility audit, or the first time you tried to take something that existed or you were building something, and you were trying to make it more accessible?

[00:38:55.06] SS: The first thing I can remember was I think actually my final project at dev boot camp. So, the way that their program was structured at the time was your last week and a half, you would make some sort of cool web app, or whatever project with a team of other graduates. And we made - gosh, what was it - it was called Photo Plop, you could upload images based on hashtags and share them with your friends. And I was lucky that dev boot camp instructors had really encouraged me to learn a lot about accessibility. There was a little bit about it in the curriculum at the time, but they were like, whatever you care about, whatever the cool thing is you want to learn, do it. Do it on your final project. Go for it. And I was like, that's accessibility. That's what I care about. So I remember the tons of hours a week, trying to cram in this final project, and checking color schemes. There's actually, within the WCAG, a required contrast difference between foreground text and the background behind the text. And I just remember trying to understand all of that and use these color checkers to build a color palette that both looked nice and had enough contrast. And I remember not doing it right the first time - I don't know what it was, there was something I totally messed up, and so when I went back to check everything I had done again, the day before we were supposed to be done, I was like wait a minute - these colors are not accessible. [00:40:29.10] Hold up. And I had to go back and like, oh no, I had to change the color scheme. It was a few day project at dev boot camp - it's ok to change your color scheme. But like, yeah. It was definitely interesting. I think I didn't entirely know about the WCAG back then, I was just googling "web accessibility" and reading whatever came up. (Laughs).

SY: Neat. So did it end up being harder than you thought it was going to be?

[00:40:56.05] SS: Yeah. It ended up having a lot - essentially, it was a lot of moving pieces and a lot of things to think about at once. And realistically, if I had given myself some sort of structure to follow or even made a list. This is back to what I was saying about define a standard. If I had just written - ok, I want to make sure my colors have enough contrast, I want to make sure the HTML's written so screen reader can use it, you know, things like that, it would've made my life so much easier.

SY: Yeah, yeah.

[00:41:28.03] SS: Yeah, no. That was the first time I can remember making sure everything was super accessible on a website.

SY: So given that that was the project you were really excited about, the thing you wanted to focus on, was it as awesome and exciting as you expected it to be?

[00:41:45.01] SS: I think so. I think - I mean, that project was also a big lesson in learning how to make an entire - it was a relatively simple ruby on rails app - but at the time, huh, very complicated, it felt very complicated, right? Looking back and like, oh, I could make that really quickly now, but it was like a big exercise in making something big, quickly, with a team, and adding on top of that, trying to make it accessible. And I was using SASS, which is a CSS pre-compiler, I was using that for the first time. I just added in so much new, cool stuff I wanted to do all at once, that it was a little bit overwhelming. So yeah.

SY: Yeah. So, for folks listening who are hopefully a little bit more interested in accessibility and eager to implement these best practices in their own websites, what advice do you have for them?

SS: [00:42:46.29] First, really try to understand experiences that different people have who have disabilities, and the way that they use the web. There are a bunch of organizations devoted to helping folks learn about accessibility, like Web Aim. Actually, Microsoft has this whole fantastic section of their site about building things accessibly and helping people to grow their sense of empathy with people with disabilities. So really just immerse yourself in that part of it to help motivate you. Because I know it's hard to want to learn a new thing that's very technical, if you don't care about it, right? The next thing I'd recommend would be reading through sites that summarize the WCAG and tell you about the most important parts of it. Certainly, every part of the WCAG has value and helps people with disabilities, but some parts of it are basic things where if you don't do this, your site will not be accessible at all. [00:43:45.25] Like, color contrast, I keep mentioning. If your site doesn't have appropriate color contrast, it's going to be a problem for all sorts of folks. So to really work on those basics on accessibility, to care about color contrast, to think about ideas of constructing your HTML, following the rules of how HTML is supposed to work - I would not recommend diving right into reading the WCAG, because as you mentioned, it can be very, very technical in some spots, and somewhat overwhelming. There are folks, I've sort of helped them to learn about accessibility, who will dive right into the WCAG, and go, "Stephanie, there's so much to this. I don't know if I want to do this anymore!" It would be the same thing really if you were to sit down and read the complete documentation for Ruby or whatever your language is.

[00:44:39.05] SY: Sounds ridiculous!

SS: If you wanted to learn a programming language by reading all of the docs about how that language works, you'd probably feel overwhelmed and close the tab and never think about it again. So think about the WCAG that same way. Use it as a reference but don't decide to dive in and read the entire thing from the beginning. Do that later, after you feel more comfortable. [00:45:00.02] Another great way that I really recommend, if in your area there are any accessibility meet-ups, that is an awesome way to learn more about this. I know we have one in Chicago, they are fantastic. They actually did an event series where they broke down each of the sections of the WCAG and explained them and had folks with disabilities talk about different parts of it and how they're relevant to them and it was awesome. Really community resources like that can be super valuable if that's a way that you learn. In general, like a lot of technical things, one of the best ways to learn it is to do it. So, to take a look at even just a simple site, like if you have a little portfolio website, to go through it and start applying some of these accessibility ideas. Because with me, and my project at the end of dev boot camp, I learned so much about accessibility by trying to do it, that can be a really great way to learn about, to just do it, to just try it.

[00:46:08.05] SY: Awesome. So I don't think I put this in the email but I had three fill in the blanks, do you mind if we do that?

SS: Oh, that sounds fun.

SY: Ok, cool. Number one - worst advice I've ever received is?

[00:46:19.02] SS: I don't know if I can quite phrase it - I don't know if I've ever heard anybody say it out loud, but it was the general of like, "You're smart. So, you should do this." Or like, "You have some fundamental quality to you, so this should be easy."

SY: Ah, yes. That's not helpful.

[00:46:39.06] SS: Yeah, exactly. Like, "Oh, well you're smart so you should go into this program in college." Or, "You're smart, do this." As opposed to the idea of something that you have learned how to do, sort of emphasizing "You have an innate quality, therefore approach things in this way."

SY: This is the only option, yeah.

SS: As opposed to the idea of "Oh, I know you've done a lot of work at this," or "You've gotten really good at this skill, so I recommend you do this." Not quite advice, but a mentality that I had - it was the worst thing.

[00:47:14.09] SY: Yeah, that's a good one. Number two - my first coding project was about?

SS: Oh, ok. This is great. So I am a person who learned HTML in like the mid/late 90s. So, yeah. So this counts as coding, right? HTML is coding. I'm a front-end engineer, I believe that. I think my first coding project that I can remember - I was making, I think it was, a page on NeoPets, if folks know what that is? It's like this virtual pet website that got popular in the late 90s/early 2000s. And I don't know why, but I find that there are a lot of coders my age that got their start making silly little sites on NeoPets of all things. It's really weird. I think I made some cute little site about one of my pets on NeoPets and their name and their favorite food. That sort of thing. Yeah. That's the first coding project I can remember that I did.

[00:48:23.02] SY: We've had so many guests who have started their coding journey with NeoPets.

SS: It's so weird. I have bonded with people in interviews before, whom they've asked "What made you start coding?" and I'll mention it offhandedly, and they'll go, "I learned how to code on NeoPets too!" and it's like this moment that we share.

[00:48:45.00] SY: This is great interviewing advice. When in doubt, just namedrop NeoPets and see what happens.

SS: Yeah, exactly. Chances are, they will know it and like it, and if they don't like NeoPets, you don't want to work there. No, I'm kidding. (Laughs).

[00:48:59.05] SY: Great filtering system, I love that. Number three - one thing I wish I knew when I first started to code is?

SS: I wish I knew that whatever kind of code I want to write is a valid thing for me to learn how to do. [00:49:15.01] So specifically, the idea of specializing in CSS and HTML. When I, going through dev boot camp, I struggled with this actually, a lot. Because dev boot camp was awesome and focuses on ruby on rails and backend. And I sort of got this idea into my head that wanting to be a front-end developer was easier, if you can hear my air quotes. That it was easier, or it was for people who didn't understand back-end development. Whatever. Or that if I wanted to be a real developer, I had to care a lot about back-end development. And even actually back into high school, I had taken a computer science class and I definitely internalized the idea that only databases and back-end of things was real coding, and that Javascript and HTML and CSS was not. Even into - I took a CSS 101 course in college as part of my degree program, and I very much thought that the sort of things I enjoyed doing weren't real coding so they didn't count so I wasn't a real programmer. And if I could go back and tell my previous self, it is ok to enjoy front-end development, that is real coding. And in some ways, it is a lot harder, so who cares what people think.

SY: That's right.

[00:50:42.04] SS: The idea of - if your language that you love writing code in, whatever that language is where everything's written in emoji? Like, if you like writing things in only emoji, that is still a thing you should do and is fun and is real programming. Like, there's not some kind of coding that is more real than some other kind of coding. They're just more esoteric and weird than another.

SY: Good one. Oh, I love that so much.

[00:51:13.05] SS: In general, the message I have about accessibility is that if you don't do it, you, a programmer who working on whatever it is you're making, if you don't do it, then who's going to do it? I really believe that we're all responsible for improving the lives of people who use our technology. It's our responsibility to not only make things accessible, so that way everybody can use it, but make things that improve people's lives, because that's the point of technology, right? I don't think there's anybody who goes to work or sits down to work on code and says "I want to make somebody's day worse. And I want to make somebody's life harder." Maybe people do that, but I don't care what those people think. We all want to make things that help improve people's lives and a really great way to do that is to build your technology in an accessible way. Because there are millions and millions of people who you can really help out by making simple changes to your code.

SY: Nice. I like that. I like that a lot. That was a good way to end. [00:52:22.27] That's our episode on accessibility, and it's the end of our first episode of our official first season. So let me know what you think! Email me at hello@codenewbie.org and tweet me @codenewbies. For more info on the podcast, check out www.codenewbie.org/podcast, and join us for our weekly twitter chat. Actually, we have two twitter chats now. We've got our Wednesday chats at 9 PM EST, and on Sunday at 2 PM EST we have our coding check in. Thanks for listening. See you next week.