NOEL: Hello and welcome to Episode 49 of the Tech Done Right Podcast, Table XI's podcast about building better software, careers, companies and communities. I'm Noel Rappin. Our topic this week is accessibility. As many as 15 to 25 percent of your site's potential users may have trouble accessing it due to some kind of disability. How can you design your site to allow that content to be usable by the widest variety of users? My guest today is Luisa Morales. Luisa is an engineering fellow at the New York City Mayor's office for Economic Opportunity. We'll talk about what accessibility means, how to design your site to be accessible, and what guidelines you can use to help ensure success. We'll also talk about a very literal form of accessibility: making your site behave in a way that it is accessible to users with limited bandwidth or older devices. We'd also like to hear from you. What issues or successes have you had with accessibility? Let us know at techdoneright.io or on Twitter at `@tech_done_right`. Before we start the show, a couple of quick messages. Table XI offers training for developer and product teams. If you want me or somebody like me, or m me, to come to your place of business and run a workshop on Topics include testing, JavaScript, or working with legacy code, that is a thing that can happen. If you would like it to happen, and you probably should, email us at workshops@tablexi.com or see a list of our course content tablexi.com/workshops. And of course if you like the show, tell a friend, tell a colleague, tell your social media network, I appreciate it when people tell me they like the show. Also, you can leave a review on Apple Podcasts which helps people find the show. And now, here’s my conversation with Louisa. Luisa, would you like to introduce yourself to everybody? LUISA: Yeah, gladly. Hi everyone, I'm Luisa Morales. I am currently a master's student at Pace University in New York City. I'm doing a master's in computer science and I am also doing a fellowship with the New York City Mayor's Office for Economic Opportunity in New York as well. NOEL: That's great and you have come here to talk to us about accessibility. Let's start by defining the subject a little bit. What most people think of as accessibility? How would you define accessibility? LUISA: What people usually think about as being web accessibility is making the web equally accessible for people with disabilities. For instance, the idea is that whether you have a vision impairment, a hearing impairment or a dexterity issue, you can access the web as well as someone who doesn't have those impairments or disabilities. NOEL: I feel like I hear about this most often in terms of people who have visual difficulties but the other ones are also quite important. How large of population are we normally dealing with the people who you may be turning away from your website because it's not accessible? LUISA: Roughly, 15% to 25% of the population on a global level has some form of disability. In the US, the Census Bureau from 2012 gathered information and in 2010, there were 56.7 million people in the US alone that had a disability as such vision loss, hearing loss or mobility impairment. That actually averages out to one in five Americans. NOEL: That including like red and green color blindness as a disability? LUISA: Yes. It's any type of vision loss, ranging from... Or like, I guess vision impairment which could be color blindness all the way up to being legally blind. NOEL: Of course in many cases, you're legally required to provide a site that is accessible, at least in the United States. LUISA: Yes. There is regulation around this. Government websites, educational websites, I guess are looked at more closely but still, there was a report that was some organization went around and took, I believe it was roughly like eight sites from every state to gather how many of them were accessible by the terms of the WCAG, which is the Web Content Accessibility Guidelines, which were released in 2008 by W3C. That's the worldwide web consortium. Maybe like 43% of websites weren't actually accessible and these were all government websites. The study was done recently and it's 10 years since W3C came out with these guidelines and the web doesn't really seem to be more accessible to people in the way that it should be. It's just really a shame because I feel like the web is this thing that is magical and open to everyone and accessible and kind of tries to even the playing field, regardless of your background. And the fact that it's inaccessible to so many people is very shocking. NOEL: Yeah. I feel like I have always, for my entire career as a web developer, heard that accessibility is a huge issue and that most web developers don't pay any attention to it and that even knowing that, most web developers don't pay any attention to it and I think I'm as guilty of it as anybody. It's not something that I think about on a day-to-day basis. What's the most important thing that a web developer can do tomorrow to start making their sites more accessible? LUISA: A great question and it's almost a difficult one to answer because if you're going to make your projects more accessible, you need to be aware of what that means. I think the first thing to do would probably just to be aware of what web accessibility means and to be aware of whether or not a company that you work with or the companies that you work with are taking it into consideration. The thing being that, it involves different stakeholders. For visual impairments, there are things around like color contrasting, so the best kind of contrast is a white background with black text or black background with white text on it because it's the easiest for everyone to see what's happening on the page. Other things are using image elements but including the alt attributes into them. A lot of people will and I have seen this done on products that I've worked on, where the alt attributes will be left empty. Sometimes that's done because the image is purely for presentation purposes but if you're someone with a visual impairment who is using a screen reader, that image is going to still come up and be read by the screen reader but you're not going to have any context for it. It's essentially just having like empty box on a website that has nothing for you and provides no value. Alt attributes are really important because it can add context around what is being displayed in the image. Also, if it is for presentation purposes, there is an ARIA label that you can use and it's the role attribute and so you can set it to presentation and then you can also set ARIA-hidden to true, which will have that image not be picked up by a screen reader. NOEL: You mentioned ARIA but tell me a little bit about what ARIA is and how I should be using it in my websites? LUISA: ARIA labels are, I guess HTML... I'm not really sure how to phrase it but it could be like syntactic sugar or attributes that you can add on top of your elements to provide extra context for screen readers. They're really great but they are dangerous if you don't know what you're doing when you're using them. NOEL: Okay, help me know what I'm doing when I'm using them, so there's data attributes. They'll start like 'ARIA-something,' right? LUISA: Yes. NOEL: What kinds of things do ARIA tags help screen readers do? LUISA: They help add context to what is happening on the page. I have some examples that I wanted to share. The one that I was talking about earlier is when you add aria-hidden="true" and role="presentation", you can add these onto an image element and essentially what it does is it makes it so that a screen reader doesn't pick it up and you can also use the alt attribute and set it to empty. Just because it's purely a presentation image, it doesn't add additional value to the website or any additional context, so it doesn't need to be picked up by a screen reader. Ideally, if you are using images, you want them to provide some type of value but sometimes like with a large image on a blog post that doesn't really do anything for you other than kind of like being pretty. That is a good example of when you would use aria-hidden="true" and the role="presentation". Another thing that can be full in this case is ideally, you should be using the label element and that will allow you to get the native built-in functionality for that, in the ideal case, you want to have a custom control set up. You wanted to do, say radiogroup, then you would have div role="radiogroup" and then ARIA labeled-by equals for the purposes of this label, then you would have a span element with the ID label and then that would mimic the interaction or kind of like DOM set up that you would get from a label element to then have like its own placeholder and other contacts kind of added to that. NOEL: A lot of times, the code of the web page is more or less in the same order that a screen reader would deal with it but sometimes, it's not. You have elements that pop in a different places, CSS can have things move across the page. Is there a mechanism to make sure that the screen reader knows what order to deal with elements on the page or is it something something I just need to be really careful of when I design? LUISA: Yes. You just actually just hit a kind of a nail. Basically, the screen reader will read the website the way that the DOM was set up for it. The way that you have set up your HTML elements, all of that is what the screen reader is going to spit back out. There are ways to remove elements from the screen readers so that it doesn't register them but you do have to be careful. Something that is really tricky are the elements that are on the DOM but aren't visually there, I suppose. If you're a person navigating the website, you wouldn't see it automatically but if you are somebody navigating the website through a screen reader, it will show. The way that it's kind of described on W3C is it's considered off screen content. The way to draw attention to new contents, whether it's a blip or an error message or something like that, is to use ARIA live and that has two states that I'm aware of. It's polite and then urgent. Then, also the ARIA described-by attributes. It will make those states active for the screen reader to then alert the user about. Other ways to go about doing this is not-all-elements if you're using a keyboard. Keyboard accessibility and screen reader accessibility have commonality when you're using them and so, something to do with off-screen elements. If you want to hide content from the screen reader because they are off screen elements and you don't want to draw attention to them until they should be in focus on the screen, use ARIA-hidden="true" and then ARIA hidden doesn't actually prevent the keyboard from focusing on the element, so you would have to then also add a tabindex="-1" to make sure that it's actually removed from screen reader flow and from keyboard flow and then to add elements into the keyboard flow, do tabindex="0". The thing with tabindex="0" is that it'll bring elements into the page as soon as DOM is loaded. You want to be really careful about using that. There are things that aren't natively supported as having a tabindex. If you're clicking through a site on using your keyboard, divs and spans aren't registered through a tab. It's usually things like links that have a tabindex. When you tab through a website, those are the elements that would get registered and displayed for you. NOEL: This reminds me a little bit of internationalization in a couple of senses. One of which is that it's much easier to do if you bake it in at the beginning of a project than it is to try and add to a project that's in progress and secondly, I think because I suspect tooling to do it is not as good necessarily as we might all want it to be. Am I right about that? Is it a lot easier to build in accessibility at the beginning of a project? I guess nobody ever says, "Leave that important thing until the middle of a project." LUISA: The way that I kind of see it is that similar to this whole kind of mobile first mindset that has been going around, it should be mobile first and accessibility first. The great thing about building your projects with accessibility in mind is that I believe it makes you a better developer. Along the way, it you makes you more empathetic as well. It also makes it a better experience for all your users. Something else that is important in terms of like Semantic HTML is creating landmarks. There are elements like section and aside and main and nav and these, I think at least in my experience, haven't been used as much as I believe they should be. For a screen reader or when you are using your keyboard, these landmark elements are super important because they allow you to skip through and to get a really high level idea of what's on that page, so on your content-heavy website, these landmark elements allow you to navigate to where you want to go. I think that's really important because it just makes the experience a lot easier and then as a developer, the fact that you're thinking about like what should go into the main element, what content is the most important, what belongs in there and then, also what's on the side and things like this. It just makes you think more about how you're building the things that you're building. NOEL: There's kind of a curb cut effect here. Curb cuts were originally put in to help people in wheelchairs but once they put them in, they discovered those are useful for people in all kinds of circumstances: carrying heavy things, people with strollers and if you have good markup for the purpose of accessibility, that also helps other navigation tools. It helps readers and Instapapers and things of the world, determine what the content is and it just overall makes the site a pleasant experience for everybody, even though some of it is behind... LUISA: Yeah, definitely. Something else is H1 elements. I partially still consider myself a junior developer. I'm self-taught and I've been in programming for slightly over three years and I worked at a development agency and then, also I had a startup. I cannot tell you how many times I've seen multiple H1 elements on a page and not had anyone kind of register that as being an issue. Heading elements are important because they denote what to expect from the content that follows the heading element. H1 elements are really important because they are what tells a user -- any type of user -- what the page is about. It is also gets picked up by web crawlers and so, it's very, very important. You only have one H1 element on a website and then, you would use like H2, H3, all the way down to H6, depending on what the order of the DOM is and then, you would style on top of that. What I have seen in practice is that developers, I myself, have done this in the past because I wasn't aware of what was happening, will use say like an H2 element and then within that, have another H2 element but realistically, it should have been an H3 or have multiple H1 elements on a page. It's not a good practice. It's not great for someone using a screen reader and it's not great for SEO. NOEL: Right. You only have one title on a page. We are sort of all paying for like the not fully thought-out decision when HTML was created to have H1s and H2s like sort of be both typography and structure and ideally, you would treat them as structure and deal with the typography in CSS. LUISA: Yes, correct. In CSS, you would basically set whatever you want headings to be and then you would override them based on what design you have to implement but the H1 element, there should only ever be one of those on the page. Then there are other rules for using the remaining header elements but the key here is only one H1 element per page. NOEL: How would I approach this? If I'm going to approach the design of my page and I'm working with designers, the beginning of a project were setting up the layout, what are some things that I can do at the beginning to make sure that screen readers or using assisted navigation devices have their workflows taken into it. LUISA: I think as a bare minimum, just because this is quite a lot to kind of take in, when you're working with the designer and also with copy editors, it's really a team effort here. When you're working on a project, you're getting started... things to take into consideration that will have a big empower, I believe are things around color contrast, so making sure that the colors that are being used are different enough where they can be picked up by people with visual impairments. Honestly, a current pain point for myself is the new Chrome browser update that was just released. There's a lot of gray and so, it's actually difficult for me. I don't have any visual impairments, to see where things are when I'm using Chrome and it's been extremely, extremely frustrating for me. I think maybe picking colors that have good contrasts, being careful about placing text on top of images, they can be very distracting and it can also be very difficult to see the text on top of images. Be sure that you're using the alt attribute and if it's for purely decorative purposes using like role="presentation", taking into account the DOM structures. I know that it's really fun to design websites that are beautiful but if there are a lot of moving parts, they can be difficult for somebody say, with like an anxiety disorder or cognitive disability to take in. Along those lines, also having succinct copy is really important. Basically, make your copy readable on the fifth grade level and you will have greater success with getting people to kind of convert and understand what your product or project is about. Then I think those are kind of a good start. From there, you can move into the ARIA labels and bringing elements into the keyboard flow. Something else to consider here is to make sure that if you are using say, a div and styling it as a button, you enable that button for a screen reader. There's a way to do it. I can't remember it right now but there is enough documentation online for it to be easily accessible. If you are not using buttons for your buttons, those buttons will not be accessible by someone, so you could have a checkout button but it's actually a div with the class "button". You have some JavaScript there and when a person clicks on it, it takes them to the checkout screen. That will not be picked up by a screen reader, unless it is specified to be something that you want the screen reader to pick up. I think the lesson there is to use the elements that are provided to you by default because they have a lot of functionality that you would otherwise have to implement yourself, if you don't use them. NOEL: I know that there are tools for color contrast and some of like the color blindness issues. Are there tools to help you audit your other accessibility issues? What's the easiest way for me to tell what my website sounds like on a screen reader, for example? LUISA: So great question. For a screen readers, there's JAWS and NVDA for Windows. They are screen readers that you can use and access your website and kind of see what it sounds like to a person who'd be using the screen reader. On Mac, there's VoiceOver, which is built in. For Android, there's TalkBack and then for the Chrome browser and the OS, there's ChromeVox. Most of these are open source or offer a free version, free trial, free to test out. For Windows, there's also something called High Contrast, which will show you what the website looks like and whether, it would be visually acceptable for someone to use who has a visual impairment. Then there are other tools in terms of just kind of testing what the website looks like on different browsers and how fast it is. These include like BrowserStack and I think, BPage Test, I think it's called. These are things that you would have to do in terms of manual testing. For automated testing, there's Pa11y CI, which is a continuous integration centric accessibility testing tool. It'll allow you to specify your roles that you want to have tested and it'll spit back things that are broken with it. One of those would be having an image element without the alt attribute. NOEL: You talked about speed there for a second and I think that's a good way to transition into another way of thinking about accessibility, which is accessibility, not necessarily based on disability but sort of based on access. What are some of the important things that you need to keep in mind when you're talking about accessibility, literally in terms of access? LUISA: Great question. Things to consider are that we, definitely myself thank you as well. Most people who are listening to this podcast are very fortunate in terms of our access to the web. Not everybody has that same access. You know, I can access the web on my laptop, my phone, at home at school, even on the street and I don't have to pay for all of it and that is not the case for a lot of people around the world. There are people who will pay the equivalent of their daily income on just loading up one page, so for them, it is essential that websites load quickly and they are small. They there just making your projects and products acceptable regardless of your internet connection or your financial status. NOEL: What are some of the specific things that you needed to think about there? Is it just a question of like taking all the fancy stuff out of your website or is there a better way to handle it? LUISA: There are a few ways. One of them is considering load times. A quick win there would be to place your scripts at the bottom of your body element, so that way you won't block the page from loading while it's gathering JavaScript located in files or potentially through a CDN or something like that. On that note, if you can use a CDN to load some of your, say a stylesheet or something like that, it can also be helpful because it will make it faster for the user to be able to get that content onto their device. For anyone who's unaware of CDN, it's content delivery network and then, also images are a huge thing here. If you can provide an image that has a smaller file size like on mobile versus desktop, that makes a huge difference. It also makes the site just load faster and then other things to consider around that is how ads are managed. Ads can be a huge headache. Unfortunately, there isn't much that can be done to circumvent them because they do tend to be third parties, so thinking about your users, you could check geographically where they are based on the IP address or check what type of network connection they're on. Say, there are on a 2G or a 3G network, you could disable ads for them. Something else to consider is offline capability. The idea here being that not everyone has access to a stable internet connection. I think this also comes down to kind of how browsers work on mobile but sometimes, it will automatically refresh which means that basically, just downloading everything if it hasn't cache it and that can be very costly for someone, maybe if it's like a new source and they're to access this information for like a school project. It can be very costly for them if that auto reload happens. Being able to make your site not do that would be really helpful and it can actually make the difference in someone's life on a monetary level. Progressive Web App is a project of Google and it basically allows you to add some of the bonuses that you get from having a need of application but apply that to your web app or your website. Part of that includes the capability for offline push notifications and then some like hardware access as well. Then there's also AMP which is Accelerated Mobile Pages. It's also a project out of Google. It's open source and AMP pages just load very quickly, partly because they don't support JavaScript. They do but they support asynchronous JavaScript but it's also custom AMP elements, so you are limited in the JavaScript that you can use on the sites. NOEL: I think CNN, either always or in times of heavy load has a separate URL that's like '/fast' or something like that that is the stripped down version of the site, that is mostly text and gives people like me warm feelings of nostalgia from the late 90s. You mentioned JavaScript. Does this kind of accessibility kind of preclude using single page apps or big JavaScript frameworks or is it just something that you need to be very careful about, if you're going to try and do that? LUISA: It's not one or the other. There are people who have... I forget what the name of the application is but kind of like Kayak but basically what they did is that they built certain landing pages using AMP and then from AMP, they take the user over to their Progressive Web App and there's a lot of data flowing through there but they managed to do it in a way how much memory the whole web application takes is very low and it's a very fast experience. You can do those. I think that it is harder to do it retrospectively. If you're already have an application and you want to convert it into a Progressive Web App, that is a harder thing to do because it'll probably take some reworking but if you start off with accessibility in mind as you've mentioned before, you're going to be in a better place to implement these new technologies and just to make your project more accessible overall. You don't have to stop using JavaScript or anything like that. You just have to be aware of what's going on. Something that I feel like kind of slips through the cracks is like memory leaks, which can be extremely costly. Even just having a script or something that texts, what's going on like in the background or something like that would be helpful. You don't want to force people to download more stuff because they're just using your site. I think that was horrible. That's pretty much it. You can have both, you can have a heavily-used application and have it be accessible. NOEL: I know that there's a tool here because I know that the Google Chrome developer tools, there's a setting to like throttle your bandwidth to simulate. Is there anything else like that or do the browsers have some more tools to have you simulate what the site looks like under conditions of not a lot of bandwidth? LUISA: I am not sure. I've actually only ever used the one offered by Chrome. I would assume Firefox does and on that note, probably Edge but I'm not sure about that. Another fun thing to do is to disable JavaScript and load your site and see if it even loads. I've heard people do this and they literally just get a blank screen. NOEL: Yeah or if you're doing like a single page app or something that's very heavily in a framework, then you're making the bold claim that JavaScript's required for this. LUISA: Yeah, but you can easily create a page or something that says like, "If JavaScript is disabled, show this message." It's really in text saying, "Please enable the JavaScript," so that you can see your site. NOEL: I feel like there was a period of time where it was kind of a point of pride for a certain personality type to claim that they turned JavaScript off sort of publicly and that sites were somewhat more solicitous about saying, "You need JavaScript to get the full experience here," and then once single page apps became a big thing and we just decided to assume that everybody was going have JavaScript on all the time, that sites stopped -- more or less -- sort of being solicitous of the non-JavaScript experience. LUISA: Oh, wow. I had not heard about this. Very interesting. With single page apps, you run into this moment where you have a link but you're not actually taking a user to a new page you're just like re-rendering whatever component you want to have displayed. There is a way to do this and to actually kind of like generate a URL, then for the user to then be able to kind of like click back if they want to. A way to do this is that you could use a 'history.pushState' and then set the path for, say like 'bar.html'. You would then have it displayed this in the URL bar but it won't actually cause the browser to load that HTML document and it won't even check if it exists. It'll just display in the URL bar. It's a great way to kind of show people that there has been a state change but not actually changing the way the structure of your application. Then to go back, you would do 'location.pathname' if the user selected to go back. You could just take them back to the state that they were previously in. But at least in this way, if someone wants to go back to the page that they were on, you can set it in your route so that the user is taken back to that state, which is huge if you are some kind of navigating the website, when you click out and you want to go back and you don't really know what's going on. Just kind of makes it feel more like a typical site would do and not in a single page app. NOEL: Is there anything else that people should know about accessibility before we end the show? LUISA: Yeah. Accessibility is for everyone and some of the reason that you should care is that if you build with accessibility in mind, you're going to capture most likely the 15% to 25% of the population that has a disability on a global scale. If you don't think about accessibility, you could get sued. If you work at an agency or own an agency, your clients may ask for it, especially if they're organizations thatneed to build sites that are accessible. I believe that companies will start looking for developers who have accessibility in mind in the future. The Financial Times did, I believe it was about two years ago, that they underwent this but they did a huge overhaul to make their site more accessible. If you look at some of their job listings now, they mention, I quote, "A love of the web, an interest in performance and dedication to accessibility," and they're nice to have so it can make the difference between getting a job or not. Just build with accessibility in mind. Even if it isn't something that is currently happening at your organization, talk to a few people and see if you can get buy in and if that doesn't work, which unfortunately is a thing that could happen, read up on it, make yourself aware of what's going on and if you become passionate about it, share it with other people and enable the screen reader on your computer and see what it's like to navigate a site that you love through it. NOEL: Great. Thank you for being on the show, Luisa. Where can people reach you if they want to know more about accessibility and continue this conversation? LUISA: Probably Twitter which would be @LuisaMariethM. I used my middle name in everything because there's a pretty well-known pianist named Luisa Morales, so I did that for SEO purposes. NOEL: Great. Well, thank you so much for being on the show and giving some great accessibility tips. I really appreciate it. LUISA: Thank you so much. I hope people will find it helpful. NOEL: Tech Done Right is a production of Table XI and is hosted by me, Noel Rappin. I'm at @NoelRap on Twitter and Table XI is at @TableXI. The podcast is edited by Mandy Moore. You can reach her on Twitter at @TheRubyRep. Tech Done Right can be found at TechDoneRight.io or downloaded wherever you get your podcasts. You can send us feedback or ideas on Twitter at @Tech_Done_Right. Table XI is a UX design and software development company in Chicago, with a 15-year history of building websites, mobile applications and custom digital experiences for everyone from startups to story brands. Find us at TableXI.com where you can learn more about working with us or working for us. We'll be back in a couple of weeks with the next episode of Tech Done Right.