Back to Blog

The Dirt: Accessibility with Marla Runyan of Perkins School for the Blind

Author

In honor of 2017 Global Accessibility Awareness Day (GAAD), we had a special guest in the studio to chat about all things accessibility. Marla Runyan is the Director of Digital Accessibility at Perkins School for the Blind and runs Perkins Access, consulting with people and businesses to make their products and websites accessible to all. You may also know Marla as a star track and field athlete, road runner, and marathoner. She’s a 5-time Paralympic gold medalist and is the only American athlete to qualify for and compete in both the Paralympic and Olympic games.

During this episode of “The Dirt” Marla shares the background on accessibility standards, why it’s imperative to meet those standards, and how you can get started solving the challenges people with disabilities deal with on non-accessible sites.

Listen to the show

Show notes:

Check out some of the resources Marla mentions during her interview to learn more about accessibility standards and tools you can use to ensure your site or product is accessible:

Check out some of our thinking on accessibility. Are your digital properties compliant? Do you want to ensure they are accessible by all visitors and users? Get in touch with us for a conversation about how to get started.

Read the show transcript:

C. Todd Lombardo: Good afternoon, everyone. Welcome to the Dirt. I’m C. Todd Lombardo, Chief Design Strategist here at Fresh Tilled Soil. I’m joined by a few really interesting people. I’m joined by Marla Runyan who’s the Director of Digital Accessibility at Perkins School for the Blind, Alex Holachek one of our developers and Scott O’Hara, our Director of Development.

Scott O’Hara: Hi.

C. Todd: Welcome to the show.

Marla Runyan: Thank you.

C Todd: Obviously with somebody in the room from Perkins School for the Blind, which is a very well-known, respected institution here in Watertown, we’re going to talk a lot about accessibility and what does that mean for digital products. So, maybe Marla, you could start off by just giving a general overview, especially for our audience who may not have this as top of mind, what is accessibility?

Marla: Well, when we talk about accessibility of a website or electronic documents or any digital product, we’re talking about the ability of all users to be able to use that product. Including users with disabilities and users who may use assistive technology. And so, what that really means is you have to think about how that product is developed and created. And there, I always say that if you’re building something, accessibility is intentional. That, if somebody said to me, hey, I just built this website, will you let me know if it’s accessible. And, I would say are you familiar with any of the accessibility techniques and how to build an accessible website? And they say, no. And, I say, well, it’s not going to be accessible. It just doesn’t happen by accident. It’s not going to be like a happy surprise. I built a website and I got lucky and it’s successful.

It’s very much intentional. So, I think in today’s world, understanding what that means and the techniques that go behind in the scenes of your websites is what assistive technology is looking for. I always break it down as its high-level in saying that it’s about respecting the semantics of HTML. That alone has a huge impact on accessibility. And understanding that a screen reader, for example, which is what someone who is blind would use to access your website, is reading those tags, is identifying components and elements and content by whether you choose to use a link tag or a button tag or a heading tag. If you use these tags disregarding their semantic meaning, you’re in a sense impairing or disabling the accessibility of your website.

C Todd: And you mentioned assistive technology, can you talk a little bit about what that means with somebody who maybe not have that term top of mind.

Marla: I think a lot of people think assistive technology is always something that you plug, that’s electronic, that has an on-off switch. And that’s not actually true. Something like a white cane is actually considered assistive technology. It can be any product, even products that you can by off the shelf that essentially enable a person who has a disability to function more efficiently and more independently.

C Todd: Is the screen reader that you mentioned earlier, is that an example of assistive technology?

Marla: Yes. So, some assistive technology products are very specialized for specific users such as a screen reader or screen magnification software. That are sometimes sold by third parties. Other times, they’re free. But really just also keep in mind, something like Siri. Most people don’t think as Siri as assistive technology, but for someone who can’t type or someone, you know, who’s going to use voice command to get information, they’re using it to function more independently. And, for that person, they’re using it as assistive technology.

C Todd: That’s really interesting. There was another person I interviewed on Product Hero recently who does facial recognition software and used a combination of their algorithm with Siri to help people with Alzheimer’s identify friends and family. It’s kind of an interesting application. But, you said a couple of things in your answer to what is accessibility, that I’d love to hear a little bit from Scott and, or Alex. In terms of, you talked a lot about respecting the semantics of HTML, I’d love to hear Scott, Alex, you work on it, you write HTML every day. Tell me a little bit about, how does that affect your work? How do you as developers incorporate that into what you do?

Scott: You can’t have a web pages without HTML so, it’s pretty darn important, I would say.

