 So as he said, I am Stephanie Slattery, and this talk is, why won't you take my money? It's about the intersection of payments engineering and accessibility. This is my Twitter handle. I love live tweeting. Please live tweet me. I'll give you a high five afterwards if I see you've done that. My Twitter handle is also on the bottom of all these slides in case you forget. I am a front end engineer and accessibility specialist at Click Studios in Chicago. I'm also the co-organizer for Chicago's digital, sorry, digital accessibility and inclusive design meetup. It's a really long title. I can't remember it half the time and it's my own darn meetup. I've also led accessibility audits and fixes for a wide variety of clients and I give talks and workshops to lovely people like yourselves all across the US. And just so I have a better understanding of who's all here, can you raise your hand for me if you know anything about accessibility? Okay, okay, like half ish of the room. Go, go, go, we got a mix. And can you raise your hand for me if you've built some technology thing before specifically with accessibility in mind? Okay, maybe like a quarter. That's cool. People, if you raise your hand, you are my people. Thank you, congrats. If you didn't raise your hand, you're about to become one of my people, so stick around. All right, let's all get on the same page first of all, what is accessibility? It's the design of products, devices, services and environments for people who experience disabilities and it's the practice of removing barriers that might prevent people with disabilities from accessing something. But more than anything, accessibility is about inclusion. It's about making sure that people with different limitations, different backgrounds and needs and disabilities are all able to use and be included in what we make. Every time I give a talk like this or a workshop, people are always surprised to learn that people with disabilities are using the technology you create, right? A lot of folks will be surprised that somebody who is completely blind from birth is using your website or somebody who's paralyzed from the neck down can still use your app. People have a wide variety of different disabilities both visual and hearing, cognitive and motor function related ones and they use a lot of different assistive technologies that we're gonna talk about a little bit both including tactile keyboards, speech recognition systems, eye gaze systems and screen readers to use the web. It's really cool. Beyond that though, it's important to remember that this is not a small group of people. This isn't some small portion of your users that you can just conveniently ignore. One in five Americans have some kind of disability as of the 2010 census and that's about a similar statistic worldwide. One in 10 Americans have a disability that directly impacts their use of the web. 10% of people. That's not something we can neglect. On top of that though, you should know that accessible design helps everybody. Folks with disabilities have different needs and different requirements. Accessible design helps them. But also everybody else tends to benefit from accessible design. A good example in the physical space is curb cuts. These will be the little dip you'll see on a sidewalk that leads down into the road over a curb. This is something required by the Americans with Disabilities Act for folks with different mobility needs or folks who are blind who need to be able to feel where that curb is but they're also useful for everybody else. You're pushing a stroller, a cart of groceries. If you're looking at your phone and not paying attention and you trip over a curb, I've definitely never done that. They help everybody. That's called the curb cut effect in the accessible design sphere and that also applies to a lot of digital things. So really following these practices we're going to go over help everybody. Okay, so why do we make things accessible to begin with? There are a few different reasons and they're all valid. It's just some of them might be more or less altruistic than one another, let's say. So the first and my favorite is to improve the lives of people with disabilities. I believe that we have an ethical duty to help people who use what we make, right? Because we're responsible for what we create. I don't think there are many of us here who go to work and say, I'm going to make somebody's life awful today and I'm going to build something that's going to be so hard to use and everybody's going to hate it. And if you're one of those people, don't tell me, I don't want to know. But we build things to make things easier for people and we're responsible for making sure they're easy to use for that reason. Another good reason to build things excessively is it's the law. Hey, doing things because we have to, woo. There are a lot of laws that have been created in the United States and across the world as a result of the disability rights movement. In the United States, we have two big laws, the Rehabilitation Act that was passed in the 70s. This is generally a labor law that governs companies and the government and companies that receive money from the government, I should say. You also likely heard of the Americans with Disabilities Act, also called the ADA. This was passed in 1990. And generally governs accessible things that are within the public space or that are public accommodations. You heard me, though, say that this is from 1990, the World Wide Web, and a lot of tech wasn't exactly large then. So a lot of our modern day technology isn't explicitly included under that law. However, a lot of cases, especially in the last decade, have made it very, very clear that we all have to worry about ADA compliance. I'm gonna give you a few examples of some lawsuits. These are all from the last decade, generally in the United States in order for accessibility law to be enforced, you have to sue a business. And I know we tend to think, oh, people are so lawsuit happy, maybe. But the only way to get a company in our country to build something excessively is to sue them. And this will either be done as part of a settlement or the final terms of a lawsuit if it goes through. So every single one of these companies, I'll read the slide to you, we have Scribd, Dick Blake, that's an art supply store. Each in our block, they do tax prep. Hilton, Ace Hardware, Five Guys, it's a burger and sandwich shop. Peapod, they do grocery delivery. eBay, Carnival Cruise Lines, Grubhub. This is just a small sampling of lawsuits. Specifically, these 10 are all lawsuits that specifically mentioned, not being able to make a purchase on a website as part of the lawsuit. Some of these went a little better for the companies. They settled them out of court, made things accessible, it went away. Others, they lost a lot of money because someone who was blind or had another disability couldn't purchase things on their website. I wanna give you an example of that. This is a quote from a lawsuit against Hobby Lobby. The plaintiff found the gift card page confusing and was unable to purchase products from the website because the checkout feature didn't work properly. Specifically, this plaintiff is blind and uses a screen reader to navigate websites and they wanted to be able to give Hobby Lobby their money but couldn't because it wasn't accessible. Also from that same case, the judge remarked, for over 20 years, the Department of Justice has consistently maintained that the ADA applies to private websites that meet the definition of public accommodation. Hobby Lobby had a more than sufficient notice to determine that its website must comply with the ADA. A little scary, right? If you're like me and you're a dev and you're hearing this, you might be thinking, help, I don't wanna get sued, right? The third reason I wanna tell you about as to why we would build something accessible beyond taking care of the people who use our tech and because we don't wanna lose a lot of money is to capitalize on a wider audience or a consumer base. So as I've said, 10% of Americans have some kind of disability that directly impacts our ability to use the web. I can't honestly think of any ethical or economic argument you could make for discluding 10% of your user base for your technology, right? You wouldn't design a website that doesn't work on 10% of browsers. So why would you build a site that 10% of your users can't even use, right? And that statistic can even be larger depending on what your user base is, right? For example, I've had a client before that was a performing arts group. Most of their clients, how we're seniors and they have a much higher rate of disability. So it might be even larger than 10% depending on who your clients are. The other good thing to know is that people with disabilities in the United States alone control $175 billion in discretionary income and they would like to give it to you. They would like to spend it. So why don't you take my money, right? Why do we build things in such a way that people cannot spend that money that they have? So we've talked about why you might build things excessively, but how do we do that? This tends to be people's biggest fear when I'm talking about this, right? It's like, ugh, I really wanna do it. I really care, but I have no idea where to start. So how do we build things excessively and inclusively? My next slide, if you listen to a single thing I say during this entire half hour, make it be this one. You should listen to people with disabilities. If you want something to be usable by people with disabilities, listen to us, right? Both in your discovery phase, when you're first creating a product, as you're building it, you should have developers and all sorts of other folks with disabilities on your team and in final user testing, people with disabilities should be involved. In addition to that, you should be following best practices. Those of us who work in the accessibility space have created some excellent guidelines for you to follow and so many blog posts and talks, and you name it. There's a lot of information there to be had. Specifically, the largest one in the web space that we refer to is called the Web Content Accessibility Guidelines, or the WCAG, or WUCAG. It's kind of a hard acronym to pronounce, I don't know, but that's one of the main resources we refer to for guidelines about how to build things excessively. We're gonna drill into that a bit more for the purposes of this relatively short talk. We're gonna answer the question, how can we make sure that payment forms, specifically on the web or on a mobile device, are accessible? So during this talk, I'm gonna be focusing mainly on what makes forms accessible for people who use keyboards to navigate through a site and people who use screen readers to understand the content of a site, as well as people with cognitive disabilities that make it difficult to understand things, how other people might, or have difficulty doing things quickly. People with other kinds of disabilities generally are less affected by problematic forms. Before we do that, though, a quick side note on what the heck is a screen reader. So a screen reader, you might first think that it just reads what's on a website to you, right? But they're a lot more powerful than that. For example, you're thinking of, I don't know, Facebook site, let's say, right? It's not just going to read to you bit by bit, each person's name and their status update, blah, blah, blah, as you go down the page. Screen readers parse HTML, similar to how a browser parses HTML, and gives it meaning, reading its semantics. If a browser reads HTML and presents it to you visually, a screen reader reads HTML and presents it to you in an auditory format. Screen readers allow you to skip through parts of the page, almost like you're reading an outline. So for example, if I had a big, long page, I could skip through it by reading just the header tags on the page, and then drill into the ones I wanted to know more about. And in the case of a form, I read through a form using its labels and can skip through and enter different parts. I'm not necessarily preceding the site in a linear way in the way a sighted user might. Also in this image here, you can kind of see in the background this kind of light white object that a person's hand is resting on. This is a refreshable Braille keyboard. They are so cool and commonly used in combination with screen reader tech. You can maybe see here there's these little bumps that look like Braille. These are little kind of pegs in the keyboard that can move up and down to represent Braille. So a person who doesn't have vision can read the website using Braille. These are also used by folks who are both deaf and blind as a way to go through your website. Really cool stuff. Okay, so how do we make a payment form accessible for folks who use technology like this? Beyond everything else, forms should be easy to use. And I don't mean easy for you or I to use, right? We're developers, we do things quickly and we're very technologically literate. Forms should be easy to use for people with low digital literacy and folks who use a wide variety of assistive tech. One of those being navigating with just a keyboard. So by default, HTML5 is totally keyboard accessible. If you're writing HTML by the book, following the rules, your form will be accessible. However, as engineers we like shiny new things like JavaScript and fun libraries that can change our page, right? Things like JavaScript especially tend to break accessibility of web pages. We also, those of us who are front engineers, we like to make things beautiful following design guidelines. And sometimes that can involve removing the focus state for a form using CSS, which isn't good. If you've ever navigated through a site just using your keyboard, like tabbing through the inputs on a form, using space and enter to select things, you usually wanna see what you've selected and where you're currently focused. This will frequently appear in a browser as a little border outline or as a shadow around the element. So forms need to be keyboard accessible. Also, clear instructions on the form are absolutely necessary. There's a few ways we achieve that. First of all, we associate labels with our form components, right? So if we have, for example, a name field, right? We both wanna have a visual label that describes it as a name, but we also wanna semantically associate it with the input field, and I'll talk about how to do that in a moment. And if we have a large group of form components, I don't know, let's say we have a bunch of radio buttons for shipping options, right? And they have listed each of the different ways somebody could have something shipped and the speed at which it ships. We wanna associate those radio buttons with each other and the overall form using something called a field set and a legend. So a field set goes around an entire grouping of items in a form and a legend describes what that group is. So in this case, a field set would go around those shipping options and the legend would describe, I don't know, something like shipping options or please select your shipping speed, something like that. Okay, let's talk about basic HTML inputs and what these should actually look like since we have a tendency to make them very weird. So this is a basic text input. If you're familiar with HTML, you'll have probably seen this a lot before. We have a label up at the top. In this case, it's a name field, so it says first name. And we have an input of the type text for a user to enter in their first name. The thing is though, we've associated these two parts of the site together using an ID and a four tag. We've labeled that text input with an ID and we gave it first name, whatever if that works. And we've said four first name on that label field. Because we've done this, a user will be able to click on or select the label on the page to put focus in that input state. This also allows a user with a screen reader to skip through your form just by reading the labels. If you don't associate a label and an input in this way, you just have words on a page and input boxes that mean nothing. And to those of us who are cited, it's visually obvious that they go together, but if you're using a screen reader, it doesn't make any sense. So we need to associate them. And I don't know about you, but that doesn't look that hard, right? Okay, so what if we don't wanna use a label? So visual labels are usually very important for sighted users. We wanna see what we're about to be typing into. However, sometimes visual text can be overkill, can be confusing, can really be unnecessary for a sighted user. A good example of this on a payment form is when you're selecting the expiration month and year for a credit card. We don't usually label expiration month, expiration year. Usually it's just expiration and then two selects, right? However, we want these inputs to still be labeled for folks who are using a screen reader. So the way we do that is with CSS. CSS isn't, for the most part, relevant to a screen reader at all. They're reading HTML. So we might hide a label that we don't wanna sighted user to see using something like this. Summarize this for you here for folks who aren't super familiar with CSS. We've essentially taken this label and moved it 10,000 pixels to the left of the screen. Way, way, way out of the way. You won't even see it. We've also made it a pixel in height and a pixel in width, and we've told it that if there's extra stuff that doesn't fit in that one pixel by one pixel square, hide it. Now, this looks like a lot just to make something disappear. If you're familiar with CSS, you might use something like display none or visibility hidden to just totally take something off the webpage. Thing is though, screen readers are smart. Screen reader devices know that if something is hidden or it shouldn't be visible, it shouldn't be presented to a screen reader user at all. So we don't wanna just completely hide it in that way. It removes it from the flow of a page. The same thing also happens if you were to set the width to zero pixels and the height to zero pixels. This does the same thing. It removes an item from the document flow entirely and a screen reader assumes you don't want people to know it's there. So it might look like a lot, but you need to be actually putting labels on the page and just hiding them totally out of sight for a sighted user. So a screen reader user still knows that they're there. Okay, what if we have help text that's not actually a label? So we might have some additional information in a payment form that's important for understanding the form, but it doesn't actually label a field. The best example I have of this for you is a CVV, right? So we have again just a simple label and input they're associated with that CVV ID. And you might have some text underneath this for folks who aren't familiar with CVVs, that says like for Visa, Mastercard and Discover, these are three digits on the back of your card, blah, blah, blah, right? All that additional text. However, right now, that's not associated with that label and input at all. For a sighted user, this will be obvious. That's underneath the form, it must describe it, cool. However, for somebody who's using a screen reader, this is just random text in the middle of a form. And if, like most screen reader users, you're just skipping through the form by reading the inputs, this will never show up. This will never be read to you, which isn't good, makes the form more confusing. So what do we do about that? We use something called ARIA. This stands for Accessible Rich Internet Applications, the W3C protocol for enhancing and supporting the accessibility of dynamic content on a site. It's also used to address content items that can't be made accessible with plain old HTML. Like I said before, for the most part, HTML out of the box in a modern browser is completely accessible. Sometimes we wanna do things though, like that label that don't have accessibility added in them right away. In this case, we'd use this property called ARIA described by. ARIA tags begin with ARIA, have a dash, and then their additional information. In this case, it's described by. So we're going to use this to semantically associate that span with that helper text in it with the input and the label. It has a new ID on it to describe it. In this case, I've just called it CVV help, and we've put an additional attribute on the input that's that ARIA described by equals CVV help. Now when we're using a screen reader, tabbing through this form, the label for that input will be read, CVV, then that described by text will be read, and then we'll be able to give input. Awesome, right? Pretty straightforward. There are a ton of other kinds of ARIA tags that are relevant to forms, and I encourage you, if you're a person who writes HTML at all to dive into them on your own, it's important to remember, however, though, again, HTML is accessible out of the box, and it's really, really easy to overuse things like this, these ARIA tags, to actually break the accessibility of the site. So be careful, and there is a ton more, I could go over with you, but again, this is only a half hour talk about how to make a payment form more accessible on the web. One example is understandable placeholder text. That's the text that appears in a form field when the user hasn't entered any input. It's really important, first of all, that this actually be relevant to what's in that space, and it doesn't distract the user from the actual label. It should also never, ever, ever, ever be used in place of an actual semantic label on a page. So for a few reasons, first of all, placeholder text disappears when I start typing in the field. Maybe I've started to, I don't know, type in my last name on a form, right? And as soon as I get to that first S in my last name, I lose the label, if it's just placeholder text. Do you want an actual label for visual users outside that field? And placeholder text has the power to be really helpful and add additional information on top of a label so it's important that it be understandable. Excuse me. Cart timers are also a problem in accessibility land. I've had a lot of clients before who work in the performing art space, as I mentioned before, and when you're selling tickets to some cool new theater event, you don't wanna just let people have that cart, that ticket, sit in their cart forever, right? You need to time it out. It's important that cart timers, one, actually be necessary to your business, in the CAG, those are those accessibility guidelines I mentioned before, it lists all the valid business exceptions for having a timer on your website. And make sure you're actually a part of one of those exceptions. If you have a timer on your cart in some way. It's also important to make sure that your cart timer is actually long enough to accommodate people with disabilities. Now again, we don't wanna just let a cart timer be, I don't know, three hours or something, right? If it's a hot item. But it should be long enough, sufficiently long enough for all of the input fields you have. I know I personally have had an experience where I was buying tickets to a conference for myself and a few other colleagues, and there were so many questions as a part of that final payment about dietary accommodations, and this, that, and the other thing, in order for me to give them my money, I didn't have enough time to enter in the information for all of the tickets before my cart timed out. And I'm pretty quick at typing, right? So it's important to make sure that your cart timers are of a sufficient length for people with disabilities. You should also have clear error messages. There are a lot of folks, specifically brands that their style of writing is kind of hip and like quirky and like snarky, right? That will have an error message that's like, oops, looks like you messed up somehow, right? No, no, no, no. We want these to be clear. I think as engineers, we tend to default to really clear text like that, right? We want to just say, your card number wasn't valid or that's not a valid address, right? So push back against designers and content writers that want to make errors really cute. They're awful for accessibility. Errors should also adequately show what actually went wrong and ideally how a user can fix it. So information about a card being processed should be more than just we couldn't process your car. It should be something went wrong on our end or your bank declined it or whatever the actual error might be so that way the user knows how to fix it. You should also avoid JavaScript for form functionality. This is a huge problem on sites that have just a single page and you're going through using JavaScript and it looks so slick to a cited user. The problem is it's really hard to tell a screen reader when something on a page has changed that you just changed with JavaScript. So I know JavaScript can make a site look really cool and really flashy but for important things like a payment form, avoid it as much as you can, right? You want it to be accessible. Also your submit buttons should actually be inputs and not links. Generally on a form, if we're following the rules of HTML a submit button will be an input of the type submit. However, if we're messing around with JavaScript we have a tendency to make it a link and style it to look like a button. It's actually super confusing for screen readers. A screen reader will assume that a link takes you somewhere else whereas an input submit, well, submits an input, right? More than anything, really what you should keep in mind is just follow the rules of how HTML works. I recommend reading through the sets of guidelines I've discussed. I actually have a lot of additional links you can find on my site and on my Twitter. And I know this has been a lot of information that I've thrown at you in a half hour but I want you to know that you can do it. Ah, I know that sounds a little cheesy but really you can, right? All of this may seem a bit complicated, a bit scary, right? You don't want to get sued, you don't want somebody to get mad at you. Accessibility can be really time consuming and costly to implement, especially if you're adding it on after you've already shipped a product. The thing is though, this is a solved problem. Those of us who work in the accessibility space have best practices for you to follow. Compared to other problems in code, this isn't actually that difficult. We're not inventing some whole cool new blockchain way of implementing payments or some new image compression thing, like not. We're just using basic HTML and following the rules. It's actually not that hard. So my main takeaway for you is that accessible payment forms are doable. Sure, you don't want to be on that list of companies that have been sued because you wouldn't just take people's money. I encourage you to learn a lot more and make your payment forms accessible. Thanks.