About this talk
Laura will go over how The Financial Times went from being generally oblivious about accessibility to making it a core part of their process across multiple divisions. She'll share the roadblocks they found and the lessons they learned, along with tangible solutions you can integrate into your own project, regardless of available time, budget or support.
- I once sat in the audience for an accessibility talk much like you are now, and I remember feeling like this accessibility stuff is really awesome. It's really cool. But I thought, does this really apply to me, to the thing that I'm building? I was building a mobile website at the time, and I kept hearing about all these keyboard shortcuts and all these things. So I thought, oh, maybe if I was building an actual website. So it felt like accessibility was very far away from the thing that I was building. And looking back it's kind of embarrassing, now that I work on this, just to have felt that way. But I like to fully own having been there just 'cause it helps me appreciate just how easy it is to feel that way, that accessibility is just this thing that maybe could apply to your project but maybe not. So fast forward to 2016. I started working at Financial Times. We were building the greatest, fastest, site in the news industry. We released last October. It was a great success. We replaced an old website they used to have, and we started winning a bunch of awards. We were excelling in performance, security, basically, every metric that we had set out to excel on we did. So one day we decided to look at accessibility. You know, we were excelling at all these other things. Maybe we're good at this, too, just magically. But unlike performance and security, we never really put a collective effort into improving accessibility, so no surprise. We weren't very good. And since this talk is going to be all about the lessons that we've learned, this was the very first lesson that we learned. Accessibility doesn't just happen. You have to make it happen. So my name is Laura Carvajal. I'm a Senior Developer at the Financial Times. It's an actual picture of our office. We are a magical place. We own a rainbow as you can see. I'm the Developer on the Accessibility Team. Today, I want to tell you about all these lessons that we learned when we're building ft.com, and basically, when we realised that we had built this beautiful performing thing that couldn't be enjoyed by everyone. If today, you're in that place where you're wondering if all this applies to your project, hopefully, by the end of this talk, you will walk away convinced that not only does it apply to your project, but it's just really easy to get started. So what is accessibility? There are many definitions out there, but there's one that I really, really like, and it's this one right here. "Web accessibility means that people with disabilities "can use the Web." That's it. I really like it 'cause it boils it down to the very core of this. It just means not denying anyone access to the thing that we're building. And I want to go a little bit deeper into this by telling you just a very, very quick story. I was in this shopping mall in Wembley not long ago with my daughter, and we were going up those escalators that you see there. And as we were going up there, my daughter asked me, so how does someone in a wheelchair do what we're doing? And she's only 10-years-old, but she's very aware of accessibility mostly because I practise my accessibility talks on here. But as we were going up there, she was asking me this, and feeling all proud, I said, oh, there's an elevator somewhere. And she asked me, where? And honestly, from there I couldn't see it. It's a very long hallway if you know this shopping mall, and as we got to the very top, we could see it at the very far end of that long hallway, and she said, well, someone in a wheelchair would have to go all the way there and then up and all the way back to do what we just did? That's not fair. It's funny 'cause children have a way of seeing things for what they are, and that was really the case. The building was obviously accessible. It complied with all the regulations, but it was just really not fair. So I'd like to expand on that definition that we saw before by saying that, beyond not denying access to the thing that we're building, we need to make sure that the access we are providing is fair to everyone. And I'm giving my daughter full credit for that quote. So as we talked about tonight, we'll mention accessibility, but we can sort of split disability into these four categories: physical, visual, hearing, and cognitive. And we may be familiar with permanent disabilities, so permanent disability would be being deaf or hard of hearing, but we also have temporary and situational disabilities. So while closed captioning, closed captions that benefit someone who's deaf would also benefit every one of us as we fall on that spectrum. And I like to say us because each and every one of us will spend some time somewhere on that spectrum during our daily lives. 'Cause we may have other reasons to want to watch that video without audio, so it's a thing that's not an us versus them. It's not something that just benefits some other people. It benefits all of us. But as far as permanent disabilities go, there are about one billion people in the world with disabilities. That's about 15% of the population. And it's good to bring that number to what it is in our projects, so if you factor in where your user base is located, the demographics, and everything else, you can get a clearer picture of what that number really is for your product. So for the Financial Times, we worked out that that number was about 26% of our users because our user base skews slightly older, and in that older segment of the population there's a high propensity for disability. So that's what the number turned out to be for us. And like we go to great lengths and a lot of teams do to make sure that we provide an experience for all the segments of our user base. So for example, if you have people using Internet Explorer, and that's only 5% of your user base, you probably still make sure that they get some experience out of your site, and all the sudden, we have this 26% that we could have potentially been ignoring and didn't know about. So these numbers tend to be a good motivator to get started. So let's say I've convinced you now. You're determined that you want to do this. You're gonna fix accessibility on your site, and you're gonna be the very best. But it's scary, and it's overwhelming, and there's just so much information out there that sometimes it's just hard to know where to even start. Our advice is just start small. For us, starting small meant doing that. We installed pally, which is an open source tool that can check your HTML, and it can detect some accessibility errors automatically. And I say some. It doesn't detect everything, but it's a really good place to start, and it's easy as that. There are obviously other tools out there. They're all really good, and they're similar, but we use pally. It's just backed by a great community of developers, and we really had a great experience. And it's just a very welcoming community behind this tool. And so yeah, I highly recommend it. And there are others out there like AXE and a few others. But yeah, give this one a shot. It's also a great tool if you want to support open source. The way it works is it goes through the web content accessibility guidelines, which is a list of criteria that accessible websites need to meet. And it checks your markup against every item in that guideline, and it gives you a report of what's broken. So the very first thing that we did was we ran pally manually on ft.com. So if you see there at the very top, we do pally, ft.com with a few parameters. We're just telling it to give us the errors. Just for now ignore warnings and notices. Initially it gave us a lot more than two errors, but this is sort of what it looks like. It gives you a report, and it tells you where your page is broken. And we could have gone about fixing the things that we found, and then in a few weeks running it again, and then fixing the things it found then. But in such a large scale project, we really needed something that we could automate and integrate into our process, so that's where pally-ci comes in. It's developed by the same team, and it's basically a wrapper around pally that makes it very easy to integrate with any CI tools that you may have. So I want to show you what this looks like for our projects. This is a very simplified view of the build process in ft.com. So we have multiple note apps. The front page is one app. An article page is another app. Sign up forms, things like that, we have a couple dozen of these, and they live in GitHub. And every time we push to a branch, it gets built in CI, and if it's the master branch it goes on to Roku and onto production. So it's kind of a very simplified view of how we build stuff. And this is where pally-ci kicks in in our continuous integration step. It runs on every push of every branch. It tells you if you have accessibility errors. To integrate this into our process, all we had to do was that line there, and all that does is run pally-ci. It's pretty straight forward. Pally-ci can be customised further, so in our case, every branch deploys a test app with a custom name. Pally-ci simply runs on that. An interesting bit here is that threshold argument. This will run pally-ci on your test app, and even if it finds errors, it's not gonna break your build. It will allow you up to 100 errors or however many you set there, so your build will still agree. You won't have stopped production there. But you will start to see a report for the accessibility errors you have. So for us this was a really cool way to start 'cause we had, like I said, a couple dozen applications and 20, 30 developers working on this and releasing dozens of times a day. We couldn't really stop production and say, hey, we're gonna break all the builds until you fix all these issues, and then after you fixed everything, you can start releasing features again. So we really couldn't do that. So this was a way to get pally into all of our applications. So what we did was go one by one through these applications, and then fix all the accessibility issues that we found there. And once the application had zero errors, we would remove the threshold argument. And at that point, when a new branch was created, if that branch had accessibility errors, then that build would break. So that was a few weeks to do that for all of our apps and getting all those errors. But ultimately, we did it for all of them, and we had pally included in all of our applications, and that was a really, really cool moment 'cause we felt like winners. We had achieved a really important thing. We felt like, you know, we had some security that we were in a point where no more automatically detectable accessibility errors would make it into production. But we realised that even though people were all for pally, everyone was excited about accessibility, people were excited about their builds breaking and excited about having something that would prevent them from including accessibility errors into the live site. We didn't do a good job of explaining how those builds with breaks or what to do when they did. So it was really lesson number two that we learned. Before you set the build on fire, train people. So we're gonna go over a little bit of what pally actually found and what we did to fix it, which is what I would have liked to have known beforehand. So it's, you know, live and learn. So one of the most popular issues that would come up was contrast issues. So this is when the text and the background don't really have high enough contrast. So one place where this happened that we can see here was in our footer'cause it turns out that light grey on top of slightly less light grey is not really great for contrast. So the rule here is you have to keep your text and your background at this ratio, 4.5:1. So what we did with the footer was just tweaked the colours a little bit that you couldn't really tell. So after it was fixed, it looked pretty much like this. And designers were happy 'cause to them, it looked really exactly the same. But it passed this threshold and then all of our, we were able to remove all those errors in pally. Another popular one has to do with alt text and images. And the web content accessibility guidelines just require that all images have an alt attribute. So stuff like that will break pally. So it will break your accessibility tests. And all you need to do is that to make them pass, something like that. But it's really, pally knows only up 'til there. It's really up to us to decide what the text should be if there is going to be text in there at all. So I'm gonna talk about three main types of images, and Aaron has covered some of this in his talk. So we're gonna talk about decorative images, images that convey information, and images that convey really complex information 'cause they have slightly different ways of dealing with alt text. So in the case of decorative images, and I apologise in advance for the Trump image. Again, so decorative images are images that don't really add to the content but are used mainly as decoration. No pun intended here. So there's really no need to add to this image that an alt text saying, you know, Trump waves despondently or something like that 'cause it really gives nothing to the user, so what we do in these cases is we add a null alt or an empty alt. So this tells assisted technology that we haven't forgotten about the alt and that we are explicitly telling assisted tech to ignore this image. There are some screen readers depending on your settings, especially on the Mac that may still read out image when you navigate the page. So what we do at Financial Times is we add role presentation besides the empty alt, and that way even the most, even the voiceover on the Mac, which is kind of weird with this, will ignore the image altogether. So if you have these two together, the decorative images will be ignored, which is kind of what you want. So then we have images that convey information. It's really up to us. Pally doesn't really have a sense of which is which. So in this case, we don't really need to read that, but that article is called, How Donald Trump Won the US Presidency in Pictures. So in this case, the pictures really are an actual part of the story. So in this case each of the pictures are actually information that we're trying to give to the user. So in this case, you could just do alt and then some text explaining what each of the images is, and these need to make sense on their own. So if you were to sort of out of context try and read that, you would know what the image is about. But if it's in context as well, it would make sense with the text that surrounds it. Finally, and this is some of the stuff that we're currently working on. We haven't quite worked this out yet. The other two are kind of easier to do, but these are the more complex images like these ones. So like charts, infographics, these actually convey a lot of information. So you may see onlinethat advice to use a longdesc attribute, but that has really strange support, and it's actually has been or it's gonna be deprecated. So we really don't do this at the Financial Times. What we want to do, we're trying to do, is in each of these images, we like, keep the alt text of like the subject of what the image is, then link to a document elsewhere where you have an actual description of the image. So it's like an alternative format. So if you read that description or if you saw the image, you would get the same information. So yeah, and if say your design really didn't allow a link, you could make this a hidden link, but ideally, it doesn't really hurt to have a link like below the image that you can click through to, and then read the description of what you would be seeing. Another alternative to making these accessible is just to not use PNG, to use SVG if you can. We are trying to do that in some places, but it can be complex, especially if you have a lot of large images on your site that get created automatically by different tools, et cetera. But if you can use SVG, give that a shot. That SVG lends itself to making images and complex graphs, graphics like this very accessible. So yeah, another type of error that we got was in forms. So there's a lot that you can and that we did break and get wrong with forms. I'm just gonna cover two things, and there are labels in forms and fields that are required. So in the case of labels, let's see what we got. All right, so you may have used this sort of syntax. So if you have a label and an input, you can tell that the label is for that input, and you'll refer to it by ID, which is really nice semantically. I remember myself having used this before and saying, okay, that's very nice. That ties the two together. But it's very easy to forget to do this because if you forget to do it, nothing really breaks visually on the page. So this is something that we found we had a lot. We had it in some places, and then, in other places, we just forgot to do it. So for assisted technology, this really makes a huge difference. If you don't have that relationship, when a screen reader reads the form, it's just gonna say, input. And the user has no idea what they're supposed to be entering in that field. Once you have that, it will read out something like email address, input, so the user actually knows what they're supposed to do there. Another thing was required fields. So we used to just say that a field is required by having that star there, but that reads out email address, star, input. And you could argue that users are used to this, so when they hear star, they say, okay. This is probably required, but the better way to do it is to actually make the input required, and ideally, getting the star out of the label, and just putting it in a separate span that's hidden from screen readers. So it would read out email address, input field required. That's it. So it's just small changes using semantic HTML that we may already know. It makes a really big difference to assisted technology. Another big issue is ads. And when aren't they? It's true that this stuff is just third party code that's injected into your site if you unfortunately have to have them, and you really have no control over that markup or its accessibility, which is usually broken. We do have control over the markup around them. And there's ways of tinkering with some things that I'm going to show you. So what we do is we wrap, yeah, sadly, we wrap all of our, the injected stuff, which is usually iframe Sense for iframes. We wrap it in a div, and we give that div an aria hidden attribute of true. And then what we do is if we have a lot of iframes in there, we go in and we give them, so after the code has loaded, we parse it, and we give each of the iframes a tab in this index of minus one 'cause the first thing is just gonna hide it from screen readers, but if you are tabbing through the page, and you haven't done that, you might get trapped. So you might tab into the ad and just get lost in there. You're tabbing can get stuck in there, and if you're navigating the page without a mouse, you can really, it can make everything under it really useless. So giving every iframe in there a tab index of minus one will guarantee that, you know, you can skip right over them. And let's see, the last thing I'm gonna go over is having duplicate content on the page, which can cause different issues. There's two types of duplicate content. When you have two things on the page that are exactly the same, and then when you have two things on the page that look the same but are really different. So I'm gonna go over that a little bit. So if you have two things that are the same, you can just keep one for screen readers. So for example, in here we have this component down here that says, Latest on Russian Politics. It just gives you a list of latest articles on that topic. But we also have it at the very top of that page. So when you get to an article, you see it right at the beginning and you start reading the article. And then at the very end you see it again in case you want to jump to another article. So visually it makes sense. It's what we want. But if you are going through the page with a screen reader, you're just gonna get two duplicate pieces of content, so you actually have no reference of where they are on the page or why you have two of them. So it just duplicates stuff for users, and on a site like ours where we have a lot of content, the user's already getting a lot of information read out to them, so the more we can remove duplicate stuff from that the better. So what we do that there is we we add aria hidden true to one of them. I believe the one at the top, so the user going through the space with a screen reader would read out the article, and at the end of the article, they would get read out these other related articles. So it just gets read out once. So if you have two or three or more of those, just leave one without that, and make all of the rest aria hidden true. Another case is where you have things that look the same but really aren't. Like, all those buttons look the same. But they are adding different topics to your myFT section of the site for them, so just topics that you want to save. So for like visually, we can tell that that button's gonna add that topic to your thing. But if you're in a screen reader, and you're normally pulling up a list of buttons when you get to the page or a list of elements, and you're gonna get a list that says add to myFT, add to myFT, add to myFT with no context whatsoever, so you don't know what each of those buttons do. So if your markup looks something like that, what we do is we add the topic inside the text of the button, but it's visually hidden. So visually, nothing changes 'cause probably your designer wouldn't want a button that long and buttons in different lengths or whatever. So you respect the designer's wishes, but you can still add context to the buttons. So now, when you put up a list of buttons, these will be read out as add Europe to myFT, add Vladimir Putin to myFT, et cetera. So yeah, it's just a nice way to fix that. There are obviously many ways to fix all these issues, but these are just the patterns that we've used at the FT. So while we're on the topic of, you know, set the building on fire. Train people first. So these are good things to go over if they apply to the stuff that you're building. But also, training. So this is one training that we did. It's like a Udacity course by Alice Boxhall and Rob Dodson from Google. I'll share the slides later on, and you can grab the URL. It's really good. It's a really good place to start. It just covers the basic of accessibility, and then it goes deeper into semantics and things we can do to make accessibility better. It's the one that we did at the Financial Times. You can do it at your own pace, and it's really great. I highly recommend that. We've said so far that tools like pally and these other automated tools will cover 20 to 30% of your potential instability errors. And the rest really requires some human intervention. So I'd like to say that by the way, having reached zero errors of the ones that you can automatically detect, you're sort of there, but there's still that bit to go. So I'm gonna go over that real quick of things you can do to get the rest of the way there. You can have an external audit, which is basically a third party expert checking your site. You can do some customer research, which is really having actual users with disabilities testing the stuff that you build, or you can learn to use assisted technology yourself. These are not really mutually exclusive. Ideally, we should be doing all these. I'm just gonna go over each of these and how we did them for the Financial Times. So the first one is the external audit. We had the Digital Accessibility Centre conduct an audit for our site, and I'm gonna show you a really quick video of the work that they did. See if we can get, I think we can get audio. There we go. Oh, man. Do we have the volume? So this is just a quick two minute video, but we actually spent the day there with them, the whole day as they were testing our site, and if you have the chance to do something like this, I highly recommend it 'cause it really will change your perspective forever of how a lot of users use your product. So after that test session, it produced a 200 or so page report with all the errors that were found. This is after we had fixed the automatically detectable ones, the stuff that was found manually. So we spent a few weeks fixing those, and once we did that, we got on official accreditation. We put it on the site. We were very proud and very glad to get it 'cause, you know, it was months of hard work obviously. And we're also very glad to be the first in our industry to get something like this, but this is really not a title that we want to hold alone, so if you know anyone or we have anyone here from The Guardian, The Post, The Times, or any other publication or really anything else, this is really something, like this metric, is really something we should all be trying to outdo each other on. So another way to check for problems on your site is by having actual users test them. Sounds pretty basic, but we don't normally do this. You may have all the theory right. You may have all your accreditation in place, but you want your new features to be tested by actual users 'cause otherwise, you might end up building something that looks good on paper, but still get it very, very wrong. Another thing is just learning to use some assisted technology yourself. You can do this for free, and I highly encourage it. So if you have a Mac and this is some of the tools that we use at the Financial Times. You can use VoiceOver as a screen reader. You can test using only the keyboard, and you can test with the zoom capabilities of the Mac. I'm gonna go over very quickly on just how we test with a keyboard 'cause initially, we thought, okay, we're gonna just test our site using the keyboard and then we're just gonna go about our daily lives using our mouse and our trackpad, but what really made a difference in testing this this way was going keyboard only all the time. So not only when you're testing your site but all the time. So this is what my setup looked like in November 'cause it's yeah, as she mentioned, you should print out shortcuts before you like really get rid of your mouse. Otherwise you're gonna be stuck, so I printed out, I think, for the top five apps that I use, my text editor, Slack, email, like Google things. So it's, as you do this, all the paper will go away because by using the shortcuts, you'll just, even if you don't want to, you'll memorise them. So I think my setup now is just that little bit of paper right there. So everything else is gone. So another thing that I've found helps is since you have your trackpad, if you're on a laptop, you have your trackpad right there. It can be just even subconsciously, just boop. You go back to your trackpad, so what I've done is I've gotten rid of all the goodies that come with the Mac, so secondary click, tap to click, and I made the tracking really slow. So my trackpad is annoying. Whenever I go back to it, it reminds me to go back to the keyboard 'cause it's just very hard to use. Yeah, that was really lesson number three. Throw away your mouse. So going back to this list of things that you still have to fix, it's really tempting to, you know, you've learned all the tools. You've set up your keyboard. You can, you know, roll up your sleeves and get started and fix everything yourself. If I can just give you one piece of advice, please don't do it. Yeah, so it's something that, I want to say I learned quickly. It wasn't quick. It took me a while. Just trying to fix all these errors yourself isn't really the right answer. You're likely to burn out. It's inefficient. Accessibility errors are going to creep into the code base quicker than you can go about cleaning them up, and you're really doing a disservice to your team by becoming a bottleneck. So this works a lot better. 'Cause most people will want to help and will want to make accessibility better if they know that the thing is happening and if they just know how they can contribute. So if you can, just spend some of that effort not just on fixing the box but on raising awareness and training your peers and everyone on your team. Also, if you have a say in what your recruitment process is where you work, you can make it part of your job description. So we add it to all descriptions that we used to have. So we added web accessibility in there. 'Cause ideally, if you're adding new people into the team, you want them to, if not be very versed in accessibility, at least to care about what it is. So we added it to our job description. We added it to our online test. And apologies for that, but we're currently hiring, so I don't want to give too much away. So yeah, if you have a say in any of those, just make it a part of that. So that was really lesson number four we learned. Don't take it all on yourself. Yeah, another good way to spread the word is to make an event out of it. So back in November, we put together what they call a road show where we invited a bunch of people to complete a form using a screen reader for the chance to win that Amazon gift card up there for 20 pounds. And we also had donuts, so it's Amazon gift card and donuts. People stopped by just to see what it was about. So this is what people had to complete. This is the form that they had to fill out. And as you can see, or not see, you really can't see very much. You're really forced to rely on the screen reader to use it. So a lot of people who stopped by didn't know what accessibility was, had never heard of what a screen reader was, so this exposed a lot of people to accessibility for the very first time. This is the form that they had to fill out, just a simple form with a bunch of menu items that would feel the pain of going through all those. Just had to enter their name and submit that. Like, then we would have a random draw and whoever we picked out would win the Amazon gift card. So the real big takeaway from this experiment was actually one of the highlights of my career in the 15 years or so that I've been doing this software development in general. It's moments like this. That's Patrick Hammond. If you know him, he's a seasoned software developer. He's rarely surprised by web stuff, but this was his reaction to interacting with the web with a screen reader for the first time. And we got that from a lot of people, so we managed to create a space of collective empathy, if you will. So we had dozens of people stepping into someone else's shoes for a short period of time. But it was really powerful. And it was really effective in creating awareness in our team. So that was lesson number five, talk about it, a lot if you can. So spread the word. Make it your thing. Make it the thing that you're remembered by. And you never really know who's listening or who you're inspiring to then come in and contribute to the accessibility work. So yeah, if you care about this, then you should talk about it a lot. So we've said that these are the things you could do to make sure your website is accessible, but some of these cost money. So it doesn't mean you can't do accessibility if you don't have the money, but you can certainly improve it a lot if you do some of these. So you may need to raise some money to cover some of that, and we did. And the end of last year, just being new to this whole thing, I just said, well accessibility is the right thing to do, so I'm just gonna go with that to the, you know, people holding the purse strings at my work, and I will just tell them. It's the right thing to do, so give me some cash. And it didn't work that way. So quickly learned that it's the right thing to do doesn't always get you a budget. So there is some really good research done by Alice Bartlett, and you can grab that link later on. She tried to do some research on how to build a business case when you try to sell accessibility when you need to raise that cash. So the real only evidence, business case, that she found was avoiding litigation, so if you're a large enough company, and you don't want to get sued, then you're better off fixing accessibility. So it's the cost of just even having your name out there associated with, you know, someone who didn't care about inclusion is just the cost of that can be a lot higher than just fixing it in the first place. So yeah, in the last slide, I'm gonna share that link and some others that you can grab. So before we finish, I want to take you back to how this all began for us at the Financial Times. While I was on bug duty one day last year around this time of year actually, and I saw a card on our juror board. Well, actually, bug duty's juror board, bug duty's the only place where we have a juror board at the Financial Times, and I'm glad for that. But in that board, I found that card that said, integrate pally. I didn't know what pally was. I found it there and just picked it up. And when I looked at the history of the card, I saw that it had been bouncing around our board for a good couple months until my colleague, Ben Fletcher, who at the time was a Senior Developer at the FT. He prioritised that card, so he said, hey, this is something that maybe we should be looking at. And Ben just happens to be deaf-blind. He's a developer like the rest of us. But just his, that little action that he did there snowballed into something a lot bigger. And that was really lesson number seven that I want to leave you with. So diversity improves your perspective really. It will improve your product. It will improve your team. It will improve your life. So that little action led to us building a better product. It led our team to learning about accessibility. And it led me to stand in front of you all here today. So it's not the most important last lesson I want to leave you with, diversity matters. So to recap what we've covered and to leave you with things that you could do tonight if you wanted to. Accessibility doesn't just happen. You have to make it happen. If you want to make it happen for your project, you can integrate pally-ci into your build tonight. You can give it a very high threshold. It's not gonna break your builds. Just get it in there. Start getting reports of what you have there and just get a sense of how broken accessibility is. It might be that it's not too broken, and it's cheap to fix. You never know. Get it in there. You'll find out. Train your people. That Udacity course obviously takes a couple weeks to complete but something that you can do very quickly tonight is just to share that link with some of your colleagues. Just make a bookmark to do it later. Throw away your mouse. That's very quick to do. Ideally, just print out some shortcuts before you do that. That's also very quick. Just don't take it all on yourself if you're gonna do this. Share the load. Just talk to your peers even outside of the development team, very importantly, the designers, QA, everyone in your team that you can get them involved and excited about this. Talk to them. Talk about it. You can go on Twitter. There's a bunch of people. I'm going to share a link with you of a bunch of people you can follow on Twitter who are just great inspiration who have great information on all of this. You can put together a road show at your company if you have some common space and you have some donuts that you can bring to get people excited. I can share the, actually, I think it's at the end of these slides. If not I can tweet it out. The code for that form that we had if you want to play with that. If you need to get a budget, remember avoiding litigation tends to get things moving. At the end of this, there's a link with a bunch of public lawsuits and the amount that companies were sued for in each of the lawsuits like Netflix and Tesco. I don't know if Tesco did it right. Netflix, for sure got sued for not having closed caption. So anyway, that link's at the end, and you can grab that and use it as a weapon to rake some cash. And lastly, diversity matters. Sadly, I don't have a silver bullet for you to do this in, you know, tonight in a few minutes, but if you have a say somehow in how your company deals with diversity, prioritise it. And if not, just talk about it a lot, too. There's a version of this talk at that URL. I'm gonna update it to be this one. Yeah, over there, you can, write now you can if you wanted, you could grab all these things that I've shared. So a while back, it would have been common to have this be the only entrance to a public building, but these days it would be unthinkable, right? To have something like this be the only path to enter a building, so don't wait until it becomes unthinkable to build an accessible website. The time to make your website accessible is really today. Thank you very much. - [Audience Member] So assuming that once you know the problem you can fix it, from a developer's perspective, what would you think was the biggest hurdle you've had to overcome when trying to achieve this aim? - From a technical perspective you mean? - [Audience Member] It could be either. I don't now. I mean, could be business, could be UI in general. Do you see what I'm-- - Yeah. It's one thing that was hard was the getting a budget part, just having to sell it beyond. I mean, in our development team and design team, it was really easy to, once you sort of expose the idea that hey, all these people use the web in this way. We need to make it easier to be used by everyone. Just everyone's on board immediately. But once you say, I need this amount of money to buy this tool or to get this training, it gets a lot trickier. So that was-- - [Audience Member] Was it a question of convincing the business, do you think? - Yeah, 'cause you need to find alternative ways of selling it. It's not just, oh, this is the right thing. Just do it. You're gonna hit a lot of walls if you try to approach it that way, and that's what I did, what we did initially 'cause we didn't know. - [Audience Member] So what helped you to convince them? - Getting all these other arguments, just having them ready. It's like, you can be sued. That's sort of the first one. You can be, and then all the evidence that it actually happens in the UK. It happens world wide, and the amount of money that it happens for. Also that you're potentially losing 20 or whatever percent of revenue 'cause it's actually users that if you have a subscription service and the page where you're gonna subscribe is not accessible, then it's really people that want to give you their money, but they can't 'cause they can't use your site. So making sure the site's accessible will enable these people to actually pay you money. So that one works to an extent. But I guess, well, depending on the company, if it's a big enough company, just the fear of being sued, the rightful fear of being sued tends to work, but it took us a while to figure that out. So that was the most frustrating bit of it I think. Yeah.