Accessibility a Developer's User Story

On this episode of Eat Sleep Code, guest Elle Waters explains why accessibility is important in software development and what a developer’s responsibilities are when creating a product.

Guest @Nethermind

Elle works on behalf of Simply Accessible with enterprise level clients to build the foundation of accessibility into every facet of corporate culture. She’s worked first-hand with business, design, content, development, and testing teams to create lean, scalable methods that form the core of accessible customer experiences. She’s seen amazing things happen when teams put accessibility first. Elle has a passion for social justice, a love affair with emerging technologies, and a healthy fear of zombies.

Show Notes

• Simply Accessible
• How to be a keyboard accessibility super hero
• Three common accessibility pitfalls for developers: colour contrast
• #A11y
• Google Accessibility
• Kendo UI Accessibility Overview

Transcript

EC: Hello and welcome to Eat Sleep Code. The official Telerik Podcast. I'm your host Ed Charbeneau and with me today is Elle Waters. Hi, Elle.

Elle Waters: Hi, Ed, how are you doing?

EC: Good, so today we're gonna be talking about accessibility. And I've brought on one of my favorite accessibility experts, Elle Waters. To give you a little background about Elle and myself. I met Elle at a conference, and I was watching a very interesting and informative and yet entertaining session on accessibility, and this brilliant speaker was giving a great session when her MacBook completely died. [chuckle] And when her MacBook died, she kept the best composure of a speaker that was having the worst technical difficulties ever, and I was literally impressed at that moment 'cause that is not something that fits my DNA. I probably would have thrown some technology out some windows at that point. So with that I'd like to reintroduce Elle Waters. Elle, tell us a little bit about yourself.

EW: Thanks. Oh my gosh, I had forgotten all about that, [chuckle] that really painful episode, but that's really flattering. So, I am currently the Director of Strategy at a company called Simply Accessible. What that means in day to day life is that we work with a lot of different organizations, a lot of different companies, different sizes. And I tend to work with companies that are large enterprise companies facing some impossible deadlines for accessibility and large challenges. And I really enjoy the challenge of that and we work with designers, developers, and testers primarily, along with some management to be able to further the cause and help them understand how to be able to build accessible digital content.

EC: So, I wanted to do a show about accessibility. This topic's very important to me, specifically, and I wanted people to understand why it's important to me and others, and understand what accessibility is, and then we can go about giving people some ideas on how to get started and get a better grip on how to incorporate that into their development practices. So, with that said, this is very important to me because my dad has accessibility issues. My dad is quadriplegic, so he has very limited mobility from his neck down. So, there's new technology and things coming around to help him get on the Internet, but there's a lot more people out there that have a wide range of disabilities that use, not only the internet but software in general. And it's important for us developers to understand that those people are out there and that they're being impacted by the software that we write. So, Elle, what types of accessibility issues are out there that we should be aware of, and what kind of people are dealing with the software that we write?

EW: That's a great question, so I think that one thing to keep in mind is that accessibility is not a binary thing and if you have somebody in your life, or you yourself have experienced different challenges, it becomes really apparent. Often times people will talk about specific categories of individuals and user groups. And they'll think about it that way, but the truth is it's a really big spectrum of abilities and it could be something that you're temporarily unable to do something, or it could be that you grow older and as you age into something, like failing eyesight, that starts to become a need or consideration, or you could have a traumatic incident. But the truth is that it's really so many different individuals that it's, like I said, a large spectrum. With that said, that's difficult for people to grab hold of so the World Health Organization estimates that, it's about a billion people. Google put out a really good website and we'll definitely share that link with this, that one in every almost 20 people, 20% of the world's population, basically that we're looking at, has some form of impairment or challenge with accessing or interacting with digital content.

EW: We usually look and think about people who might have vision loss, people who use assistive technologies like screen readers, where it takes the text on a website, webpage and will read it aloud. There are also people who use screen magnifiers. The other category that we often talk about might be people with different mobility challenges. Like you said there's people who have limited mobility and different parts of their limbs, sometimes they'll use technology, they'll use things that emulate a keyboard. And so, they might use a Sip/Puff device, or a virtual keyboard and there's amazing things happening with technology that are making that a really creative area to explore how to be able to provide more access for people, and how to be able to allow them to have more independence.

EW: Then there's also people who have different levels of hearing loss, so people who are completely deaf or people who have different kinds of limited hearing. And then finally, most of the time what we kind of almost sometimes overlook I think in the web community is that there's a huge gradient of people who have cognitive challenges. So, autism is definitely something that you hear more and more about on the news. Well, there's definitely some impacts when it comes to your content strategy, your site map, how you create the interactions on the web that are either consistent or predictable or not, for people with different cognitive challenges. Dementia is another one that's really taking hold of the public consciousness because of recognizing that there's an increase. As people get older and technology gets better we're actually encountering more and more disabilities related to age.

