 Here's the panel that you've been waiting for after we had it hinted at every other panel so far and lots of questions and lots of quick solutions being thrown around. Like the last session, for example, when will voice recognition be the norm? Just easy. Take people's eyes out, take their arms off and they have to use voice recognition. A lot of things that we actually think is coming had to be used in accessibility for years and years already. I always see accessibility as a hardcore usability testing. It's something that people need and not something that we just want to have. But Derek is going to do a better job in that. My job is right now not to talk, but to introduce people. So to first make fun of the Germans that have a family name like Luthwaite, Sarah is here. She's from King's College and she's an academic researcher and writer bridging the gap between critical disability theory and accessibility practice, something that was on our mind for a long, long time. And we've been discussing a lot between us, hopefully. Andrew Rungslie over here is from the RNIB and he's an accessibility and usability specialist focused on the web and mobile platforms. He's also contributed to the SIRF rights standards, which is an interesting thing to look at. Alice Boxhol is from Google, but she knows about accessibility. Okay, that was unfair, but it was so good because everybody else I talked to, she's like, and here's Alice, she's going to talk to you later about accessibility, so no pressure. You have to answer all the questions right now. She works on the accessibility developer tools extension and library and that's something like we used in the past, we had performance tools for developer tools, but now we have accessibility testers in there as well, which are great and absolutely necessary for things like a Chromebook where you only have Chrome on it and nothing else. And Matthew Tiley Atkinson from the patch yellow group over there is for the patch yellow group a tester, screen magnifier and occasional text to speech user and he works on web accessibility, accessible gaming, which is an interesting topic, especially when you think about these kind of connect things, level editing and supporting older users. Old users, is that a political correct term, I'm not sure. So speaking of people that have been around for a longer time, I'm going to introduce you now to Derek Featherstone, who has been with me in the accessibility world for a long, long time and worked on the first book that we both had chapters in, the web accessibility book that two or four people read and followed up later on. So without further ado, over to Derek. So I'm here today to talk about accessibility and most people think of accessibility in very technical terms and the number one point that I want everybody to walk away from this today with is that accessibility is all about people. It has to be about people, because if it's not about people, we end up doing the wrong thing, even though we're meaning to do the right thing. So all of us that are up here have a background in doing this stuff for people, so Christian actually started his first foray into understanding accessibility was when he was working with people with disabilities when he worked for the Red Cross. Sarah is a researcher. She actually works with real people on accessibility issues. Alice is putting aria support into Chrome and that's for people to use. We cannot forget this. Andrew actually works with people taking smartphones to them to show them and demonstrate all the different accessibility features of smartphones and how those things can actually have an impact on their day to day life. And Matthew started changing the authoring environment for gaming so that that could be accessible to people that were blind. And I do too. I work with people with accessibility with disabilities every day. We do research and testing and try to figure out what UX is for people with disabilities. What does UX mean to them? And so hearing all of the things that everybody is talking about this afternoon and this afternoon has been absolutely fascinating because we're talking about it at very technical levels but at the end of the day people have to use those tools and that to me is what accessibility is all about. We tend to simplify things and you probably have heard of all of these different conditions or things that people have that people are blind or they have low vision, they have hearing difficulties or that they have a mobility or a dexterity impairment. And when you start to think of all of these things, even those things seem to be very physical but what about the cognitive side of things? And those are traditionally the things that we're thinking about when we think about accessibility but there's a whole other realm that we need to start to get into and explore. How many of you have heard of things like vestibular disorders? So there's a whole group of people that have some kind of vestibular disorder and I don't even like the word disorder but issues with their balance and so when they're looking at a screen with all of your fancy CSS animations and your parallax effects, that actually makes them nauseous. It actually causes migraines. So when you're scrolling down a page and you have a car that you've animated with CSS that's going like this across the page, that actually makes somebody nauseous. These are new things that aren't sort of in mainstream accessibility and we need to start to take those things into account. Things like speech, the very last panel was talking about what about speech and as Christian pointed out, voice recognition software was originally invented for people with disabilities. So on the speech side of things, and this is I think an absolutely critical thing for us to keep in mind as we move forward, speech is just one modality. What happens if we create interfaces that use that as the only modality and what does that do for somebody that speaks a different language that has a stutter, that maybe has cerebral palsy and has difficulty speaking? We need to create interfaces that are entirely flexible and one of the other panels earlier, the pointers, what about custom gestures? What about the fact that, and so here's a custom gesture, move up and to the left? Well, that custom gesture is already being used on Android for screen reader users that are using the talk back screen reader on Android. So what happens when that custom gesture that you've created and built into your page conflicts with the custom gesture that is required for the screen reader? So we need to think about flexible alternatives. So when I move up and left in talk back in Android, that means something to me and that gives me functionality. So even though you create a custom gesture like that in your app or in your page, you need to consider that maybe that's not the only way that we should be able to instantiate that action. Maybe we need some other method or a backup mechanism to do that. We need to think about all of these different things. We tend to put people in boxes and say, you're blind or you're not blind, right? You have a disability or you don't. But that is not reality. We have a scenario and this is a very standard Gaussian binomial bell curve distribution, whatever you want to call it. And we have people that live at one end of the extreme or another. And this one is talking about people's size. But think of it in terms of any ability. So you have people on one end that have maybe completely normal vision. On the other end, people that have no vision. And then you have people everywhere in between. This is not a binary all or nothing scenario. We need to think about that all the time. Today's assistive technology is really advanced. We've moved from a point where solutions that we used to think were completely untenable like ARIA. So ARIA stands for Accessible Rich Internet Applications. And it's a tool that we can use to add to our code to provide programmatic accessibility where it just didn't exist before. Screen readers for over the last five years have really advanced and really done a great job of getting ARIA support into that technology. But we have to ask this kind of a question. What if a brand new version of a certain type of assistive technology just isn't modern? And I'll give you an example. This is a suite of assistive technology tools. We've got voice recognition up there. We've got tools built into browsers. NV Access is a screen reader for the Windows platform that's free. Voice over on the Mac. Zoom text on Windows is a magnifier and reader combination. Now all of the screen readers on there, they have done a pretty good job of keeping up with modern technology. But some other tools don't necessarily keep up. And so I'm not going to name any names or single anybody out, but Dragon Naturally Speaking is a great tool, but it doesn't keep up with the standards. They haven't implemented any support for ARIA, and that's something that all the screen readers have done. I'll give you an example of why that's actually important. This is a very new version of a Google map. And these things on the interface, the search button and the Zoom in and the Zoom out, those things all used to be divs with on-click handlers. Pretty straightforward practice, very typical. This is something where we could actually improve that by giving it a div with a roll. Instead of just having a div with an on-click, we could actually give that a roll of button so that a screen reader or other piece of assistive technology in theory could recognize that that's a button so that there's a more natural affordance there that, hey, I can actually click on this instead of it just being a div in the page. The beautiful thing about this is that, and I just literally saw this with this new revision of Google Maps, they're actually now buttons. Like actual buttons. Holy crap, they're actually buttons. And that totally gets a gold star because all the semantics of a button are already in that native element, right? This button could be used by Dragon Naturally Speaking. The div with a roll of button can't be, right? So there's a question about whose responsibility is this. There's a lot of people that are pointing the finger at Dragon and saying, you guys are wrong. And I want you to think about this. From an ARIA perspective, this is the last time I stayed in London, I had this in my hotel room. This was a king-size bed. And so I had sleep apparatus with a roll of king-size bed, and it was two twins with a break in the middle. Now, I complained. I'm Canadian, I don't complain. So this was a big deal to me. So I complained and I got a new room and I got a new bed. And so in that bed I had a sleep apparatus and it was a king with a class of posh. Thought everything was great until I dug a little further. And I had a sleep apparatus with a roll of king-size bed, two twins with a break, If you remember nothing else about ARIA, remember that what's under the sheets actually matters. The tools and the code that you use actually have a huge impact on how assistive technology can interpret it and work with it. So thinking about those kinds of things and thinking about Dragon and how it works, is it our job to be responsible, even though we have a tool like ARIA that could really change your app, do we have a responsibility to make some better choices and actually use things like real buttons or just better code in general? My vote is yes, but you'll find that out in the next little while. The other thing that people are asking quite a lot about these days is stuff about detecting assistive technology. And I want to know, and as a developer you probably want to know, all morning, I'd really like to know, is this HTTP-1, is it HTTP-2, is it whatever? Do we have the capability to know? And my question to you is, if you could detect a screen reader, what would you even do with that information? And there's some real slippery slopes that we go down when we do that kind of stuff and say, I'll give you one example and then I'll shut up. If we use a screen reader, if we detect a screen reader, we might inject a whole bunch of extra hidden headings that give some extra context to a screen reader user, which is kind of a neat idea. I think there's some merit to that, but we have to remember that the only people that use screen readers aren't just blind. There's all kinds of people that use screen readers for literacy reasons. And what's the impact on them? If they have a learning difficulty, if you're having a screen reader read hidden headings that they can't see on the page. So we need to think bigger. We'll address a lot of those kinds of questions and more during the panel. Thank you. Splendid. So we're back to bed components instead of web components. Not bad. So we have a lot of experts here. We have seven questions that we cut down on. I'm supposed to get these questions on some list here, but that's not showing up at the moment. What's going on there? Oh, it's a tablet. Look at that wonderful touch interface and really small and not resizable. Okay, so the first question that we have was supposed by Andrew Betz, but he doesn't want to do it. So Melanie Lange. What are the main offenders of modern websites in terms of accessibility and what can be done to fix that? So the question is like in many cases as web developers we do things that look beautiful and it's a barrier for accessibility without us even knowing it. So I think we're going to send that off to Matthew. So Matthew, what have you seen in your day-to-day browsing that drives you nuts although people think it's amazing? There's a few things. I'm sure that there's going to be many examples from the rest of the panel, but I suppose a personal bug barrier for me is disabling pinch to zoom on mobile sites because that just renders them completely useless to me personally. I'm vision impaired. I can see well enough to use the device but only if I've got control over the size of things on it. So that's a personal one. I think something to bear in mind is that somebody that's using an assistive technology to browse a website, say for example a screen reader but it isn't limited to just a screen reader, they can only perceive one element at a time. So they go through the whole thing, one element by the next element until they get to the end. And a lot of stuff in accessibility is providing information such that the assistive technology can help the user get to the bit of a page they want to get to as quickly as possible. So a lot of stuff is about saving the user time and making sure that the structure of the page is conveyed, the semantics are conveyed so that the user saves time and can get to the bit they need. Things like lack of skip links, lack of headings. Visually you can see the layout beautifully but there's just no semantic information or no structural information there. That's very frustrating because it might actually be with a trend on modern sites is towards things like simpler language, fewer words on the page, more focused. It could be really good but sometimes people forget the basics which is just make sure that you use HTML headings and lists and stuff like that, aria, if necessary, excuse me, and native controls where possible. So things that save people time. And there was also an article I read recently about things that just have to go away. Things like when you're asked to enter a credit card number and you're asked what type of credit card is it and please remember to put the dashes in or don't put dashes in or put spaces in telling the user to do this stuff. Okay, for all of us, that's really annoying. It shouldn't be necessary. It's just a number. But for accessibility, people facing extra accessibility barriers, that sort of stuff, having to go back and correct it because the instructions weren't necessarily there or correct, that can really take a lot of time and it's very frustrating. So it's going back to using sensible HTML, building things the way they used to work. I remember when browsers were bad, you had to use the right HTML or otherwise they wouldn't show up because there was no CSS to a degree. We then used tables for different weird things, but that's a different story. So Alice, the shockingly innovative way of using buttons instead of diffs with on-click handers, do you have to fight for these kind of things? Is there a way that developers are actually assuming that things work in the browser because the browser fixes it for them to make things accessible? If you're using standard widgets, by and large it should be accessible. One of the big problems we see is that people just simply aren't using the standard widgets. I'd very much like to understand why my hypothesis is that you can't style them the way you want. So two problems. One, you can't style them the way you want or they don't behave the way you want. One thing I would like to see is making it easier to style custom elements the way that we want to because it's quite difficult today. It's a very simple problem to solve, I think. Secondly, make it easier for developers to actually apply that ARIA metadata semantic information. How can we get that on the golden path that we've been talking about today or the pit of success? How can we make that easier for developers? I think that Web Components possibly has a big role to play here and I know that the team is working on that. Another idea would be to put it into the developer tools that we're all using. So how can we expose the accessibility information such that it's impossible to ignore? So wouldn't it be better to make it harder to put ARIA on stuff? How do you mean? Well, ARIA is a great solution for screen readers but it's not right now for Dragon and I know in good conscience that I won't... We don't use ARIA unless we know that it's going to get really good support and that we look for other ways to do things when we're building things. I almost would like to make it better to just use a button rather than to add roll equals button or something. Yeah, I completely agree. We're coming back to ARIA in an extra question later on and I agree it's a tricky thing to actually turn something into something that it isn't when there is something that is already something but that's a different story. Andrew, what do you see as crimes that are happening that actually make things inaccessible on mobile devices when you people use HTML? For example, that the unsightly select box that people hated on the desktop and always wanted to style is awesome on mobile devices? Yeah. I think on mobile, I think Matthew's already covered it. The biggest one is disabling pinch to zoom. I've had so many users come to me with that problem. I'm asking, why does my pinch to zoom not work on this website? And it comes down to the way we're using the meta viewport tag and we're all using it to kind of get rid of the 300 millisecond delay, which I guess in the past my advice would be to developers think about how you use that. But I guess now going forward, I'm thinking, should people like myself be getting more involved with browser vendors to say, okay, developers are doing this? Is there a way that we can kind of cater for both scenarios rather than say to developers, don't do that? Is there a way that we can kind of get this fixed through bugs with the browsers basically? So that's probably the biggest one. I think on desktop, the best bit of advice I could give to you guys would be try using the things you build with a keyboard only. So just recently I was working with someone who was having a huge problem with their online banking where they couldn't complete a payment to somebody because it was using an overlay. And whoever had built that had clearly thought about the interaction with the mouse. Things behind the overlay were disabled. You couldn't click on them. Their interaction was going wildly wrong. And if the developer had thought, okay, maybe why someone's not using a mouse, they probably would have come up, found that problem quite quickly and could have done something about it. I'm very excited that Jake Archibald has a question but we have to move on to the next topic. So Ross Green has a question for us. You're not Ross Green. I'm not Ross Green, but Ross Green is not attending. So he has asked me to ask the question. And I've also got to answer it because I've got a microphone. Accessibility expectations and requirements are vastly different depending on the user's world region. What more could be done to align them? Example, most EU rules say don't auto play media. However, most US media will auto play. The answer is don't auto play media. And a slight snark is, well, EU rules could be more widely promulgated if the EU government websites actually obeyed their own rules. Okay. But anyway, what could be done to align the different territories' regulations about accessibility? So the good news is that this was hard to understand. The question is basically, there's twofold to that. There's differences between accessibility guidelines in Europe and in America. You have to, for example, when you do government websites, when you do very much basic, any website that faces a lot of audience, you have to apply with them. You have to basically apply the rules and are different from Europe to America. As this worldwide web of us is worldwide kind of confusing to which ones to follow. So are there ways to actually get the legal requirements more aligned with each other? So maybe Sarah, you could tell us something about that. The thing I find interesting about this question is it refers to geography, which I think is really important. Obviously, we know devices vary, our tools vary, and so forth, but also it's worth understanding and thinking about how disability varies globally and internationally. So we've already heard a little bit about, say, the nature of disability and how we might want to conceptualize it, but it's worth also, I think, recognizing that disability means different things in different parts of the world and levels and types of disability vary depending on where you are by locale, region, as well as by nation. So personally, I think there's a bit of attention in terms of picking a standard to apply in all situations. I think the great thing about WCAG is that it's a guideline, and when it's applied as a guideline, perhaps for more of that indigenous reflection, the expertise of local developers to come into play as well. So they can account maybe for an indigenous population with lower literacy levels, or perhaps who have less assistive technologies. At the moment, there's not a great deal of data globally in terms of the kinds of technologies that disabled people are using, but obviously WCAG in particular is being picked up because the UN Convention on the Rights of Persons with Disabilities is being taken up by more and more countries, and people have this kind of policy vacuum in terms of information and communication technologies that are referred to in the UN Convention, and people want to make sure their policy is picking that up. So WCAG is being applied more and more as the kind of verbatim standard, but I think there is a bit of attention in terms of knowing what that means, say, in Nepal or Uganda or, you know, more regionally. It is kind of confusing because, I mean, being an ex-German developer and now living here, there's different guidelines, even in Europe from country to country. So maybe, in point of the RNIB, I guess you work with a lot of people that come to you and say, like, I don't want to be sued. What can I do for people with disabilities? Which is the awful, awful question we keep getting. Yeah. What is your answer to that? How do you get people to understand that just applying with the law does not necessarily make an accessible interface? Um, so I think there is a... For me, there is a business case behind accessibility, which we're all often talking to companies about around, you know, some potential SEO benefits, potentially opening up to new markets. And I think when I first got into that sector, or this sector, sorry, I kind of really did believe in that business case. And I still do. But at the same time, it's a little bit theoretical because we don't have many cases to back it up. So Derek's point about what if we could detect a screen reader? I think I'm with you, Derek. I don't think it's a good idea to detect a screen reader if you're going to do something with that information in terms of the website. But I'd really like that feature as part of analytics so that, you know, we can say, okay, we made some changes to the website, and we can now see perhaps, you know, screen readers are not dropping out midway through, you know, the process of checking out or something like that. So I'd really like that kind of stuff because we don't have many good case studies. So whilst we can say, yeah, maybe you can get more visitors, we don't have any figures really to back that up. Yeah. Derek, you used to work on that for a long time as well, like back in what's days and things with, like, I mean, we had guidelines that said you have to have a certain kind of access key on the page, for example. Is that possible or usable really? Yeah, there's a lot of things in, you know, you have to remember that, especially when you talk about guidelines, accessibility guidelines, and then talk about giving them the force of legislation. You're taking something that is designed to be necessarily fuzzy and putting it into something that becomes absolute black and white. And I would even respond to Bruce and say, you know, we all said, you know, everybody laughed and said, well, the simple answer is do not autoplay. I'm saying that autoplay can actually be useful for certain types of people, including people that have mobility difficulties. It may be actually much easier for them if you do autoplay so that when you go to a new video page, it actually does play for them. They don't have to try and work hard to actually get it to play. So when we're putting, you know, embedding a YouTube video or a whatever video on a site of ours, we always recommend have it embedded and don't autoplay that one, because it's on a page outside. Because then the user has the preference to set it up so that my videos on YouTube always autoplay. So we're kind of catering for both things there. So the, you know, the edicts like Do Not Autoplay, they sound really good, but they don't necessarily always make sense. Autoplay is bad for everyone except for the people that need it. Okay, we have a question from Christopher Emery. I just wanted to kind of talk to you. So the difference between the EU and US law, I just wanted to kind of, just with the cost of my experience, I found that it's actually even more complicated because the requirement of success, we don't just live in the government legislator, like for example when you get to a client who reaches the level where they're now rolling out in difficult markets, they will then have their own accessibility requirements there within that, which typically will be based on one market, even though they're running out locally. I mean that's my experience, even though they're running out globally. So we've actually encountered situations whereby we're using like the EU accessibility guidelines even though we're rolling out in the UAE or in China and things like that. And that becomes a very weird, strange situation because the document a lot of times that the accessibility was kind of created at the company's end was to take off the box to say, well yes we have accessibility guidelines, but they didn't roll it out to the market level. So I just wanted to say it's on top of the government legislator there's the actual corporate layer as well. It's a super tricky all in all problem and the issue is a lot of people try to sell accessibility as something you could be sued if you don't do it right but then we don't have to answer how to do it right. It's like getting someone's attention by kicking them in the shins, like, yeah you have their attention but not their support. So Shane Hudson has a question for us on this not kicking but general. He's there, the man in the striped shirt. So are the workag guidelines redundant in a world of smart phones and tablets are accessibility laws trying to fix an outlet as well? Yeah, kind of. So basically the question is the WCAG guidelines define a lot of stuff for example keyboard accessibility which is on a touch device a bit of a weird thing to enforce. So do they need to be upgraded? Do we need to think about different form factors? I think the best would be just what do you think? I think this is a problem with the nature of standards and there's quite a lot of interesting writing about what standards do outside of development communities. So for example they offer a fixed perspective which is what I think some of us are struggling with in the sense that disability is so heterogenic that it needs to be as inclusive as possible and a standard rather than a guideline is difficult. So there are these problems about how it keeps abreast of new developments which we can't necessarily foresee. But I think one of the things which I find interesting is that standards also convey certain values and as I say when they're being picked up internationally it's useful to recognize that they also promote the rights of people with disabilities and they promote their access to technology and raise a kind of whole argument about human rights, disability rights which isn't necessarily reflected in all the communities that these standards touch upon. So that's one of the things I think which we need to also keep front and centre. Matthew, in terms of gaming I mean the Parchiello group does a great job in explaining on their blog how to apply WCAG guidelines how to apply best technologies and most people start with a blank canvas with no keyboard accessibility whatsoever for their game. So do you think that the WCAG is outdated? Are we fixing the web from 997 rather than the web from 2005? A couple of things, first of all the gaming stuff is separate to my TPG stuff but I'm very happy to talk about it of course. Sarah made a really good point last night which I just wanted to make sure came up which is that a screen reader could be a person next to you reading what's on the screen in a particular place you were saying about different countries have different social views of accessibility and different access to ATs and therefore screen reader detection would have to encompass reading glasses and people sat next to you as well and both of these at the same time perhaps. Anyway moving on to answering the actual question . A couple of points one of them is that if you look at WCAG and there's a lot to read but the central points that it's trying to get across and the values that Sarah mentioned they're actually written down in there they are the poor principles that your content needs to be perceivable operable, understandable and robust and you can look up what those are but you get the general idea you can apply those kind of principles to any medium now some of the WCAG stuff might be less appropriate on mobile some of the very specific technical stuff but a lot of the guidelines in fact all of them are written with those four principles in mind and you can apply those to any medium so in terms of game accessibility that is about making sure that you know what information is important to someone to be able to play this game what is the best way to present it to the particular audience that you're thinking about in our case it was blind people so it was making a lot of visual cues, auditory instead understandable that well it's got to be understandable to be able to be enjoyable in the case of a game and in the case of a banking website it's got to be understandable in order to be able to use it and robust that covers the kind of security and reliability stuff on the website side of things and on the game side of things you don't want it to crash just before you're going to complete the level so very briefly that is you know a very glib high level trying to demonstrate you can apply these things to multiple areas so Alice when you put that into the developer tools accessibility panel I mean those of us who have been in accessibility long enough remember Bobby proved and people put like triple eight badges on their website which ironically didn't have an alternative text what are the testing tools that you have in there do you get like this doesn't apply with that guideline or is it more of a transcription of the perceivable and the ideas of it because it's easy for a developer to say like oh I'm now accessible because I take all the boxes but what does it really mean what kind of a test tool would help people there the accessibility developer tool is that passing mechanical accessibility audit does not in any way guarantee that you're completely accessible it's only looking at the things that we can test programmatically which is a subset that said what it does look at are things like color contrast it tries to look for click targets and suggest that you should use an aria role and keyboard handling it also looks for valid aria use it so those are sort of the main things that it's looking at but one point I did want to make just to follow on that the robust in perceivable understandable robust actually encapsulates working in different modalities which actually implies that it should work on different devices so when we're talking about mobile, tablet even something like Google glass or a TV or a leap robust encapsulates all of that good Matthew you had a question or you're pulling it she covered everything you do I just wanted to show that somebody from Google there was something to say about accessibility I was going to ask so I once made a comment about changing an outline in CSS and basically changing the background color for the focus I got slated immediately on Twitter for this it's not accessible with that and I'm kind of like well what is the right way to do it and it's a part of me that's like well can I apply filters to my site that says this is what a screen reader will see or like what should I be doing in my workflow that basically helps me as a developer make my site more accessible are there tools is there something to recommend or is it just a case of use native components use the accessibility thing and use that so Derek using 75% of all statistics are made up so you can get probably one of seven people know that you can get 80 to 90% of the way accessible by testing everything with a keyboard and you have to manually test that because that's interaction there's no way to test it other than that but dealing with like straight up good solid semantic markup that using just writing good HTML and not screwing up keyboard access gets you 80 to 90% of the way there straight up honest truth now the using it with the keyboard is going to show you stuff about your outline changes right you're going to go through and you're going to say shit I can't see the cursor I have no idea where I am I have to stop this cursing right now actually and we this is a longer topic that we could go on so I'm moving on to actually add Soden which is actually covering this a bit so at Soden has a question yeah Mr. Snowden was I not allowed to say so as developers we often try and make our sites work well for screen readers but is there anything else we can do besides screen readers when we're designing our sites to make them better for accessibility that is an incredibly interesting question that we haven't quite covered yet or just did or tried so Andrew what do you think the big screen reader debate every developer I talked to like it works with a screen reader because that's something I can test with what else should we be thinking about no it's a great question and I could make up some stats now but I'm not going to go ahead in the UK there's some around two million people that have some kind of sites related issue and the vast majority of those have some residual useful information so the thing you can take away from that is quite a small percentage of those two million people are using a screen reader the rest of them are making some kind of visual adaptations to the page and I think you can extrapolate that to around the world issues so think around the world it's something like 280 million people have some site related issue so things that you can do that are not related to a screen reader and this kind of applies to all of us using a website out and about colour contrast the size of your fonts how much white space is between controls so when you're using a screen magnifier I'll see sites sometimes where there's a form and maybe there's two buttons at the end next and previous they're really far apart from each other if someone's using a screen magnifier I think Matt kind of touched on this before it's a little bit different with a screen magnifier but you see a portion of the screen at any one time those of you that everyone pretty much has max here you'll all have a screen magnifier built in windows as well so you can try this out if you want another way to think about it is if you imagine sliding a credit card around your screen just imagine that was your viewport so if the buttons are far apart there's potential to miss them so just that kind of stuff is worth thinking about and that's nothing to do with screen readers at all that's a very good point I love the credit card thing my favorite is always when people now everything comes with screen readers which is great for accessibility for people but it also is kind of bad because developers think they know how these things work now the amount of people I see using a screen reader with their eyes open is amazing and that defeats the purpose because of course you can understand your system so James Ably has a question or was that already about the last topic yeah that was about the last topic okay good so do you have another one maybe they put gasoline on glasses and put gloves on to simulate a process yeah so maybe do we need to go back and just do that maybe it's going extra miles testing this kind of way works I mean I gave people broken mice to actually use the website for example with yeah there's tons of things that you can do like that to you know to simulate different types of disability and I believe that all of those things are great you know user you know emulating what a user with a particular type of disability would be you want to see what it's like for somebody that has a tremor in their hand to use a mouse turn your mouse sideways and try to manipulate it on the screen and you'll use the wrong hand there's all kinds of things that you can do one thing that I would point out and I think those are great things to do the WCAG guidelines specifically because we know and I say we like I was involved or something but we can't all go and test with real people and so those guidelines are all in place because they're based on years and years of people actually working with with people with disabilities so that those are if you like absolutely valuable and useful and everybody should do it but if you can't do that then you have guidelines as your point of advice and I absolutely go back to it but if you can't just feel at least partially confident that those guidelines are there to replace the fact that everybody can't do that I feel I completely understand where you're coming from but I also feel that's a bit of a cop out in terms of I think sometimes standards step in and people want to learn the standard because that's the easy thing to do and they want to turn their mouse sideways and do that when sometimes they have disabled populations sitting right under their nose so for example in the university sector there are hundreds of disabled students at King's College London how many are involved in testing our systems they're right there we could easily engage with them so I think it's important to be creative and think about drawing people into this conversation so if you're doing usability testing at large don't be afraid of contacting disabled people's organisations or putting a call out for people to get involved in testing your systems because they will give you much richer feedback about how your interfaces work and they're going to bring up things that you just would not have imagined possible it would be interesting to see what kind of I mean you can take the glasses away from your colleagues for example or you can read out your text on the screen to somebody on the phone if it then makes sense you know it's an accessible text if you need the thing to see to understand it then you don't like there's a lot of, it would be interesting to set up a wiki or something about these like little accessibility hacks to simulate different things but outreach to real people with real disabilities hardcore users that know how to use something is amazing, I mean I learned most working next to a PHP developer who was blind for like four years and that was just incredible because he coded faster than me which is annoying now with a sense of dread Patrick Lauke has a question I've got a question, I've got a lengthy statement now just a quick note I wanted to pick up just on something that was mentioned at the start there about, I did something to my outline and I was immediately jumped upon by an accessibility lynch mole the dirty kind of truth even within the Pacello group I can say that hopefully openly is that you get three accessibility experts you get five different opinions we disagree even on sometimes very fundamental things like very first online book hack you know having appropriate old text, we could have discussions for days about what is the most appropriate old text for this and you get fierce debates in the accessibility community about every image should have this kind of old or no image should have old so just wanted to kind of temper the whole when you get people jumping on you and immediately shouting oh that's not accessible they may be right or they might not be right and as Derek mentioned towards the start is that it is not a binary thing it's not always it's either accessible or inaccessible there's certainly things that you can do that completely screw everybody over that can't see the screen perfectly but beyond that there's lots of shades of grey on that one also stop arguing on twitter 140 characters are not good to actually bring emotions or facts in we've got Nikio Verma here because Christopher has said too many things already so basically I did a bit of a start check and I checked that there are about 2.7 million people in Britain who have colour blindness and haven't seen that mentioned in this talk yet do we consider people who are colour blind to be stable or are there any things that people generally can do to improve their pages to prove that they look so colour blind? I met a few unstable colour blind people in my past I think your tools Alice I mean you said you talked about the colour distance but also colour blindness as one of these simulators in there isn't it? No not in my tool actually Well that can be fixed Sure you want to ask me about that There are extensions certainly for Chrome probably for other browsers as well which will simulate colour blindness and contrast ratio has a colour blindness implication in that you can say if you have red on white if you view that as great it may not be high enough contrast ratio Derek you were twitching? A little There's a great tool colour oracle which you can install at the desktop level and it will transform everything and you can simulate things it doesn't two challenges with colour blindness and I'm saying this in a very blanket statement so there's probably more challenges with colour contrast issues the other is the way that you're using colour to convey information if you're relying on colour then you need to we're not saying don't rely on colour use colour as much as you want but use other mechanisms to indicate things as well so it could be that you're using pattern with colour or instead of just using colour think of a line graph that has a legend at the bottom each one of the individual legend pieces actually up beside the line so that you can then follow the line it also ties into internationalisation, my favourite is when people just use red as a warning whereas in China it meets good luck good luck we lost all your emails wonderful lots of questions let's have one here the man in the loud shirt sorry about my shirt I was just thinking we've talked a lot today about web performance and things like that how does the whole performance piece fit into accessibility we'll see why I'm kind of coming to mind there's things being too fast where we're constantly working to speed things up you know is there cases in accessibility where we actually need to slow it down so there was a few of I had a few thoughts when listening to all the other performance things and one of the things that I heard was what's in the first 15 kilobytes I started to think what should be in the first 15 kilobytes for somebody that has a particular type of disability and I don't know the answer to that question I think it's a great one I'm not sure about slowing things down most technology most screen reading technology and other technologies they work on top of browsers they're not their own thing generally speaking so I'm thinking where I'm kind of coming from is about the thought of perception if something changes on the screen too quickly it becomes harder for visually impaired people to actually detect that change you know so are you talking about in response to some event that's happened on the page or like an initial load is it more like UX problems isn't it I think like drop down menu just a case of stuff changing either naturally in a carousel which is kind of automated or in response to an action so on a carousel for example we always you have to have if it auto plays you have to be able to turn it off and you have to be able to start it up again so I'm not sure that that's really slowing it down from a performance perspective but you should definitely allow for somebody to manually go through the carousel if you have to have one on your on your page we also do things like if the carousel container when you detect keyboard usage within that container we automatically stop stop it from rotating so that it immediately becomes a manual thing if you're moving through it with the keyboard so that you basically take a screen reader that's on that on that content if it suddenly whisked away quite often what happens that you know if the node is just slidden nice word if the node slides out out to the side that's different than if the node is destroyed and in some of these cases screen reader focus is lost and they have to start at the start over at the top of the page so that's something where we want to kind of give them a little bit more control we are running the danger here getting into implementations and explaining you how to do a certain widget and we are all open to discussion for that it would be wonderful to ask get a few questions sorted and then we can answer offline because right here now it would be like do it like this or do it like that to answer the broader question about timing there there is language in WCAG about how long things should take how much time you should allow for things so that maybe gets a bit more at your question and also to me raises a bit of a broader question which is I'm curious how many web developers have even looked at WCAG to quite a few to me it seems like it's a great set of guidelines for creating good user interfaces so for example things like allowing error correction in forms do we not all want the form to lose all of our data if we make a single mistake so yeah I think the web would be better for everybody if we all followed WCAG and this is an example of something which is in there which we could learn about just from reading the guidelines and of course there's more there's stuff that's not in there or there's stuff that needs more information but it's a really great place to start okay we're running out of time here a bit so we're skipping one of the questions that I've seeded sadly enough we have one from Aurelia Moser here I skipped that apple quiz you can deal with it so I'm wondering how do you prioritize accessibility in your workflow and right now it seems that reactive is something you need to do when we make it just the thing to do it's the old question of like where's the accessibility plugin that I can put at the end of my workflow how do you get accessibility into the workflow from the very beginning in a cutthroat environment that has not much time Derek it's got to be moved earlier in the process if it gets to the end and you're finding accessibility issues for the first time in QA or as you're preparing it for QA it's too late it has to be done at the design level we focus very loosely on design development in QA as kind of three important pieces not thinking about the business side that's important but the focusing on the transition points I think is critical so having designers talk with developers and specking things out not like as in the spec but here's what my intent is with this design and so that a design can specify things like here's how the keyboard flow should work for this particular widget or for this page even working on it together here's the most logical source order looking at this wireframe and the hierarchy of content here's the most logical source order for that and having that stuff passed all the way down the chain is to me is one of the most critical things that would help address that so that it happens earlier and we don't get to the end and say it Andrew what do you think this is someone else's point of view I can't remember whose article it was but we were talking about how the first time you do something it is difficult and it takes you longer to do it so if you guys can remember the first time you built a website it was probably hard and it took you a long time the first time you built a responsive site it would have been your mind might have been a bit blowing like this is taking me a long time but then the next time you do it it's easier, the next time you do it again it's easier and then it just becomes normal because of the accessibility it only seems hard because it's not something you'll do day to day but if you do invest a bit of time and effort into doing it a couple of times your workflow will change and it just will become something you do naturally I can't remember whose opinion that was but I really liked it and I read it I completely agree with that and I completely agree with various things that have been said before like for example just try it out with a keyboard as you're doing it I've pointed out do it from the very start from the design process but you're all going to be dealing with stuff that already exists and there are some things I think Alice mentioned accessibility testing you can't do it all mechanically but some of it you can and perhaps this is going to sound odd coming from me because I'm very much reliant on me going to look at a site and finding accessibility problems with it but there are a whole range of things that you can test mechanically for example does every image have an alt attribute it's a very simple thing now one of my colleagues is working on or has developed a tool an API in fact it's going to be in beta soon it's called Tenon which can perform these tests that can be automated and it will go away and perform them you can make it part of your build process so if there were two biggest things I would say is perhaps look at that see what it can do for you because it can be part of your build process a human being does not need to waste their time on some of this stuff and the other thing is make sure that you can challenge yourself to like Christian said take away the mouse for a while and see if you can still use your site some stuff like that you can really reduce the amount of time and effort it takes by making it part of your process and as much as possible please do try and consider it from the design stage from the absolute get go and then there's the other sorts of advice that you've heard just generally sprinkled through about testing things with a keyboard and stuff like that I'd like to just interject a little bit of sociology because I know part of the issue is that it has to be a team effort across your entire team and it has to have accessibility more than others and I think it's trying to position accessibility as part of a norm which is understanding that disabled people aren't an out group they're part of your in group so at the moment there's a term aversive disabilism so most people believe they're quite liberal they don't discriminate against disabled people but if you're designing for your group and that group doesn't include disabled people disabilist judgments because you're still excluding the outputs are still the same so in that sense it's important to sort of expand our concept of who a normal user is to include disabled people of who we know okay we have to wrap up so I have to thank the panel and I'm incredibly excited about all of your interest because having worked in accessibility and having to shout at people for years to consider accessibility it's great that there is a new way there of partnering that we have to remind people about something there seems to be a communication gap between the accessibility evangelists and the developers out there and a lot of things can be repeated that have been said a few times so I'm really happy about this so take this idea take this enthusiasm about it out there and pester as many people as possible who know about accessibility and if you get grumpy answers as Patrick said thank you so much again