C Todd: In terms of respecting the semantics of it. So, it sounded like code is not accessible written just by its nature. It has to be intentionally written in a certain way.

Scott: Yeah.

C Todd: To be accessible. So what I’m curious is, as you work on projects, as you write code, especially HTML what is it that you have to keep in mind as a developer that maybe, maybe other developers or the developers listening may not have it top of mind to be accessible.

Scott: I mean, I look at it this way, I look at it like every project that I’m doing, every design that I am converting from static blocks or wire frames in the code and stuff, I’m constantly questioning, what is the context here? What is the intended meaning behind what’s going on? You know, do we have something that, for whatever reason, is styled to look like a link but the actual way it should be used, like would indicate it would be a button. You know, like links are supposed to go to different pages or are supposed to bring you to different pages on, or different sections of your current page.

So, if you have a link that either doesn’t have a trap attribute or has just a pound in it and no other URI (Uniform Resource Identifier) to jump you around the page and you’re using that as a way to trigger another function on that page, whether that be through JavaScript or … really should only ever be through JavaScript so I’m not going to talk about anything else there. You know, it’s like why are you doing that? Like what’s, why would you use a link when there’s a completely appropriate button element that you should be using that gives you the semantics and the appropriate functionality that you’re actually looking for?

C Todd: Mm-hmm. What that sounds like to me, a bit, is really thinking about the design and user experience of the side page or product as you’re writing the code for it. So, I’d love to hear a little bit about, so from the designers in the audience who maybe aren’t writing code but are doing the designs, what does that mean? Because those things have to be thought out in advance or maybe in conjunction in writing that accessible level code.

Marla: When I do presentations on web accessibility, I’ll say, it looks like a link but it’s not a link. It looks like a heading but it’s not a heading. Or, it looks like a button but it’s not a button. An example is, you know, there’s lots of divs and spans out there that people are creating to do and behave like native HTML element. And so, when they do that, you have a screen reader user for example, lands on what should be a select element, should be a drop down. But it’s not, it’s a div. So, it isn’t identified to that, when I talk about the semantics of HTML, I don’t have the semantics now to tell my screen reader, hey this is a dropdown. So, natively and by default, if a select element were used the screen reader would land on that and it’s going to tell the user what type of element it is. And the user will know and be able to operate that element.

But, when you create things that like, you create a form control out of a div, it’s not going to be accessible. Then you’d have to go through a process that I’d probably have to defer to Scott on to make it accessible. But, in reality, it would have been so much better to start with something that worked to begin with. And then another example might be using heading, you know everybody has classes in their CSS for their headings. They have their H1 and H2, they have certain colors and font sizes associated with those classes. And so, they’re like, hey I want this particular piece of text to be nice and big, and bold and large, and stand out so I’ll just make it in H2. Well, what you’re doing, you’re using semantic elements to create visual presentation.

And, that’s where we run into accessibility issues because a screen reader user is going to navigate your page by heading. They’re going to want to skim your content and they can jump heading by heading, by heading. If they’re landing on content that’s really not a heading, that doesn’t function as a heading, you’ve created this, this complete, you know, confusing or, you know, you’ve destroyed the relationship between elements on your page and the content. So, it’s respecting that, if you understand how users, a variety, all users come into a website and are going to be looking at your page in a lot of different ways. It’s not just a fully sighted user coming in and looking at the page that you built with 20/20 vision and so forth and is going to use and a mouse user.

You’re going to have to open up your mind and thinking to say, someone might come into my page and completely flip flop my color scheme because they can’t, they can’t see text against a white background. So, they might use their assistive technology or features within their browser to change the color scheme and make it reverse contrast and completely throw whatever colors you thought important to your site, out the window because that’s what they have to do. That’s what that user has to do to access your site. So, thinking about, as a developer, all the ways users, including users with disabilities, are going to come into your site. How they’re going to, the type of technology they’re going to use to access your site. And, really respecting that semantic markup and not using it for visual presentation but using it, in fact, for what it is intended for.

C Todd: Yeah. That’s really interesting and certainly a lot of implications for the design of the page as well. And, to think about just even the inverse of colors. Right. So, a designer may spend a lot of time and energy picking and choosing the color pallet for a page or the color pallet for a layout and yet something with a screen reader or something may come and flip and invert it so that the user can actually read it in a way because their capabilities don’t allow them to see it. But, let’s say like the remainder, the majority of the population …

Thinking about that, what are some of the things that, you know, if you’re a product owner, product manager, designer, developer, you’re working on a website or a product, a digital product, what are some of the things say you’re not taking these, this isn’t top of mind, this isn’t how you naturally do your development work for getting product out the door. What are some of things you can start to do today? Like, where can you go to look? What are some things to think about? How can you start to incorporate these elements into your product?