EC: Yeah, I think it's really important to identify what you said about the technology getting better. As we see IOT and other technologies like natural language interfaces and things like that coming into the mainstream, almost anybody can get on the internet and those type of things are really changing lives of these people. And to have our software to where everyone can access it is extremely important, not just from a feel good perspective but I'm sure that you could give many other reasons that you have examples of.

EW: Yeah, it is a really exciting time. It's such an amazing area of innovation and, like I said, because medical technology is getting better. So people are finding that where something might be completely an end of life scenario for someone, these days, in the 21st century, they're finding ways to be able to live with different kinds of severe disabilities. And in keeping with that as well, there's some amazing technologies happening everyday being invented that allow people, like you said, more abilities to live independent lives. And technology's so integrated in everything that we do in our life that it is something that's a fundamental piece of what it means usually to be having a bank account or shopping and that kind of stuff. All those things tend to interact with digital content.

EW: I think that it's really interesting to see how people interact with all of these different things and the challenges that they face because, by and large, more often than not, what people encounter as difficulties are the same problems that they've had before all of these technologies and inventions came into play. So the challenges that people have with accessibility are actually much more solvable and not really directly related to some of these newer technologies, for example. We see at least within our line of work that it's the same kinds of challenges that we've seen all along which mostly goes back to building good code, following web standards, keyboard accessibility is a great example. That's not nearly that much different just because of mobile applications or internet of things, it's really the same kinds of needs that people have. So their needs haven't changed even if technology is different and their recommendations are pretty straight forward, very much the same kinds of recommendations that we give.

EC: So what should developers specifically be aware of, what are some key points that they can look at?

EW: Well, I think that this is gonna sound like I'm scolding when I say this, but it is true that more often than not, probably 60% of the time when we are looking at something, let's say, some front end web code, looking at a webpage for accessibility, two thirds of the time, it'll be something that was actually not specifically related to accessibility. That's a problem. And much more about, like I said, web standards. So if you create a <div> and it looks like a button and you want it to act like a button, make it a button, not a <div>, right? Because the truth is, all these different assistive technologies they have to go and interact successfully with stuff. They have to use a ruler, a standard, and so the W3C has pretty much told everyone how to create valid HTML. And so, when you get really creative and you put a faux element out there and for the purposes of a design visually, it looks like a particular... "It looks like a radio button. I really thought it was a radio button." And so, a screen reader will read that and it won't know how to interpret that. So, I think one of the first things we tell developers is, "You know the right thing to do. You know how to use these elements and do your best with that," and that actually solves a lot of problems.

EC: So developers write semantic HTML, please. [chuckle]

EW: Yes. It matters. [chuckle]

EC: Do not <div> all the things.

EW: Don't <div> all the things and progressive enhancement is not old-fashioned, it's actually still the best way to build a webpage. So, just because there's the new hotness which we all agree is the new hotness out there for a JavaScript library, does not mean that it replaces the need for HTML or that it actually is maybe more significant than the CSS that you put there. But layer things according to what they were meant to be done, the purpose they were meant to serve.

EC: Yeah. I don't know how many horror stories I have of opening up a web document and finding just straight divs through the whole thing or headlines that were made out of bold tags inside of [chuckle] more bold tags, inside of other inline styles that mimic an H1, H2 scenario. There's countless times I've encountered these things, and a lot of those are in CMSs. And it can be really horrendous. So, I know you guys are out there. Somebody is writing these stuff. [chuckle] I've seen it in the wild. And I'm gonna go out on a limb here and say, they're probably not the folks that're out there listening to podcasts or reading articles or visiting conferences.

EW: Yeah. Not your listeners. [chuckle]

EC: There maybe few and far between those crowds. So if you're listening to this, scold those people that aren't listening and aren't reading and aren't getting in touch with the community, and don't know the web best practices for HTML markup. Get the word out.

EW: Yeah. And there's ways to approach things. We're not dismissing the need and importance to be really creative. There's absolutely a need to be creative because you get challenges all the time. And how to be able to build something in a way that meets whatever the design spec is, for example, but the real challenge, going from good to great as a developer is being able to maintain the same level of standards that you would expect when you were first learning, how to be able to code, maintain those same standards, and then find a way to be able to do that. And of course, the second thing that I would always tell developers is - test your code. Not you and not necessarily running a test sweep, but with a real live actual user. Well, we're big believers in agile, and one of the main reasons is because the real proof of success is what that user feedback tells you. So test your code with real people, and if you're looking to make something accessible, make sure that you do some usability testing with people with disabilities. There's ways to be able to accomplish that and pull that feedback in and you'll know whether or not something is really actually fully accessible.

EC: Yeah, I think it may have actually been you that said, "Accessibility will separate the good designers from the great designers."

