 y prinsybul yng Nghymru i gael eich cyfweld i gael y gweithio gyda'r grwp ym Ysgrifennu. Yn ymweld, cyfweld y gweithio gyda'r grwp yw Ysgrifennu, mae'n ddweud yn ymdillol i gael y cyfweld i gael eich cyfweld i gael y gweithio gyda'r 4 ymgynghau H2ML 5.1, yw ymgynghwmpwnu, yw ymgynghwmp yn ymgynghwmp yn ymgynghwmp yn y bwysig ymgynghwmp. I'm also all that's standing between you and a pint. And I'm going to talk about accessibility. So if you're sitting there with your head in your hands, just give me a few minutes of your time. If it turns out that accessibility really isn't your thing, then over the course of the next few slides, I'm going to use some movie quotes from some of the greatest films and probably a couple of the worst over the past few decades. And if you get really bored and you don't want to listen to the talk, you can just sit there and play Guess the Movie instead. But to accessibility. Houston, we have a problem. We have a big problem with accessibility. Actually, we have two problems. One is that accessibility has a pretty bad reputation. It's not really that sexy. It's not really that cool. It's definitely not something all the cool kids are thinking about. And because of that, our second problem is that it doesn't happen. And that causes problems for a lot of people out there using the web. Now, there's a number of reasons why this is the state of affairs and accessibility at the moment. The greatest trick the devil ever pulled was thinking world that he didn't exist. And this, to some extent, is a problem with accessibility. People think that it's not really a thing. It doesn't really matter all that much. But the truth is, it matters a great deal to a great many people. I could quote a whole bunch of statistics at you. But I read an interesting one in a Mozilla Hacks article just recently posted to their channel on Medium, written by Chris Mills and a couple of his colleagues at Mozilla. And in it, they came out with the statistic that there are more visually impaired people in the United States than there are internet users in Canada. So if you think it's not a thing and it doesn't really exist, there's probably a whole bunch of people over there who are really going to get quite cross with you. So let's go to the Winchester, have a pint and wait for this all to blow over. That's the other thing, accessibility doesn't really matter to a lot of people. It's like, well, if I ignore it, it'll probably go away. The truth is about accessibility. If you get it right now, you're going to help an awful lot of people. The really important thing from your point of view is that if you get it right now, you're going to be helping your future selves. Because the sad truth is, you're not going to be young and one of the cool kids forever in a day. There is going to come a time, and I'm sorry to say it, when bits of you aren't going to work as well as they do now. You might not see straight, you might not hear as well. You might have spent too much time typing over the intervening 25, 30, 40 years and find that your fingers don't work as smoothly and as well controlled as they used to. So think about accessibility for selfish reasons. Think about your future selves because trust me, it is going to come important at some point in your futures. I'm sorry Dave, I'm afraid I can't do that. People will say, I can't do accessibility because the project manager didn't think about it. My client didn't ask for it. The beam counters at the head of the organisation didn't include time and money and budget for it. But the truth about accessibility is that if we all do a little bit, we all play our part with the roles that we play within the bigger picture. We can actually accomplish a great deal without needing anybody's permission. That's really worth thinking about. It's just part of everybody's toolset. There's nothing special, there's nothing in isolation here. It's just something that everybody should think about and if we all do that, we can actually make an extraordinary difference. Frankly my dear, I don't give a damn. That's the honest truth about how a lot of people feel about accessibility. For some reasons, that's because they've had a bad experience with accessibility or accessibility people. There's nothing worse than having your code reviewed by an accessibility person who then looks up and goes, well basically you can't code. If you knew the first thing about HTML, you'd probably know about accessibility. I've seen that happen, unfortunately. Hello, my name is Inigo Montaille. You killed my father, prepare to die. That's why a lot of people feel this way about accessibility people. Because we've had a pretty bad time of going out there and dismissing the hard work that people have put into the things that they build and they create. We spent a long time in the accessibility profession saying, you can't do this, you didn't do that, you failed that, you're going to get sued for the other, you're not conforming, you're not complying. I wonder you all didn't go out there and jump off a bridge quite frankly. So we have a big responsibility as the accessibility community in this to do better because we haven't covered ourselves in glory. I spoke to some people a couple of months ago and actually officially apologised, which I'll do again now on behalf of what went before in the accessibility community. I'm sorry, we got it wrong, we should have been more encouraging because what we know now is that there's actually a real interest in getting accessibility right. So I'm not bad, I'm just drawn that way. That's generally how most of us feel about accessibility. We didn't really set out to upset anyone, nobody really sets out to build anything that's deliberately inaccessible, but sometimes it just comes out that way. Part of the reason is that there are a lot of myths and misconceptions about accessibility. Aristotle was not Belgian, the central tenant of Buddhism is not every man for himself and the London Underground is not a political movement. I know this auto, I look them up. Accessibility is filled with things like this. Gentleman, you can't fight in here, this is the war room. Everybody sees accessibility as a bit of a fight. We're going to come in there like the accessibility police and we're going to tell you you can't do stuff. All the designers will tell you you can't do accessibility and the accessibility people are going to say, no, you can't have your beautiful designs and you can't have your JavaScript frameworks and you can't have your interaction and all the cool and funky stuff that we know everybody really wants. It isn't true anymore. It used to be back in the day, but actually if everybody thinks of accessibility as part of their own responsibility, you kind of do away with the accessibility specialist altogether and I'll be out of a job and in a bar having a pint somewhere, which would be fantastic. But seriously, if we all try to get along and discover where accessibility fits in, you can alleviate a lot of the tension that you can sometimes get when you bring people in from different disciplines with different requirements. You're going to need a bigger boat. People will say you need extra budget to do accessibility an extra time. Now there's a certain truth to this. If you're not familiar with accessibility or your team isn't familiar then, yeah, sure. It's going to take you a bit of extra time, possibly some money for extra testing or maybe training of your team or just upskilling, but actually what we're all aiming for is to get to the point where we don't have to ask whether something's accessible any more than we ask whether it should use JavaScript or HTML or CSS. It's just that when we use those things they are accessible. We don't even question it. It's just part of the roll call of the way we do stuff. Man who catch flyer with chopstick can accomplish anything. People think that accessibility is difficult and yes, it can be. Sometimes the easy stuff in accessibility is really easy, but building complex web applications is actually pretty complicated. But building those things is complicated anyway. You guys have already done the complicated stuff. You do cross browser compatibility in an ever-expanding market of browsers. You've done CSS layouts for goodness knows how many years before Flexbox came along and it was all just clearing this and hiccupping with the other. Believe me, if you guys can do that, you really can do accessibility, but that kind of leads to another one of the things. Toto, I have a feeling we're not in Canvas anymore. It's not that accessibility is really difficult that's the problem. It's that it's unfamiliar. When we design for people who use different platforms and technologies, things like tablets or smartphones, laptops, desktops, whatever they may be, we've got a certain degree of familiarity with what using those things is like. But there's a good chance that you don't have an understanding of someone like me who's blind using a screen reader experiences. Someone who's deaf and needs captions to look at or to listen to audio, video material for example. So finding those shared experiences is actually quite difficult until you realise that actually you do do things with a screen reader probably more often than you think. If you listen to your GPS in your car or as you're out walking, give you vocal instructions, that's pretty much what a screen reader does. If you use Siri or Cortana or Google Talk or any of those voice command assistants, you're using speech recognition tools just the same as people with physical disabilities do and what you're hearing back is pretty much what a screen reader user hears back. So the experience really isn't that unfamiliar. I'm fairly betting to bet there's a good chance that many of you have zoomed in on stuff on your touchscreen devices because it was just a little bit difficult to see. If you had a hangover at the time, I bet you did it even more because it was way more difficult to see with your eyes all squinty shut. But that's what partially sighted people do all the time. So these experiences really aren't that unfamiliar. Badges, we ain't got no badges, we don't need no badges. There's a school of thought that says accessibility is all about getting a badge to put on your website. It's all about meeting some legal obligation, some policy obligation. And the last two of those things are certainly true. A lot of countries, including this one around the world, have legislation that makes accessibility to services, including digital ones, a legal requirement. But that's not really what's important. We know this to a certain extent in this country because we don't have any case law. We don't have access to services suing people for the inaccessibility of their websites. What we do have over countries like the US where perhaps there is more litigation is a general acceptance of the idea that if we just get it right, we bring in more customers because more people are able to use the things that we're building. We might then bring in more revenue or spread our messages further or just have more users downloading our apps or whatever the product may be. So that's what we've got here, a failure to communicate. A whole bunch of things that really aren't true about accessibility but people still widely believe. So I generally think we can do better. I think we can do better as people trying to get accessibility rights and we can certainly do better as people trying to communicate how to get accessibility right when you're working on the coal phase. So this is your last chance. You can take the blue pill and the story ends or you can take the red pill and we'll go down the rabbit hole and see what happens from there. So what happens from here for the rest of this talk is the red pill. We're going to go down the rabbit hole and I'm going to try and show you that there's a different way to think about accessibility. Your ancestors called it magic. I call it science or you call it science and I come from a place where they're one and the same thing. Accessibility is a peculiar mix of usability and technology. Technology in the sense that obviously we're using all the different technologies to build products, web applications, apps, whatever it may be. But humans are an enormous factor when it comes to accessibility. There's every glorious configuration of human you can think of benefits from accessibility in some way. And that can make it seem like a bit of a fluffy subject. Something that's quite hard to grasp, hard to put into cold-blooded terms and certainly something that's really hard to identify solutions for at the code level where, I'm guessing, most of us are comfortable working. So in the face of overwhelming odds I'm left with no other option than to science the shit out of this. Are you ready? So first principles. Keep it simple. Accessibility is always going to benefit from stuff that's simple. Now we live and work in an age of frameworks of all different kinds of compilers, transpilers, preprocessors and any number of other bits and pieces that come together to help us in our day-to-day jobs. And they're all good things. They all have a really valid place in our ecosystem. So I'm not going to stand here for a moment, certainly not at an Ember conference and tell you that you shouldn't use these things. That would be ridiculous. But it is really important for you to understand as much as you can about the technologies that underpin these frameworks and tools. The more you can understand about vanilla JavaScript, about how CSS works, about how good old-fashioned HTML works, the better understanding you're going to have of the challenges in accessibility that occur when we start to use complex frameworks and other tools. So if you're not really familiar with how to do things, the kind of mental arithmetic way if you like, take some time and go back and play with some of the technologies and see what you can learn. Don't believe everything you hear, and only believe half of what you see. The reason is that for a large number of people with disabilities, particularly those who use technologies like screen readers, the code that underpins web applications and websites is absolutely critical to their experience. When you load some code up in a browser, it creates a document object model. Very familiar with that, I know you are. What you might not know is that the browser also creates an accessibility tree. It takes a bunch of information from the DOM and creates a tree of accessible objects or accessibility objects, and each of those things represents information about what's on the page. Something's role, its purpose, so heading has a role of heading because that's what it does in life. It's state if it has one, so a checkbox, an input with a type of checkbox and a required state that gets communicated, and also its label or its accessible name. How do you refer to that object? And this is why I say go back and have a look at the base technologies that underpin the tools we use, because what you'll find is if you use HTML in the right way, whether it's a product of scripting or just written in the old-fashioned text data kind of by hand way, you'll discover you get a whole bunch of accessibility information for free, and that's really worth bearing in mind because that's the information that assistive technologies like screen readers pick up on to make experiences more accessible. Computer magnify times 10. It's worth bearing in mind that people don't all use the same technologies. For those of you who remember developing for the web in its early days, even into the 2000s, you'll remember that we pretty much just had a couple of browsers to choose from. Actually for a time there was pretty much only one to choose from. People generally used a mouse and a keyboard and that was pretty much it. These days of course we've got smartphones, we've got tablets, we've got things you can talk to, things you can listen to, things you can tap, things you can hit, things you can scream at on a really bad day. The only thing we really don't know is what devices and technologies people are going to be using, and we therefore need to think about building in responsive designs as much as possible, because responsive design is really good for accessibility. If someone needs to literally zoom in and look at content, the way most zoom capability works in browsers and devices today is actually to change the resolution size so it will trigger the responsive layouts. So if someone needs to look at something really, really big scale, they can do it on a big monitor, but if they zoom in far enough, they'll trigger the mobile layout response and get that in much bigger view and much bigger clarity. If I'm not back in five minutes, just wait longer. This one actually really came to mind a couple of days ago when I saw a tweet from a friend who'd written a blog post because a company had just launched their new website. It was a really slick website. Very simple, just very content focused. It's extremely beautiful. All those things that we kind of look to and aspire to have in our websites. Until he discovered that the background image was nearly five meg. I thought he went off and had a look. There's a great website. I think it's how much does my website cost.com. It will tell you how much it'll cost to view a particular page in a website if you're on a data program on a mobile device in different places in the world. If you're in the US or the UK, it was fine. It was a couple of cents for the page and no big deal. But then he looked at the cost if you happen to be in, I think it was more a tania, and it was $33. Now $33, and don't even mention what that's worth in pounds at the moment, is a pretty substantial figure of money. But when you realise that if you happen to live in that country, that's about a third of your daily income, it really starts to put it into focus. I'm mentioning this because accessibility is also about different technologies. It's not just about people with disabilities. It's people who use old technologies. Some people with disabilities do use old technologies. Some people who use old technologies have to. Or they do so for a whole bunch of different reasons. But it's worth thinking about who's going to be consuming the thing that you're building, or who are going to be consuming it on. And just bearing in mind that not everybody is going to be using Chrome in a nice western country on a really huge connected data pipe. So thinking about people in different ways and different modes is really important. If you focus on what you've left behind, you'll never be able to see what lies ahead. One of the things that's come about in accessibility terms, particularly with using script frameworks and single page applications, is bearing in mind that you need to do a bit of work to manage the experience, so it's fairly similar to the native browser experience. Focus is a big part of that. If you're using a framework that redraws part of the DOM, you need to fake the experience from an accessibility point of view of having a new page loaded. So make sure that the page title changes when the view changes. And put a heading, if you can, at the start of the new content area, or the main content area, and update that too to indicate that new content is loaded. And what you'll probably also need to do is actively take keyboard focus to that heading. And if you can do those things, what you'll find is that for screen reader users, keyboard users, screen magnifier users, the experience is pretty close to what the browser will do natively had a new page loaded completely in the browser. So there are times when you're using frameworks for doing the things that they're very useful for, that you do need to take a few steps that the experience you're providing emulates the one people are expecting. So is it functional? It's fully mission capable. This again comes back to devices and more specifically input interactions. The stuff we build has to be functional for a whole bunch of different inputs. It's pretty commonplace now to think about mouse and keyboard, but that doesn't really cover the extent of it these days. You might be familiar and if you're not, check out the pointer event specification from the W3C. That provides a whole bunch of input events specifically aimed at mouse, but also other pointer devices like stylus and other bits and pieces. You also should check out the touch events, another W3C specification. And that provides some useful event handlers and methods for dealing with touch devices when you're building web applications in the browser. So things like the 300 millisecond delay that you can sometimes get while mobile devices are waiting for the second tap in a double tap gesture can make button interaction pretty sluggish feeling. So both specs will give you ways for dealing with input specific problems like that one. It's not rocket science. Just bear that in mind as I'm kind of just throwing all these ideas out there. This stuff really isn't difficult. There are a whole bunch of tutorials, resources out there, lots of people you can call on to do it. But some things to reassure you as you go along. Life is like a box of chocolates. You never know what you're going to get. Bear in mind that you never know what your audience is going to look like pretty much what they're going to be using and certainly why they're going to be using it. But also bear in mind that we work with a whole bunch of different technologies and accessibility is important to all of them. So no matter what project you're working on which particular technologies or frameworks you're being asked to work on at this point in time there will be accessibility bits and pieces to think about no matter what you're confronted with when you get into work on a Monday morning. But there are three ways to do things. The right way, the wrong way and the way that I do it. For some reason people think that in accessibility there should be a golden answer to every question. It's really quite peculiar. If I asked you guys how should I build a dynamic web application using a JavaScript framework. Now you're all going to say of course you are. But actually if I say that at any other DevCon I'll get 16 different answers and it will be absolutely right. And it's the same with accessibility. If you ask me how to do something I'll tell you one way. You ask my friends and colleagues in accessibility and you'll probably get three or four other different answers. That's okay. There are no right answers or at least no more than in any other part of technology. So don't worry if you don't find three answers all telling you to do exactly the same thing with accessibility. Just pick one, try one and experiment and see how you get on. That's okay. It's not the years honey, it's the mileage. There's a lot of people out there who've been doing accessibility for 10, 20, 30 years even back before the web was a thing. And between us we've got a lot of knowledge and expertise that we're quite happy to share. But that's not really all that important in the scheme of things. You don't have to know anything to get accessibility becoming part of your toolkit. You just need to take a deep breath and make a start. And bit by bit you'll discover if you read a little more and find a few more blogs and have a few more conversations with people that your knowledge grows and soon you'll be the one helping other people kind of come up the ladder behind you. So you don't need knowledge and experience. You just need the courage to get started. There's a very challenging observations you've made and the beautiful thing about people who come to something for the first time or they're still pretty new to it is the way the rest of us do it. And that's one of the fantastic things about the web. It's one of the reasons the web is just so incredibly exciting and entertaining and so widespread is because we can push its boundaries and we really, really should. If we'd all stuck to the standards and specifications exactly as they were intended we probably would never have had Web 2.0 if anybody can remember that phrase. We'd never have started building custom components and custom widgets because we'd have just stuck to the rules. If you think something in accessibility could be better, you think that the way it's always been done is not the right way. Stand up and say so. Say it positively and encouragingly but by all means go ahead and challenge it. There's nothing to say that everything we're doing or saying so far is absolutely right. New people, new ideas are really, really welcome. I think this is the beginning of a beautiful friendship. So what I want you to do next time you're in work and remember gentlemen, you can't fight in here, this is the war room. I want you to go and hug a designer. Hug an accessibility person. Go and find an interaction designer and hug them or if you're not a developer go and find a developer and hug them. If you're a full stack developer give yourself a hug and try not to be mean to yourself. Go find someone and tell them what's important to you about what you're doing and how you think it might affect the people that are going to use the product. Ask that person to tell you the same thing about their part in the role. See if together you can figure out how to make an interaction really accessible to all the devices. Whether you're speaking, clicking, tapping, touching or something else we haven't yet thought of. Trust me, you'll find it's a really, really innovating and happy experience when you can do that because you know that what you're going to get at the end of the day is not the conversation, well the designer just gave me this and they threw it over the wall and now I've got to build it and it's all broken and I can't put the accessibility in there because you can put pay to all of that or at least a lot of it. So really go out there and give somebody else on the team a hug, trust me. I told you, aim for the target, come in under the radar. You don't need permission to do accessibility. Sod the beam counters quite frankly. What do they know? Just do it anyway. Because like I say, it's all of our responsibilities but you'd be amazed at how much accessibility you can sneak in without anybody noticing and I guarantee you one thing, nobody's ever going to complain, I guarantee you. Come and find me, if anybody complains that you've sneaked in a bit of accessibility and somebody pointed out and said, no, that's not good enough for our clients or our customers. Come find me, I'll buy your pint. Because you can just sneak an enormous amount in. It might just be an alternative text on an image if you're working in the front end. It might just be making sure when you were developing that you did something like unplug your mouse and try to use all your functionality with a keyboard or on a touch device and made sure that it worked and fixed any problems that you found. It doesn't have to be much but without anybody really paying attention to an extraordinary amount that will make an amazing difference to a lot of people. You're only supposed to blow the bloody doors off. You don't need to fix everything. Little steps are perfectly right in accessibility. Because there is that whole kind of legal thing, a lot of companies, particularly those where legislation is important, they get very twitchy. Are we going to get sued? What do we have to do not to get sued? The truth of the matter is that every step you take towards doing something more accessibly is a step in the right direction. So if you can take little steps, you don't need a sledgehammer to a walnut. Just go and do a bit at a time and every day if you can do that a little bit more, you'll find when you look back that you've actually come a hell of a long way since you took those first few steps. And nobody's perfect. If you get something wrong, it doesn't matter. We all make mistakes. I look back on some of the early code that I wrote and it's absolutely horrendous and I'm talking about really horrendous table-based layouts and fixed widths and font tags for those of you who are old enough to remember back that far. We all do things that we look back and say, oh man, I shouldn't have done that. That's okay, because that's how we learn. That's how the web evolves, that's how we evolve and that's how we keep pushing the boundaries. And it's the same with accessibility. Go read up, try a solution, figure it out. If you can test it yourself, do it. If you can't, put a call out through any of your channels, any of your networks and see if you can find somebody for whom it's important to take a quick look at it and get some feedback. If you get usability testing with your consumer audience or your target audience included in the project you're working on, so much the better. You'll get more official feedback. But it's okay to make mistakes. It doesn't matter if we don't get it right first time because if we keep trying, that's the really important part. So these things beg the question and I kind of mentioned this before. Ask questions if you don't know something or something doesn't make any sense in something that you've read. Ask away. I joined Gitter and Slack channel called A11Y Slackers. A11Y is because there are 11 characters between A and Y and accessibility, so like I18N. It's got a whole bunch, a couple of hundred of accessibility people sitting there kind of chatting about stuff. They're all pretty seriously technical. So Google for that. There's a blog post with instructions for joining it. Go hang out on that channel because you'll get some good answers to questions if you need them. Shout out on Twitter. There are other forums. The web aim is an email forum where it's really good to get technical answers to questions. The web accessibility initiatives interest group email list is another place. There are lots of places where you'll find accessibility people out there and most of us, most of the time, are really happy to help. There are no stupid questions so just get in on there and ask what you want to know and I'm pretty willing to bet nine times out of ten if you need. So I guess it comes down to a simple choice, really. Get busy living or get busy dying. So this is your decision time. I want you to go out of here today and decide that you're going to get busy living. You're going to get busy changing coding, making it more accessible both for people like me now but also for your future selves because this is about living and hopefully we're all going to do that for much, much longer yet. So get out there and start changing the world for yourselves if not for the people now. I'll have what she's having. And the truth is that once you get that bug, once you get that energy, other people that you work with will want to know what it is you know. And I've seen this really strongly in effect. I worked with the Government Digital Service on the beta of the GovUK website and that started out in a room of 12 developers from the private sector and one of the principles that they decided on was that they were going to put user needs first and that meant accessibility. And as GDS grew and I think it's now somewhere over 400 people, that general culture, that attitude has remained because as new people have joined the team, they've seen that the people who were there before them just accept accessibility as something they should know. They take a pride in making it part of their job in just doing stuff the right way. And it's really infectious. Developers, all of us humans actually, if we think somebody else knows something bet your bottom dollar. The next thing we're going to do is look it up on the web and find out what we can do to know a bit more about it. So you guys have the power. Spread the word, make it positive. We can do this if we do it together. Oh my gosh. Look at that fluffy unicorn. He's so fluffy. I want to die. This is how I want people to think about accessibility. This is how I think about accessibility because this is how I think about the web. And I guess I hope it's all the same for you guys as well. The web is brilliant. It's crazy. It's hectic. It's insane. It's complicated. It's broken a lot of the time. But I love it. And I want to use it. And I have a disability. And that means I need stuff to be accessible. So this is how I want people to think about the web and because accessibility is just part of the web to think about accessibility in the same way too. So Carpe Diem sees the day. Make yourselves extraordinary. More to the point, please. If you do one thing, go out of here today and make your technology extraordinary because you will make a hell of a difference to a great many people. Thank you.