Marla: I have some favorite like resources that I’ll post for like, especially for end developers who are just getting into accessibility.

C Todd: Mm-hmm.

Marla: Like tutorials and things like that. So, I’ll post them.

C Todd: Great. And you mentioned, WCAG and tell us a little bit more about that. Why should we care about those kind of things and where can somebody else, where can somebody learn more about that?

Marla: WCAG stands for the Web Content Accessibility Guidelines. It’s often people say WCAG for short. And WCAG, we’re currently at WCAG 2.0 and that was developed by the W3C, which is the World Wide Web Consortium. We have many members of W3C right here in Boston area. I’m actually on the W3C Low Vision Taskforce. So, we are working on WCAG 2.1, hopefully, to come out in 2018. But WCAG, if you just Google it, you can go into the W3C has several, has entire libraries and resources all on what is WCAG and understanding what it is.

And, I’ll give you high-level overview of WCAG and that, the Web Content Accessibility Guidelines is basically a set, everything is based on four basic principles: perceivable, operable, understandable, and robust. So, every criteria that they have, that they recommend or, what’s called the success criteria to meet the guidelines within WCAG, fall within one of those four principles: perceivable, operable, understandable, robust. And if you think about it from a usability, any user would want those four things. I need to be able to perceive your content. I need to be able to navigate and operate your content, and through your website. I need to be able to understand what I’m supposed to do, right? And, it needs to be compatible, it needs to be robust enough and compatible with my technology so I can use it.

So, that’s kind of at a high-level of what WCAG is covering. Within WCAG, you have your guidelines and then you have your success criteria and those are your technical standards essentially for what we define today as an accessible website. The success criteria or SC are then at three different levels. Level A, which is most essential. Double-A, which again, I would also consider essential. And then Triple-A, which is like above and beyond but great, best practice type of techniques. Currently, the Single-A and Double-A success criteria, which together make up 38 criteria are now being adopted into legislation for web accessibility. If anyone knew, heard the news that the Section 508 Standards has refreshed and is going to be incorporating WCAG 2.0 Double A into the standards for web accessibility.

Right now, we all look to WCAG to say, is this site accessible? We think, okay, does it conform to WCAG? Is it meeting those 38 success criteria? And, that’s what we have right now to lean on. That’s the international community is also leaning on WCAG as well, knowing very well that WCAG 2.0 is almost 10 years old. So, it is due for a revision, which is coming. But, more importantly, I think, we have to consider not just these criteria but, again, coming back to user experience. And, even if you implement techniques that align with WCAG, there’s still, in today’s web, it’s sort of the technologies and in today’s web have kind of outgrown WCAG to some degree. So, we really need revisions to WCAG and we also just need people to be more aware that this is out there and that there are guidelines in place. The W3C has also created techniques with code examples on how to meet the SC within WCAG. So, it’s all out there. It’s just a matter of doing your homework and learning how to do it and learning why it’s important.

C Todd: So, let’s try to answer that question. Why is it important? Let’s say, if I can play devil’s advocate, why do I need to spend this extra time and energy? Time is money. And if I’m a start up, I’ve got a digital product out there. This is going to cost extra money. What am I going to get in return for this?

Marla: So we say three things. It’s good for your business, right? It’s the right thing to do and, essentially, it’s the law. I mean, right now and I don’t want to go too deep into the legal environment for WCAG or for website accessibility. But, if you have a, if you’re an e-commerce site, for example, you’re selling products and someone comes in with a screen reader and they can’t buy a product, they have a case, they have a legal case against you for discrimination. Because I don’t have the same access as somebody else who can see. So, that’s already happening and happening and very pervasively throughout and that’s what, I think unfortunately, even though we’ve had these guidelines available for like I said, almost 10 years. And, while this is the right thing to do and it’s smart because why would you want to close the door on a consumer.

Everyone knows that you can’t build a store, a physical brick-and-mortars store and exclude people from entering your store and shut the door and say, oh you can’t come in. So, why are you doing that on your website? Why would you, if your goal is to make money and sell product, why restrict who can come into your store? So, you have, again, it’s smart business if you want customers. Number two, you are at risk because, again, there’s somebody who can bring suit against you for discrimination. So, I think a third motivator, in my mind, is that when I know a site, when I work with clients and help them build accessible websites, it’s just a better product.