EW: Yeah. It makes good designers great and bad designers obvious, right? And it's a challenge. Nobody said it was gonna be easy, but it is something that is... Some parts of it are really well known. Like I said, developers who would be listening to this podcast, the things that you guys know, that you've always known, you will always know that an H2 is actually a heading. So use it, embrace it, love it. Semantic code is there to help you build things correctly and honestly, makes a much better webpage. You don't have to do nearly as much testing, and tweaking, and jacking up your code to be able to fit different browsers and different devices and different resolutions. One of the best things that ever happened for us in the web accessibility world was ushering in of responsive and mobile web because you can't really hide, right? Bad code becomes pretty obvious when it's thrown into some weird mobile device that nobody ever knew to predict to build for.

EC: Yeah. And developers don't throw your hands up in the air and say, "Not it," when I say designers. [chuckle] Because front-end developers, I'm talking to you. [chuckle] And most developers are designers in some capacity, even if you're a back-end developer, you're designing APIs. So don't play the, "Not it, I'm not a designer" card. If people are interacting with the thing you're building, you are designing something.

EW: Yeah. And even if you're a backend developer, there's a progressive enhancement beauty to what you do as well. So, API should have data. Don't put CSS and markup and stuff and push that from some backend piece, leave the layers where they belong.

EC: So, what can we do to relax the developer's fears about accessibility then?

EW: So, I think one of the biggest most intimidating things that developers often face is when they really start thinking about all the different types of disabilities there might be, all the types of user scenario there might be. These really complicated, scary, different and sometimes expensive assistive technologies. It can be very intimidating to know where to start. It can be really intimidating to feel like you have any confidence to actually accomplish this, and do well at this, and succeed in this. And so, a couple of things that we usually talk to developers besides just that they already know certain things, like building to the specification is really the first step in knowing how to be able to build good code is one of the foundational pieces for accessibility. But another thing that we often talk to developers about is they actually have the most important piece of assistive technology already with them. And it's not their brains. Although that's a great piffy way to end that sentence. It's really a keyboard.

EW: So unplug your mouse and see if you can actually complete a task; if you can go through a particular shopping cart experience and a modal dialog pops up, can you actually get out of that modal if you choose not to do whatever it asks you to do. Use a keyboard and you will catch so many issues and keyboard accessibility is the most fundamental kind of accessibility that we would ever recommend, and it hits and really positively impacts the largest group of users that would be using that product. And then we talk to them about... Go ahead.

EC: I'm gonna take a moment to remind folks too, Telerik has multiple products. Kendo UI, UI for ASP.NET MVC, and UI controls for ASP.NET Web Forms, our AJAX products. All are 508 compliant, so if you're worried about your development process and you want something that you know is going to work with the keyboard and some of the things that Elle's talking about, all of those control suites, we do have full accessibility support on those products.

19:16 EW: And rigorously testing something with a keyboard is something that anybody can do, there's no training that you need to know. "Can I use this with a keyboard?" And so, it's a great tool that we recommend for developers when they're just starting out and it's definitely the most impactful, like I said, for end users. We like to call keyboard, images and forms, the accessibility MVP. We often say that because when you look at something you wanna make sure that you're bringing the most value for whatever product you're building for your end users. That has the most value for people with disabilities. If you approach keyboard, images and forms in that respect, you've really covered a huge amount. Especially with forms because that can get pretty complicated, but I would say that's usually where we start with developers and it's something that is achievable, it's something they can see real success with, they can see huge benefits from. And then to just go from there and it's one of the things that, it's really something that may take a while to get to a point where you feel like, everything I do is fully accessible. But it's at least a starting point for you as a developer to know that this is a really huge benefit to people.

EW: There's a really good website called the a11yproject.com, specifically tailored to developers. And it'll have different kinds of code resources and some descriptions about why a particular widget works the way it does. It has some questions and answers about, for example, when to use title attributes, and the answer is 'almost never'. [chuckle] And different things like that that's really helpful for developers. And then, on our website, simplyaccessible.com, we have a basic series that we're going through. This year we're really excited about it because it's starting from the ground level and we're approaching it from the things that we get asked questions about most. We're trying to go through those one by one and make sure that we provide that feedback. Oh, and I almost forgot to mention too, so if you hang out on social media, and you love the Twitter, one of the things too that's also helpful is you can start searching for the #A11Y, and it's basically, accessibility has 11 letters between A and Y, the way that they do with internationalization, which is like, I18N, I think. So A11Y is the hashtag that a lot of people, a lot of industry experts, a lot of disability advocates, a lot of developers and designers will basically have really great conversations and you can definitely find a lot of help. If you have questions it's one sure fire way to be able to get some answers.

EC: So, we talked about best practices and we have some great resources. Do you have any other getting started information that people should look at?

