 Hello, I'm going to talk about how we made FutureLearn more accessible. Hi, I'm Nicky. I'm going to introduce FutureLearn very quickly and then talk a little bit about accessibility generally and then do a kind of really deep dive into some detail of the specific problem that we were having recently and how we're going to fix it. It takes about 15 minutes. So what is FutureLearn? Oh no, the flicker. This is terrible. How do I make it stop? We don't know why this is, but if you have white edge-to-edge feels like a lamp. Good. OK, well, let's see how we're going. Anyway, some of them are different colours. It'll be fine. FutureLearn is an online social learning platform which means that we do online courses with content partners by universities and cultural institutions like the British Library and the BBC online through our responsive website, as you can see here. So what we mean when we talk about accessibility, you can see this, this is actually our mission statement. I kind of have to roll my eyes a little bit when I say that because I hate those words, but that's what it is. The best learning experience is for everyone anywhere. So what we think about when we talk about accessibility in that context is not just screen readers, if you've heard of those, not just screen magnifiers or people who just use the keyboard or people who just use the mouse. The reality is that everybody is out there, they have different eyes and different brains and different fingers and they use computers in all different ways and all of those people have to be able to do that. Everyone, anywhere. So how do we do it? You might have heard of organisations like the W3C and the WAI and WebAIM. These organisations very kindly think hard about these sort of issues and set up guidelines that we can just follow. It sounds really simple when you say it like that, but anyway, I'm going to go through a couple of them, not all of them because there's lots. Keyboard navigable. Obviously this is, well, I think everybody in this room, the power users probably understand why this might be important, but not just for power users, but for people like my mum who has or gets arthritis and sometimes doesn't have a great range of movement in her arms or a colleague nearly broke his arm at the weekend and now can't move and is having trouble with that, which kind of introduced to me this idea of a temporal disability. It might not just be that there's something, you know, providing tax alternatives. Again, the kind of obvious one that you think of is like, oh, screen readers, we've got to do this because screen readers can't understand images, and that's kind of true, although I think people like Google are having a really good go at that. But again, and specifically thinking about future learn, not everybody learns really well through video or just pictures, so things like transcripts and subtitles on the videos are super important. Using more than just colour, and this is where we kind of start shading into the crossover between accessibility and just kind of interaction principles and good design, I think, I choose to call it that. So yes, obviously people who are colour blind are going to have trouble differentiating if you don't use the right colours, but people with all kinds of low vision will have this similar sort of problem, and also I found out while researching this stuff that there's a horrible thing that happens as you age. The shades of blue that you can see become less, like they all kind of merge, and I was just like, good thing that I like pink. And again, obvious, this is good for everybody. You need to make sure things are clear and simple so that you can find the information quickly when you need it, not just because you have a learning dyslexia or something like that, but you might just have a headache or a cold or be stressed. And similarly, again, the last one, the obvious, so this is more about getting information in a timely fashion if you're in a hurry. So yes, this kind of stuff is good for everybody because sorry to be depressing, but we all get old and we all have accidents. Again, another sort of factoid when I was researching this was something about one in three people over the course of their lives will have a period of what would be termed disability lasting up to months or years, which is kind of frankly terrifying. Not that I want to put the fear of God into you, but yeah. So these are kind of also, I picked these specific ones because I think they're kind of the easy ones that everyone's heard of and hopefully are doing in their sort of daily jobs. I think that you will probably be familiar with these sort of guidelines. And obviously some of them are going to come out of the colour and the language conversations with other people on the teams that we're using to build this stuff. So I think something that's really important to have in your head when you're having those conversations is kind of looking at this list of dusty, dry things that I've got to do to make it accessible and get stuck in this mindset of, well, if I do these things or if I do just these things, my site will be accessible, but it will be really boring or it won't be very interesting visually or engaging or interactive. And I don't think those things are true. You can have both. They're not mutually exclusive goals. So, yeah, this was the specific problem that we were having on the site that we needed to fix. It was a bug. Bearing all of the previous points in mind, we wanted to fix a problem with our like button, which is this tiny thing down in here that I realise now that no one can see because I thought there'd be another screen. Yeah, so if you're zooming on in, when the problem that the bug that was there was when we hit like, we can see that the colour changed. Oh, God. But we know that's not enough, so we can't use just colour, so we also update the like count, so we show visually that something's going on. So we think, oh, great, we've given some feedback. Unfortunately, as it stands, this is not enough. The markup that we were using made sure that it wasn't keyboard accessible and it wasn't screen reader accessible. So this is the same thing again, but as if it wasn't just a visual, but the screen reader was reading it out. So if you haven't used one, a screen reader, it's just an app that sits on top of the browser. It's not the browser itself, and it can read any text that's on the screen, not just websites, but any other things that it happens to be on the computer. So you can see here, it says like one, and when we hit it, crickets. So rubbish, we've got to fix this. So yeah, and the way that we do this, we're a rail shop, so the whole partial just kind of gets spat back out, and that was the cause of one of the first problems that we had with the, it wasn't keyboard accessible, as we will see. So this was, yeah, the problem we were having, the like button, you can see it visually, but you can't hear what's going on. So this is one of our pages on the site. This is what a content step looks like. So over here on this, you have some learning and a video or an article, something that you're going to, information that you're going to take in, and then on the other side, you can talk about it with your fellow learners on the course. This is kind of why we felt that this was a problem that we needed to fix specifically, not just because we want to make these things accessible to everybody, but liking is kind of an important part of the interaction between people. We want to make people feel so good that when, you know, when they've been on Facebook and they get a lot of likes, so this is why. So how do we do it? We use a tiny bit of JavaScript, ARIA roles, which we'll come on to later, and CSS. I presume you've heard of JavaScript and just CSS. But anyway. ARIA stands for Accessible Rich Internet Applications, and it's just some attributes that you add to your markup that other applications can read and understand. So we'll come back to that. So the JavaScript first. Yeah. This is where the JavaScript comes in, obviously. We mean JavaScript focus. You don't need jQuery. I just couldn't fit anything else on the slide. It's super simple. It sounds really kind of like, oh, God, really? Yeah, it is really simple, but that's good. Because we replaced that whole div, remember, now the DOM is like, hey, I don't even know where my focus is supposed to be. In our case, then, as part of that response, we focus back on the like. We actually go right back to the specific like button, I think, because that's where your focus was when we kind of interrupted you. So this will fix the first problem for people using the keyboard. Yeah. So what happens if you don't? I have a video that's white. Brilliant. So yeah, you can see we have focus. Not very well, because it's flickery, but that's how we're indicating our focus. This is keyboard navigation only, so you shouldn't see a mouse pointer anywhere, but let's just see what happens, anything. So we've hit like, we've lost our focus, and I think I'm going to try and tab now to go to the next thing, and I'm miles away from where I wanted to be. I'm not actually using the skip-nav in this, because I wanted to show how painful it can be. Yeah, so eventually we get back to where we were, but it's kind of a pain. I think that comments threads can be like thousands and thousands and thousands of comments long, so it's very painful. So don't lose focus. I know it sounds really simple. One of the things I really liked about this was that it felt a bit weird at first, because there are so many sites that you see those horrible spammy ones where they kind of hijack your cursor or your key press or whatever. I thought, God, I don't want to be one of those people, but I think actually this is the right time to use this kind of tip. So aria rolls accessible rich internet applications, special attributes that you put on your HTML tags. You don't need to install anything on the server or the client to use them. They're just there, they're part of the spec. They should work as far as part of the spec goes, as we'll see. So browser support in terms of, yeah, kind of Android was a bit shaky, but it's much better now. It doesn't really tell the full story, can I use? Because obviously there's lots of different types of accessible technology and devices that are reading the aria attributes and these aren't all on that list. They don't all work in everything, surprisingly. But like CSS rules, the browsers or whatever would just kind of skip over anything they don't understand. So it's quite safe to use anything. If it doesn't work in one particular device, for another one, that's fine. Aria Live is the one that we're particularly interested in today. There are lots of others, but this one is the one that we want to use right now. And this is what it does. This is exactly what we want. We've just changed something on the page and updated something and now we want that update to be read out. Yeah, so the way I think of it is you put the aria live attribute on the tag and then it kind of registers itself with it and listens to it and all of the nested content within it as well. And if anything changes all the way down that tree, it kind of puts its hand up and says, I've changed, you can listen to me now, something. So it's great for giving feedback. It has, yeah, can take three values, polite, off polite and assertive. We use polite because it means don't interrupt. So if the person has started carrying on doing something else like reading the rest of the comments, then it will do that until they've finished and then pop up and say, so it just doesn't interrupt, which is really nice. When I was researching this as well, I found a weird, I think, I'm not sure if this is really true, a screencast from about 2011, which seemed to imply that the assertive value before it was that used to be called rude, so you would be polite or rude, which I kind of feel like, hmm, good thing they changed it. So, yeah, this is the result of all of that flickering. One like. Now, two like. So we've put our Aria live role on there and you can see, ah, cool, okay, we've got some text being read out, but you can see immediately there's a mismatch between the markup, between, yeah, it's not a sentence. So this means we're going to have to use some CSS to hide some content from the screen to show only some content to different screen readers. I'm looking kind of shifty at this point because I know it's not really the best thing to do. This is the kind of hack part of the, we were feeling really good earlier because we used the right tool for the right job and now maybe not so much, this is the kind of work around. Yeah, so this is what we did. Yeah, so this is kind of nearly what we ended up with. You'll notice at this point we had to switch the source order as well to make it match the visual. We've got a new ARIA role of ARIA hidden, so that will say to assistive technology, don't listen to me, I'm not interesting. So that's the thing that is displayed visually and then there is visually hidden utility class just to, of screen. And then we can go mad in our visually hidden content area and kind of tell people a little bit more context about what's actually happening, so that's nice. And then finally, if you tried with a screen reader, this is what it would say, and this kind of makes a bit more sense, I think, as a sentence. So that's kind of it. We used a tiny bit of JavaScript, reset the focus, make sure that people don't get taken out of the flow. A few ARIA roles to make sure the feedback gets announced at the right time and other content is available and then the CSS just to hide things. Question time. Oh, and confession time first. And I have a question for you. I've actually never used Ember, so, yeah. But I wondered if there's anything that you pick out immediately of the framework or that could be in the framework that would help this kind of problem or help us solve it. So that's why you think about that. I can answer your questions maybe if you have any. Hello. I'm imagining that the focus is because you're replacing the whole thing. Yes. You've done that the other round, you've just done the element. Yeah, so I'm imagining if it was just a link, then that would be fine. You'd still have to swap the whole div anyway to get the nice two likes you like to this. So in that sense, to make the like button more accessible to readers, you have to replace the div to manipulate all the content. Yes. That's right. How do you manage testing this? So what can you imagine that's the kind of thing that you can come along, do a... It's the problem once, and then in the future someone else comes and adjusts the mark-up because they've got a new design or something. Is there anything that you can... Do you have... What would you suggest organisations do to continue to make sure that you don't get re-questions? It just happens. I can tell you exactly what we do, which is that we write the mark-up and describe why we're writing it that way and then the next person who comes along will know why we did that, I guess. And we have tests so that stuff fails as well, obviously. It's a Rails app in case... Sorry, I didn't show that. So there's lots of specs all over the place for that kind of thing. And manual testing as well. Not every time with screen readers. But yeah, lots of testing in various forms. Is there anywhere specifying a test on what a screen reader should say? Ooh! Well, it will read the content of the element of the mark-up. So, yes, by having the content there, I guess. You take one element or not the other. But you can just say, load this page and then expect screen reader to say, do you like this at that sort of level? I don't know. I'm not aware of screen reader simulations for things like aspect or Jasmine or anything like that. It would be good. But at the moment we just check that the right content is in the right place. Yeah, these are some really good more links, by the way, and stuff that was super useful when I was making it. The examples of different times that having those kind of principles would be this A to Z, it's A to Z of accessibility, which I kind of stole a lot of the examples for. I made all of those up. Hello, Jamie. Are there any bits of the new one that we had to completely rethink it for the screen reader? This one, yes. It's on our list, yeah. Iterative, yeah. I think next time when we come back to this, we'll be thinking a bit more clearly about it up front. So, you had to... I was just going to say, I think everyone probably likes the accessibility and often they're probably not. But I definitely do not know enough about the different types of accessibility. So, you know you mentioned how everyone at some point in their life will have some disability or something like that for a short period of time. Is there a resource or did you stumble across something which had a load of use cases that might change your mind about how to do things on the accessibility? That's this one. The A to Z, A to Z, yeah. That's just like, oh, can you thought about this? Yeah, it's literally an alphabet, like 26. Yeah, and it kind of changed my view on it as well. Because I think that's probably the takeaway that I get is that the way that I put it together, I go, and there's a screen reader at some point. Whereas in actual fact, even changing the language is a good... I've never think about it. There's a whole bunch of stuff going on there, you know. Hello. The question is not technology, but it's more about the business case justification. These sort of accessibility features, as you point out, are important. They may not be my first one to race out there and start off to build these things in. But how did you justify the cost that comes with it? Is there any sort of guideline in terms of who needs to do this sooner rather than later? I guess everybody, really. I mean, going back to those kind of... The last few points on the pink slides are things like clear design that's up front for everybody. Clear, simple descriptions and instructions. Where are learning sites? Are things like subtitles for the videos and transcripts and stuff like that? We really just have to have... Just because not because we have to be accessible, but because we're missing half of the people who don't like watching videos. Or who can't watch videos at work because... Well, let me ask you the difference. Are there any actually legal requirements that you have to do in the future? Yeah, I believe so, yeah. You need to make your sites accessible. However, there's a clause that says you have to do it reasonably accessible in terms of not making bank drums in the process of doing it. So you have to actually work towards making things accessible. Most banks and financial institutions or public bodies are required legally to at least hit a minimum of accessibility requirements for which my company works and not pay it over. But there is legal requirements so it's worth thinking about it as well. Because if you do become successful, you need to have a strategy that you can either roll out quite quickly or have at least put some space and stuff in initially. Just one comment with your like button. So I think sometimes we try to solve problems using technology when sometimes it could be when you click a button that says you liked it. And I think sometimes it's also thinking about it in a way that accessibility is considering things beyond a technical solution but a perception thing. So I am quite busy and I have the mind of a goldfish and forget what I've done. It's all beyond Facebook and it's similar to common. Because I'm supposed to be working and they interrupt me on Facebook because it's more important to be on Facebook. And then I'll be like, why is it that I like this? And so it's even like the language clues and the sorts of things that you can do that are even quite simple and not necessarily technical. It's worth talking to people like copyrighters and other sorts of people like that as well because they will think about things that you ask your world technology will never consider. It's like I have a technical solution for this. It's amazing the work and it could be something even simpler. It's an ongoing battle we have with that button. The questions we considered for this problem was just to get rid of the whole thing entirely and then the problem goes away, right? Especially because there's kind of concerns over cannibalising commenting because actually what we really want is conversation. So if you let somebody kind of be very lase, you know, not really interested in it. And yeah. One comment from the JavaScript framework world. Oh yeah. There's a project called React Accessibility. What that does is it lids your components as they arrive in the DOM and it will look out for certainly like obvious mistakes. Obviously it can't spot everything but it does stuff like if you've got a cannibal on a dip it will say to you, hey, do you want a roll button on this or should we just use a button for this and stuff like that and it will try and look out for bits of text which they can see will get angles and become monetisable to the screen reader and there's a port of that for Edinburgh as well. So this is a JavaScript framework so if you give the opportunity to do this kind of thing I'm sure you can do it but you can take the same approach with the scaling of the DOM like any linser, you can assemble a companion of common mistakes and this is what this does and it's issues with warnings into the JavaScript console so you would see them all better and your developers can go and she should ignore them. Could you put that into your build process do you think so it would fail? Is that something that ember contributors would consider moving into the core or would that be a framework? Reacts are not sure ember is enough for the community to be there Anyone else? In terms of the analytic side can you tell what sort of disabilities people have or accessibility issues Sorry, in an automated fashion I don't think so It's not like browser screen readers don't have user strings or anything like that Oh, maybe they do No they don't That's because screen reader manufacturers don't want to announce that their screen readers developers will give a sub-part experience to people if they know you're using screen reader That's one example of why it doesn't announce It takes the mystery shopper approach I think they're justified in this approach We've all been sent to a mobile website That's why that's why it's hard to get statistics We do have a weird thing in our team where each developer spends the day doing QA and tech support and on the days I've done tech support users emailing me the thing doesn't work and eventually we get down to the problem is that they're using a text-only browser I'm really interested and I want to talk to you more about it Probably bad use of QA time Can I ask who's used a screen reader For those who haven't you should really have a go I think they're incredible pieces of software and they use all other kinds of clues to tell you about what's going on and use the stereo field to tell you about where your cursor is on a particular page and all sorts of audio indicated to tell you what's going on and what you're interacting with It's true That's a funny fact I think we all should be concerned We are at least one of us some of us are TIA aid support and it turns out that there's more blind people than we are so so remove support for us or if you have to choose to support blind people because you have accessibility so that's the story That's quite All right, let's hear it Thank you