It’s a better product for everybody because a lot of the criteria of WCAG, if you think about it, being able to navigate, know where you are, knowing your location, who doesn’t like that? Who wants to not know where they are on a website or how they got there? You know, who wouldn’t appreciate having help or support. So, like, for example, you can have one of the WCAG Triple-A guidelines is to have a help option. You know, to be able to have, explain or define terms that some users may not understand. So, I think if you think about it, you know, a lot of these criteria really support all users. It’s not just for people with disability but at the end of the all, if you did it right, if you built it right, you’re going to have a much better product.

Scott: I don’t think there’s a single designer, developer, anyone out there who actually goes into building an interface thinking, I’m going to do this for all. I mean, if you are out there. I mean, please stop. Think about any other industry where you are tasked with building something, you know, think about just even building a house. You’re not going to just go in and just start willy-nilly throwing stuff together and hope that in the end, it all stays standing, you know? You kind of have to know what you’re doing to do your job and to do it appropriately. So, in the overall, in the umbrella of wanting to do things right, wanting to build experiences that will be useful to everyone and not discriminate against anyone.

You know, it behooves us to actually, really understand what it is that we are doing. If I’m going markup my website, my application, like, there’s a reason that these tags exist, these different HTML elements. Use them. There’s sites like Mozilla Developer Network out there, that has, is a great resource to understand some of the context behind the different markup elements and their attributes.

C Todd: What is ARIA (Accessible Rich Internet Applications)? And what does that do, why would a designer, developer need to think about that?

Marla: When I was saying back, when I said that building something in successful website is intentional, I was actually thinking of ARIA specifically. Because ARIA is essentially, you’ve got this suite of attributes and properties that communicates specifically to assistive technology like screen readers. So, let’s think of something like expand-collapse mechanism component. And, you can put an ARIA expanded equals false or true to communicate to a screen reader the state of that accordion panel.

Scott: Yeah. You would do it on the button elements that basically toggles the visible states, the successful state of the panel content associated with that.

Marla: Right. So, like that’s a little, when I talked about HTML semantics, that to me is almost like the foundation of an accessible site. But, then when you get into ARIA that is something that’s very intentionally done to enhance accessibility. One of the criterion in WCAG is called Name, Role, Value, it’s called 4, 1, 4.1.2 as success criteria Name, Role, Value, which basically says that somebody coming into to your site needs to know what something is, what does it do, and what state is it in. So, if I’m coming in and there’s a set of accordions and I can’t see but I’m using screen reader, it’s identifying that hopefully my trigger is even going to receive keyword focus because I’ve even seen that where those were not focusable elements so my screen reader never even found them. But, if I do find them, I want to know, if that menu, is that accordion collapsed or expanded. And, that’s what ARIA does.

If it tells me that information so that I know that I move forward into my next, next element on the page I’m going to be into, I’m now reading the content within that panel. So, it’s really kind of awesome to see it all work. I’ll be honest. We worked with Perkins Access, which is the consulting group that I lead over at Perkins. We’ve been working with these developers on the build of a new site and the first thing we had to address is the main navigation, you know, menu. And, they had, you know, drop downs and so forth. They had little blue arrows that indicated to a visual user that this is going to have a drop down of sub-menu and so forth.

And, in working with them, we were able to create, they were able to create a fully accessible, keyword accessible, and, you know, accessible for a screen reader user navigational menu. And that you can come in with screen reader and know exactly where you are, know exactly if you’ve triggered drop down or a sub-menu, you know if that menu is open or closed. It’s … When it all comes together and works so well, it’s pretty awesome. And, there’s no compromise, I want to reiterate, there’s no compromise to how it looks visually. I think there’s a misunderstanding that an accessible website is either boring or only text or I can’t use pictures or I can’t use certain colors. I think people have a misunderstanding that they are going to be very limited in what they can actually design and create if they want it to be accessible.

And, that isn’t the case because there is a lot you can be doing in your code that’s conveying that information to assistive technology without compromising that visual design. It’s still there. So, it looks cool. It’s a very cool website for, I think, all users because it’s so, the layout was so simple and well done and we, of course, went through all the contrast specifications to make sure they were meeting all those for people with low vision. And, now they have working menus. What a concept, right?

C Todd: Right.

Scott: Right.

Marla: What a concept. And you hit those global components and they’re all through your domain and they’re going to work on every page. So, that’s how we want to, that’s the goal. If we can especially hit into the global, how you, the components and elements you have globally. You know, if you talk about all your form fields, usually you’re going to use the same kind of text field that you used on this page and on that page. So, let’s get it right. Let’s make sure that’s working it right, you labeled it correctly. And, then you can go put it on every page in your site. But …