EW: I think it depends on where your particular technology stack and what you're working on is. There's a lot of great advice, for example, jQuery is a good library. There's Telerik, there's a lot of these other places where you'll see, not only, "Here's the library of different elements or scripts that we provide", but, "Here's things that are important to consider about accessibility." So I think one of the things I might recommend to developers is to go to the particular technology that you're using, that you're employing and see first if they have particular solutions that they've created for certain reasons. Like I said, there's great stuff on Twitter, there's really good stuff on, of course, Simply Accessible's website. And there's a lot of good conferences. My favorite conference is in Austin every year. It's called AccessU and it's a two day conference with a one day workshop and it's about maybe 300 people and it's totally devoted to accessibility and it has different tracks, and it's got a really robust developer track. And a lot of different industry experts go there and teach very hands-on exercises and then of course it's in Austin, so that's awesome. You get fantastic barbecue, and that's May, every year. And so, I would definitely recommend that. It's a great conference.

EC: Now, Elle, do you have any advice for people that would like to have some help with testing? Is there a proper way to approach somebody that they'd like to have, maybe, test something for them, that has certain accessibility needs? Do you have any advice for that scenario?

EW: Sure. So, there's multiple types of testing, right? So, oftentimes, when you think about testing, just in a day-to-day world, you wanna think about automated testing, which has some benefits, but really only covers about a quarter of accessibility issues, but there's huge benefits, at an enterprise level, to consider where automated testing fits in. Definitely the way that you might do with Jenkins or Selenium, you wanna be thinking about those easy to catch things that you would have and say, continuously integrated kinds of code bases. And then from a manual testing perspective, you definitely want to approach that from a perspective of training up your QA staff, to think in terms of that, sort of MVP model, so that they feel comfortable testing keyboard, images and forms, and then going from there, but I think what you're talking about is probably closer to the other thing, which is usability testing with people with disabilities, where you'd have a real world scenario, and the thing that is a little bit challenging is, with most usability testing, what you don't want to do is really frustrate somebody, an end user.

EW: And so, I would recommend that before you start thinking about maybe testing with people with disabilities, that you make sure that some of those basics are covered first. So, just as an example, you probably wouldn't want to go to somebody that you know uses a screen reader, and ask them to test your webpage you built, if you, yourself, haven't tested first to make sure that the keyboard accessibility is really intact. Because otherwise, the whole page is pretty much locked out for them, right?

EC: So, you don't wanna hand them a hot mess? [chuckle]

EW: Yeah. The short cut of that is, do a little bit of the basics first, and make sure you feel pretty comfortable with where that's at, and then definitely incorporate people's feedback, but just make it worth their time, in order to be able to give you some of those other things. Like, one of the benefits of testing with somebody with a screen reader is that they may tell you it may be keyboard accessible, but maybe with the way you've coded a particular tool tip, it's not something that voices allow with their screen reader. And so, that's something that is really valuable information to get, but it's at that particular stage where you wanna be able to get that detailed feedback. There's a couple of services and people who do usability testing with people with disabilities. When we're working with clients, we work with their customers, so I would say one of the things that you wanna do is maybe reach out to the people who do usability testing, at your organization, and ask them whether or not they have a way to be able to pull in different participants who might have different disabilities.

EW: It's something that... It can be challenging, because it's not like everybody's organized, or that they have a marker, saying, "I have to have this particular disability," right? They're human beings, and they're going about their business. A great thing to do... There's a really unusual high volume of developers who are color blind. It's surprising. There's usually one in every eight or nine men is color blind, but that number has actually increased when you start looking at web developers. So I'm gonna say that my guess is that, as a developer, you might know someone who's color blind, who's actually your co-worker. And that's a great opportunity, because then you can just talk to them and ask them to take a look and see, "How does this look? Is there enough contrast between these two different colors?" So, those are some first recommendations I would have, and I think that, definitely, somebody should just contact me and I can give them some links in some other areas, about where they might wanna go, given the kind of work that they're doing, 'cause that makes a difference.

EC: So, if you have any feedback for the show, regarding accessibility, please stop by developer.telerik.com, and leave a comment in our forums there, or you can also go to SoundCloud, and there's a way to comment in SoundCloud, as well. SoundCloud will actually let you leave comments on the actual point in the track, which is pretty handy. And we'll try answer some of those questions. You can also find Elle on Twitter, and @simplyaccessible, and we will post links on our show notes, so you can get in touch with us and Elle, and to find some of the resources that we talked about today, and get started with your learning journey on accessibility. So, Elle, I really appreciate you coming on the show. It's always great to talk to you, and you always have lots and lots of interesting information.

EW: Well, thank you so much, Ed, for having me. I love the opportunity to be able to talk about it, to share with people. We have, as a mission, to make it less frightening for people to jump in to accessibility and include it in what they do each day.