Scott: Right. So, backing up a second there. The reason that I kind of introduced RESA and I don’t know if I should talk about this is because one of the first success criteria for using ARIA is not use it. And, the reason for that is, you know, in the examples that Marla was just talking about, we’re talking about fairly complex web components. An accordion isn’t something that exists in the HTML markup language. You know, we have summary in details that are getting more support finally. And, they could potentially be used as something like an accordion in the right context.

But overall, there’s no such thing as an accordion HTML element. So, the best time to use ARIA is for, you know, complex components. Like those where you’re essentially creating an experience that you need to augment with additional semantics, to make it truly accessible because you could build an accordion without ARIA attributes on it. But, you know, like the ARIA expanded attribute to be placed on the button trigger for the panel, if that wasn’t there, it would still work as long as you had the appropriate JavaScript in place to make it function correctly. But, it’s that little bit of extra information that makes it a better experience for assistive technology users.

One of the other things that I wanted to kind of point, touch on there, is that JavaScript is also incredibly helpful for accessibility. There seems to still be a little bit of a misconception that JavaScript is somehow bad for accessibility and I would say that’s only true when you’re not writing JavaScript 2 appropriately. Like if you’re making a divs clickable, I would consider that JavaScript bad for accessibility because you’re recreating functionality that you could have had from using an appropriate HTML. But instead, you know, rewriting, an existing element to behave, again, like a button or a link or what have you.

But, in the case of using it, using ARIA, you absolutely need JavaScript. ARIA in and of itself has no actual functionality behind it so to toggle an element, again, using the accordion example, to toggle whether that trigger announces that it is expanded or collapsed, that particular state, you need JavaScript to do that. You can’t do that with HTML and CSS and ARIA alone.

C Todd: So, that’s interesting, that also makes me think about things about website in terms of something that might be a, like, for examples perkins.org is their publicly facing website but then you have a, which may be a single page or multiple pages, assuming then you might have a product, which could be something like, let’s say, Evernote or Gmail. Like you have its own log-in and then there’s things behind it with functionality. How do you attack or address, maybe a better term is address accessibility issues when you’re thinking about creating something that’s more product focused versus necessarily a public facing website?

Marla: A product, meaning are you thinking about like web-based application?

C Todd: Could be web-based, and that’s the other thing that’s in my mind is mobile. Is mobile devices are a whole other public category of accessibility. But, we’ll start off with the sort of web products and web applications.

Marla: Well, just one thing to keep in mind if you’re a web application developer, is that obviously your goal is to sell your product to somebody. We’re actually seeing this now, we got talking about procurement. You’re talking about, so, if I go to a bank, I won’t put the name out there. But, let’s say I go to a bank, I don’t put the name out there but let’s say I go to a major bank website and now I’m going to they have, let’s say they have a little feature on there where I can go in and enter my information and get my retirement, you know, plan or something like … I’m actually using a third party, I’m actually now even though I think I’m still on that bank’s website, I’ve actually gone into an application that someone else built. The bank didn’t build it, they bought it.

So, but the bank wants to be accessible and the bank is a consumer of that application. They bought that product. So, it’s sort of this trickle down effect. It’s like if you’re building an application, you want to sell that application. If the consumer demands that your application be accessible and not only do they demand it but they require you to prove it, you now don’t have a choice in terms of developing that web application. And this is becoming more and more prevalent as consumers continue to insist that those third party applications are accessible.

Because if they’re not, then the consumer him or herself or the entity is actually liable. At risk, at legal risk, even though they didn’t build it themselves because that application is performing a basic function or an essential function of their site, of their domain. And, so that’s just something to keep in mind. If you’re building something that you want to tell, who are you selling to and what are they going to require of your product? You know, and to be able to say, yeah, our product is meeting WCAG. You have, you’re ten steps ahead of your competitors. So, that’s something, that’s my pitch for web accessibility for web application developers.

Scott: No, I think it’s actually a really interesting point to bring up too especially in the, you know, current landscape where, you know, there’s so much open source software out there right now too. There’s so many open source plugins that people can download to get their, you know, development up and running quicker. It’s awesome that people share their code and, you know, contribute back to it so that we can, you know, move ahead quickly with what we’re building. The problem with that though is because not everyone has a strong foundation in accessibility, there’s a lot of stuff out there where it may really be popular but it’s not particularly accessible.

And I would hope that, one thing that we can hopefully change as a development community, the more we talk about accessibility, is that people can get in there and really kind of like look at these different kind of plugins and be like well, wait, is this really how it’s supposed to work. Like is this really good for people that need to use their keyboard whether they be sighted, low vision or no vision, you know. Does this even work with this screen reader? It’s not enough to go through and like mash the tab button and be like, oh, I can get through. That’s cool. Like that’s not how most screen readers actually use, you know, their … Navigate through interfaces. They don’t just willy-nilly use the tab button.

I mean, Marla you can speak a lot more to this but, you know, there is a whole set of keyboard controls for each screen reader out there. Whether it be JAWS, NBDA, Voiceover, Microsoft Narrator, what have you. And you need to kind of test your plugins and all those different screen readers to see how it actually functions because tab is not sufficient.

C Todd: Yeah. And, I think, to add onto that, I’d love to get from Marla, just a maybe a higher-level questions of, especially since you’re a Perkins School for the Blind, how do people with disabilities use, not only the web but also digital, you know, web applications, how do they go about that? So you started hinting on it by using maybe a screen reader, using some other things. How do they actually navigate and work through those kinds of things?

Marla: Well, I’ll just address what I’m most familiar with and what we address. And this does encompass a lot of accessibility issues to kind of connect to screen reader compatibility. So, the screen reader as Scott mentioned, there’s some out there. There’s some that are free. VoiceOver is part of Mac Operation System. So, if you want to play around with VoiceOver, you can turn on VoiceOver with Command F5 and then, and you can turn it off again Command F5. But if you want to just get a sense of what it can do, it does take quite a bit of practice to understand how a screen reader works. But, knowing this, in terms of, no matter what screen reader someone is using, the user is essentially using keyboard shortcuts to find and navigate your web page. Or, to find content and navigate your web page.

So for example, a sighted user looks at a web page, they see the whole thing. They see the entire layout and they can skim content. They can look at the large headings, whatever, find, okay main content in the middle. There’s a left sidebar, main nav across the top. The header, footer. They see the whole thing in about three seconds. So, a screen reader user who is blind comes to a website, obviously, not getting the whole picture at all. They’re come in and they’re going to land on element, by element, by element, like a puzzle. And have to, and if you don’t have, again, you don’t have headings, if you don’t have things that are meaningful. If you don’t use, Landmarks are another amazing accessibility technique to implement is to be able to use Landmarks. To use HTML structure elements, like Nav and Main and Floater and Header. If you do that then a screen reader can actually jump right to those regions and know where they are.

So, you think about how someone who is blind, I always think that someone who is sighted has sort of a whole-to-part processing. They come in and see the whole thing and then they focus in on the details. So they go from a whole to a part. And, someone who is, whether using a screen magnification software so I’m only seeing a small part of the screen or I’m using a screen reader, it’s the complete opposite, it’s a part-to-whole. I’ve got to actually navigate the parts and create a whole because I can’t see the whole thing at once. And so, knowing that I have to essentially put your site together like a puzzle. I have to navigate in different ways so I can navigate by link, I can navigate by button, I can navigate by heading, I can navigate by landmark. Right? I can do a find command and just search for something. So, I have to kind of use all those ways of moving to figure out what’s on your website and find things and find stuff.

C Todd: Yeah.

Marla: Right. And that’s why I’m so dependent on your markup, right? I can’t tell you how many retail sites I’ve been to where, if I can display a list of all the headings on page inside my screen reader. I can just do a list and say, display all my headings and then I can get a list of all your headings. And, you know, this, it will say all the like, all the large text. Like 15 % off is now a heading. I did not know 15% off is a heading.

C Todd: 15% of what?

Marla: Yeah. Exactly. That’s not a heading. You just wanted to make your font bigger. So you put heading markup on that. That’s not a heading. So, and not only that, I end up with, you know, 45 headings. And, it really shouldn’t, the markup shouldn’t have been used. So, knowing that. Just knowing that that someone with screen reader is going to come in and number one, they’re going to, I don’t know a screen reader user who doesn’t move by heading. It’s like so critical to accessibility and just being able to move through your site. The other way people move is using, you’ll hear using the tab key, which means I’m going to move to every links and form control so anything that could normally receive focus that I could interact with, I should be able to land on it by hitting the tab key.

And that’s when you get into issues of like, oh somebody made a div and then they used JavaScript to make it function. Like a form control. I’m going to navigate my tab key, I’m never going to find that element. I’ll never land on it. I won’t even know it’s there. So, understanding that in itself, just headings and links and elements that receive focus and understanding why that, how that works.

C Todd: And you mentioned that this happens a lot.

Marla: Yes.

C Todd: How frequently, you know, how prevalent is this violation of this accessibility?

Marla: Gosh. How prevalent? I don’t even know, I think I’ve tried to find for demonstrations, you know, accessible versus inaccessible site. You know, W3C has like a demo site that I’ve use where they’ve created a mirrored image of a site so it visually looks identical but one is completely inaccessible and one is not. You know, so, I’ve tried to find like real living sites that are accessible. Unfortunately, there are very few out there. There’s always something. I always, I always think it’s a continuum. Accessibility is not just black or white like it is or it isn’t. It’s really a continuum. So where does your site fall on the accessibility continuum because chances are I’ll be able to find something on your website.

C Todd: 15% off.

Marla: Exactly. But I may not be able to buy your product. Or, I may not know what color your product is or I may not be able to pick a size. I mean, I’ve been through so many e-commerce sites where even if you’ve been lucky enough to find the products. Like okay that’s what I want and then you get to the place where you’re supposed to pick color and size and those are all custom form controls that don’t work, with the screen reader, I’m stuck. I can’t. Or, I’ve had a website, another retail site where I got past that step, clicked add to cart and I’m sitting there and I don’t know what, nothing’s happened. I have no cart link on the page. I can’t get to the cart, I don’t know where the cart is.

Find out that in actuality, once I clicked, add to cart, there was a temporary module that opened, that timed out, that I was supposed to get into to go to my cart and I never knew it was there. So, again, I can’t buy your product, right? So, it’s not that difficult to make it work. That’s the thing that’s so ironic, that it’s really not that difficult to do it right.

C Todd: Yeah. And, so, one of the things I’d love to get back, a little more detail on is just your work at Perkins. So, Perkins mission is to, I’ll read from your website: Prepare children and young adults who are blind with the education, confidence and skills they need to realize their potential. Can you talk a little bit about your division is Perkins Access? Is that correct?

Marla: Mm-hmm. Right.

C Todd: Talk a little bit about what it is that you’re trying to do there, specifically.

Marla: Yeah. So Perkins Access, we’re a consulting firm within Perkins School for the Blind. And we’re 100% primarily focused on digital accessibility. So, we offer our services that include assessment, remediation guidance, and sustainability support to help people build accessible websites. We work with web developers. We work with actual clients who have their own web developers. We also help with content providers in learning how to create accessible electronic documents. So, didn’t even talk about PDFs yet. So, Microsoft application, you know, Microsoft Word, Excel, PowerPoint. We do workshops, we’re going to be launching online courses this fall for many, some of our trainings as well.

We’re actually going to be putting on one of our first web accessibility workshops on June 14th at Perkins School for the Blind in Watertown. And, we’re really going to tap into everything we’ve talked about today. We’re going to touch upon the user experience. So, if you’ve never, don’t know how someone who is blind uses the internet, you can come to our workshop and we’re going to do lots of demonstrations, which shows you this is how it should work and this is what happens when it doesn’t. So we’re going to do a lot of that. Myself, I’m going to be leading the workshop with my colleagues and we’re going to be taking you through that experience because, I think, no matter if you’re a web developer or a designer or,  you know, you work in marketing or you just want to know more about what this is about, you’re going to come away with a much better understanding of what we’re talking about when we talk about web accessibility.

We’re also going to talk about the legal side of things. So, we’re going to cover ADA and Section 508 and then in the afternoon, we’re going to talk about WCAG. So, we’re actually going to go through some of the more prevalent issues such as talking about tables and headings and links and forms and were going to give you some code. If you’re a developer and you want to come, you’re going to get some code and see, you know, how should I be labeling my form controls and why? What’s the impact of doing it one way versus another? So, that’s what we want to do, is we want to not just give you that code but we want to teach you what the impact of it is. And so, we’re going to show you, okay, you didn’t use a label element to label that text field and this is what that experience is like to a user.

And now, okay, we’re going to use the label on it and we’re going to associate it with our text field and now you’re actually going to have that experience because we’re going to take you through that experience. And I really think that that’s how we’re going to get this, the only way I know to get this across, is to give people that experience from a user perspective. And hopefully, you know, you come away from our training on June 14th and you’re going to have not only a ton of great information but you’re going to have like, okay, “now I know what I need to do next” kind of thinking. And, we want people to come because we want to, you know, be able to take back and sort of champion the effort of it, champion accessibility back in their workplace and say, you know what? We need to do things differently now, we need to think differently in our, in how we’re building or what we’re creating and this is why. And, so if you come on June 14th, you’ll come away with all that great information.

C Todd: And so, on the theme of access if somebody can’t access your Watertown workshop because they are not here, how else could someone get that information?

Marla: That’s a good question. We’re going to be putting on series, this is like the first of a series of workshops. So, my advice is to constantly check back and if you just Google Perkins Access or Perkins School for the Blind you’ll and then search for Perkins Access, you’ll come into our kind of sub-domain. And we’ll be periodically updating what workshops we have. We’re going to be doing remote webinars as well. So, this particular workshop on June 14th is just covering a lot of content, we just didn’t feel like it really belonged online. But we’re going to have more concise versions in the future. So, you know, just check back in with us because we’ll be putting on more down the road.

C Todd: Cool. So, there’s a lot of information to unpack here. I think it seems like there’s, you know, if I could ask each of you and go around. Like what are the three things that somebody should take away from this conversation around accessibility. One is, the biggest one for me is well, I just read on your website, there’s 55 million Americans with disabilities. So, obviously, good accessibility is good business. If good design is good business, so is good accessibility. What would you want people to walk away with?

Marla: I know that there’s a lot of folks in user experience and I know that it’s kind of its own thing, and, you know, in the web developer world is user experience. But, accessibility has got to be included in that because if you’re thinking about that user experience well what kind of, who are your users? Your users are everyone. And, I’m probably on June 14th, I’m going to be one of the lead presenters of the accessibility workshop and I will probably, if ever use the word disability in our workshop because I don’t think this is about creating something for one population of users. This is about creating something for everyone. For everyone to use. Why don’t have something everyone can use? And that is really what I think the internet was designed for, was for everyone. Right?

C Todd: Right

Marla: And to some degrees, the internet is synonymous with access. So, it just doesn’t make sense to have an internet that only some people can use. It doesn’t align with what its intent is.

C Todd: Mm-hmm

Marla: So, from a bigger picture and opening our thinking a little bit more, you know. Come on June 14th, to our workshop, but I would like people to maybe who’ve listened to this podcast today, to come away with a completely different perspective about accessibility and not think to yourself, well, I have to build a website so people with disabilities can use my site.

C Todd: It’s not just …

Marla: It’s not that.

C Todd: It’s not just one more. It’s not a chore. It’s not a check boxed.

Marla: No, it’s not a checkbox and it isn’t that way, it’s about building a really good product. That’s what it’s about.

C Todd: Cool. Alex?

Alex Holachek: So, from a front end development perspective, I think the thing that made the big difference in the accessibility of my code recently was using how to use VoiceOver and really kind of, not only testing my code in terms of whether my code works but whether I can navigate through it using VoiceOver. And I know I’m probably not using it like a blind person would use it but just getting that sort of, it becomes much less theoretical if you’re actively trying to navigate the site. And you can catch things a lot faster than maybe some other auditing tools, which are also helpful.

And the other thing is, I definitely back up the idea that making a site more accessible helps everyone. An easy example for that is like sometimes designers will hand off designs that have like very tiny text or, like, very light font weight text or light gray text and then when you make it larger and, you know, you bump the font weight and the size and make sure it passes color contrast, you’re really helping everyone with bad screens and everyone who is holding the thing away from their face a little bit. Basically, everyone gets a better experience out of the deal. So, it’s a good thing to keep in mind.

C Todd: Cool.

Scott: Yeah. I would piggy back on what Alex and Marla were saying in basically don’t think about accessibility as something that needs to be tacked on or something extra. Like HTML in and of itself is accessible. You start from an accessible place. If you’re just building a web document, if you’re using the appropriate elements, it is accessible by default. It is only by adding in styling that maybe bad for color contrast, for example, or you know using JavaScript to make elements that aren’t suppose to behave one way, behave another way. Those are the ways we make our websites, our web applications inaccessible. So, I would hope that we would come away today like realizing, we start off good. And it’s only because we-

C Todd: We just mess it up.

Scott: That really is kind of it. If we just like really think about what it is we’re building, what it is we’re trying to do and understand what that is in context. You know, make the appropriate decisions, use the correct elements. Make sure that if you have to build something that isn’t native to HTML, that you are taking into account all the functionality that needs to exist there. Everyone is going to be at least temporarily disabled in their lifetime. By building our products, by building our websites to be accessible, we’re in a way making sure that future us’s don’t get mad at the crap that we’ve put out into the world.

C Todd: Sounds like the general adage of, you know, don’t take too many shortcuts because you may speed certain aspects of development like the open sources that you gave earlier but you may not actually have a product that your end users can actually use or actually buy. You may be turning away users, which is unfortunate. Well, thank you all for joining us today. This is a really enlightening conversation for me as someone who is more on the design side. You can learn more about Perkins School for the Blind at perkins.org. Marla, thank you so much for joining us. Alex and Scott. Thank you for being here as well. We’ll see you next time.

Author C. Todd Lombardo

C. Todd brings his vast experience in design, innovation, and strategic thinking to craft smart, impactful solutions that radically transform our clients’ business strategies.

More posts from this author

How we work Process

Product Hero Talin Wadsworth