Ask the expert ep1, Accessibility – Transcription Benjamin Ellis: So I am joined by Steve, and I am super excited to be having this conversation today. Steve, introduce yourself if you can. Steve Green: Hi I'm Steve Green, Managing Director of test partners. We're an independent software testing company and these days, we specialise in accessibility testing, training, and consultancy. Benjamin Ellis: Brilliant and we've worked with yourselves for a little bit and you've definitely helped us up our game on accessibility by a huge margin, which we were very grateful for. For people who are new to accessibility? What does that mean? And then, if someone's not familiar with that term, particularly in the context we're talking about, surveys and web forms predominantly but also the digital domain, what does accessibility mean in that domain? Steve Green: Right there's probably any number of definitions out there, but essentially I think of it in terms of the ability of people to use a website or a mobile application regardless of any disability or access need that they have and that last phrase is important because not all access needs are the results of a disability. I know a lot of people would think accessibility, disability, but there's more to it than that. A lot of people who have access needs wouldn't regard themselves as being disabled at all. And so for instance, most dyslexic people don't think of themselves as having a disability if insofar as they think of it at all. They see themselves as just having a different type of ability and indeed, many of them perceive that they have an advantage over people who are not dyslexic because they think perhaps more creatively or differently. Obviously, people like Richard Branson being one of the examples of that. Also, anyone can find themselves temporarily disabled. So for instance, if you're using a touch screen device outside in the sunlight. You'll probably need a higher colour contrast level to read it than you would do indoors. Even though there's nothing wrong with your eyesight, something that's readable inside is less readable outside and then of course, there will be situations where perhaps you've got some sort of injury or something and can't use a mouse so perhaps you're having to use a keyboard to navigate. Again you wouldn't think of yourself as disabled but you have a temporary access need so that is how we think of it. Benjamin Ellis: That's great to have illustrations. I'm a dyslexic myself. I resonate with that, and I know that certain fonts and things can render something almost unreadable to me. Similarly, I've got a colleague who fell and broke one of their fingers and it's interesting how that changes things. You can't use the mouse in the same way, it kind of transforms how you use things and makes you realize that some things are not as easy as they could be. So, there's a broad range of scenarios there. If I'm thinking about a digital survey or digital web form, what are probably the most common accessibility challenges that I should be thinking about? Obviously we want to think about the broad range, but what are the most common things that users are likely to encounter? Steve Green: Right I'm not sure there's an answer to that one. Without doubt the noisiest user group are people with visual impairments. And so there may well be a perception that they are the largest group, but that may not actually be true. Certainly there are no real figures for that sort of thing. There are different issues, so, so some of the issues will be code related and just sort of under the hood because assistive technologies need to Hook-in in order to make the content accessible, and then there will be a whole load of issues relating to the visual appearance that effect potentially everyone. There are many tools that people use to help them. Uh, so ranging from there are built in ones. There are things in your operating system whether you're on windows or Mac or mobile. And there are built in screen readers, magnifiers, there's the ability, perhaps to change colour schemes to a high contrast scheme. So a lot of that is built in if you need it. Then there are three browser extensions that perform all sorts of different functions. And then there's a whole range of products going up to very expensive professional tools with the professional screen readers and magnifiers being around the best part of £1000, plus annual costs so that people could be using anything in that whole range. And now many people who are listening might have heard of screen readers and magnifiers, their quite commonly known, but there are also a lot more, especially in the education sector such as literacy tools that are aimed at people largely with dyslexia or learning difficulties and OCR applications that's optical character recognition and, so that people can convert non text content into something that's machine readable so it's absolutely vast range of tools out there. Benjamin Ellis: It's quite amazing how the technology has transformed in the last few decades. I remember using something called a Makaton board, it was like an alternative input device and it costs many, many thousands of pounds. Yeah, now a lot of websites, you can pick up your tablet and switch them into dark mode and get an alternative or high contrast theme like almost built in or you know, Android devices and Windows will do transcription for you and retext out. A lot of those tools now are just kind of baked in and available. In terms of that set of assistive technologies and tools. What are the particular ones that people should think about or be aware of? Because for most people they don't realize that those tools are there or if they've seen them, they don't realize that actually it's an assistive technology. And then, what does that mean for what I'm building when I'm building a survey? Steve Green: So if you're talking about developers to start with. They don't really need to know about all those things. Accessibility is enormous topic and so they should be starting with the simpler things like following the web content accessibility guidelines so that's the set of what they call success criteria that you meet them all, what you've built should be reasonably accessible. And it's perfectly possible to follow all those guidelines and the technical specifications without really understanding why. You just know that you have to mark up headings like this and mark up lists like that, and put these Aria attributes on these components. And as long as you follow the specification it should pretty much work. So, I would say the most important thing is to start learning all of that technical stuff. Then once you're happy with it. Then, perhaps go on and start learning about the screen readers. There are some open source free ones around like nvda. And by all means start to learn about those. But one of the mistakes developers make, is trying to make a screen reader sound a particular way because they think that someone who uses a screen reader is going to want to hear certain things and you shouldn't as a general rule design for how the screen reader behaves. You should be coding to standards. When you're really proficient at coding to standards. Then you can start to take account of the actual screen reader behaviour or whatever the system technology is. But you need to a lot more understanding than you would have at the beginning. One of the reasons for that is, if you take screen readers, there are about four major ones for Windows, Mac and mobile. And they all behave differently. And so if you code to standards. They should all work properly. If you try and code so that jaws sounds like you think it should. Who knows what the other ones are going to sound like and so you can actually make the user experience worse for a lot of the audience whilst trying to make it better for one small portion. Benjamin Ellis: Yeah, it's very interesting one of the things we've talked about internally and in building our mental frame for accessibility is having things work on the user's terms rather than on our terms and that means letting people adapt it to what they need to do to be able to get access to the thing. I was using a restaurant app. it was a four Mace thing. You could order from the table, which was a great bit of Technology. Unfortunately, they chosen a really very artistic font. For me it was very difficult to read, and they disabled the pinch to zoom that you get on tablets so I can’t zoom in on the font, so you know it was a frustrating experience. Because obviously a designer in that case said: “Well, we want it to look this way, and work this way” and taken away the ability for the users to adapt it. To actually what they wanted to do be in this case. Steve Green: Yeah, another thing to remember is you know the first time you use a screen reader? You will hear things that you're not expecting it to say uh for instance, jaws will say blank in between paragraphs and I've had developers writing to forums, saying how could I stop jaws from saying blank, and it's supposed to. If you did stop it, and there are ways to stop it, if you did, users would be very confused. Because, it's just doing on your website what it does on every other website that so people will be used to how their screen reader works on all the websites they visit so actually you want your website to be consistent with all the others rather than trying to force a particular user experience. Benjamin Ellis: Yeah, that's right. It's very interesting point actually is about seeing how other people have done it as well, I think. A lot of accessibility people tend to do work on their own, you have the great benefit of having a team with real depth of expertise there. Oftentimes people are trying to solve this problem on their own and there is that thing of having a look at what best practices out there and what other people have done and how they've solved some of the problems. Steve Green: Very much and so we participate in the wider accessibility, community a lot. There are a number of forums like web aim and the IAP, which is a professional accessibility organization. And so, although we're competing with all these other companies. We actually come together on these forums. And ask questions and give answers and share ideas, and share things we've found and uh that's absolutely invaluable now. You don't want to be sort of isolating yourself on your own. The communities very collaborative. Benjamin Ellis: There's a great community. In terms of people getting started and so that you know the thinking, particularly people who are in public consultations or doing public facing surveys. What are the most common mistakes that people make when they start to try and bake in accessibility and account for that in their designs. Steve Green: Right and I think the first thing is actually not so much a mistake but most of the problems arise from the use of JavaScript frameworks. And the third party plugins that go along with them. Nowadays people would think you're weird if you built a website without using a JavaScript framework. But when we started back in sort of 2002, jQuery didn't exist back then, or not in any meaningful way and you hand coded every single line of code. Then came along jQuery and later things like angular react and the whole bunch of other frameworks. And so, a lot of stuff is built in and nowadays anyone building a website the first thing they do is pick a framework. And as soon as they've done that, they've baked in a whole ton of accessibility problems because all of the frameworks are horribly inaccessible and even the ones that aren't so bad the third party plugins for them are terrible. And so even before you've written a line of your own code. You've already got a whole stack of problems there that you then need to strip out and fix. So, people who've been down that path will typically go through all the pain of fixing the framework and creating their own version of it that they then use for future projects. But first-time round, there's no avoiding that pain unless you don't use a framework. The other major sort of generic thing that's causes problems is developers trying to be too clever. And not really sure why they do this. But if there's like a simple way to do something like using a native HTML element. And there's an insanely complicated way to do it. They will do it, insanely complicated way for whatever reason, and so that always brings a whole load of accessibility problems. Now I reckon that accessibility peaked around probably 2006. So, 15-16 years ago and it's got progressively worse since then. And that's due to a combination of the JavaScript frameworks, but also code just getting more and more and more complicated and developers trying to do so-called clever things for whatever reason, and just year on year, the accessibility gets worse and worse and we thought it couldn't keep getting worse, but it does so. So my advice is that if you if there is a simple way to do things and using native HTML elements do it that way. Benjamin Ellis: And for the for the less technical members of our audience, what's going off under the hood here is oftentimes when you pull up a web page and look at it in the original kind of development of the standards and it was literally the text that got put on the page with some styling around it. Whereas now, what tends to happen is your browser loads up the page. It goes off, and fetches megabytes of code, which then render the text onto the screen. So, for a computer program looking at this screen rather than the user, what's there is changing all the time, and it can't work out. What is readable text and what's hidden and what’s put off the page and so actually for the screen readers and assistive technologies whilst the visual thing might look great with this sliding picture show and buttons coming in from the left, right and all these beautiful things, actually it stops a lot of the accessibility tools working. And actually, even for people not using the tools, sometimes a lot of that visual movement can be quite off putting or make the text difficult to process and read. Steve Green: Absolutely. In the old days you used to be able to very easily read the source code and so one thing on the page would correspond to one line of code, which might be a text box or a paragraph or something now that one thing on the screen might have 50 lines of code that you have to read and work out what on Earth is going on there. And yeah, you mentioned things moving around. That has become much more prevalent in recent years with things like parallax scrolling which makes me feel ill and I know a lot of people don't like that. And pages where as you scroll down content seems to just fade in or slide in from the sides and everything's moving, even when you hover over links the underline will slide in instead of just being there. Really don't know why designers do this cause it all adds extra code, extra potential problems. No user ever said “I really wish all the text came sliding in from the side instead of just being there”. No one ever said that. Benjamin Ellis: It is interesting as web browser technology has moved on that now increasingly there are settings to say actually, I want high contrast, I prefer low movement, and actually users having to communicate to the designers and builders of the websites and the forms “please don't do these things”. Please make them easier for me is an interesting continuum as well for us. We think on the continue to increase civility as well because the reality is there are people out there who may have a very old machine and an incredibly slow rural broadband connection. Might not even be broadband, might be you know a very slow 2.5 G mobile connection or something where actually the experience for those users is some of these things could be that a page takes 30-40 seconds plus, sometimes even minutes to load and you know goes on the capabilities of their machine in terms of the graphics is trying to do and that literally renders it un-usable. So sounding like the doom mongers. And then turning it around the other way. So, what would you say people are doing really well in the accessibility domain in terms of kind of building surveys and forms and digital things at the moment. Steve Green: Right well, obviously you guys are doing really well. On the project that we did with you, you were able to fully conform with WCAG 2.1 AA which is pretty challenging to do not many people get all the way there and you did so that was great. We've recently worked with another agency who are working on behalf of, and I've forgotten, which government agency they are working for now. I think it was the DWP uh and they had a survey. Took a bit of beating into shape, but again we got there, 100% WCAG conformant. There really aren't that many good examples and most of the ones I can think of are government related and the reason for that. Is that certainly the newer government websites by which I mean like central government that they're built using the Gov UK design system which, and you can look it up online, is open so anyone can use it. And so indeed. They encourage people to steal their code because they've built a component library of all the most commonly used components and design patterns. And not only have they got some really smart developers there, but all of the components have been extensively tested for cross browser and accessibility, so it's very safe to use any components or design patterns that you find on there. And now that's it's been around a while, I'm not sure how long maybe 5-6 years. But it's obviously started off small and only the newer websites have been built with it, so, although all government websites look the same. They're not all coded the same, so that some of them are really, really good for accessibility, some of the older ones less so. So that is really the biggest example of things done well. I really struggled to think of anyone else. I'm probably being unfair here. I'm sure there are some good examples and I'm reluctant to the sort of big up my own clients here, some of whom have done some exceptional work. But unfortunately, still most of the big brands out there are still not doing very well for accessibility. Some like, and I will mention the BBC, are going backwards. You know, ten years ago. The BBC were at the forefront among larger companies. They were doing accessibility really well and sadly now that's no longer the case. Benjamin Ellis: And so one thing we kind of skipped over, and didn't talk about is why should people think about accessibility? I think you and I can take that a bit, for a given, but why if I'm trying to go to my boss, “hey, we need to kind of invest in this and skill up in this” what's my pitch? Why is accessibility, something that I need to do if I'm engaging with the public. Steve Green: Yeah, so there are a number of reasons and when we're talking to people in an advocacy role. We try and work out like? What's their hot button? Which one are they gonna respond to. So we might start by saying depending on what your website does. Then, having good accessibility might extend your marketing reach and maximize your sales. You might actually get some return, difficult to quantify but in principle, if more people can use your website more people are likely to buy from you if you're selling online. So that's normally the first angle that we'd start with. And it might minimize your support costs if you're having to take calls or emails from people who can't use your website because of the accessibility issues, then making it accessible potentially will reduce that support workload. Then you've got avoiding bad PR. So, you'll never get good PR for having an accessible website. But you can certainly get bad PR for it. I remember in the early days about 20 years ago, I won't say which one of the online banks, but one of the big ones were horrified to find a quarter page article in one of the broadsheet newspapers now talking about how their online banking couldn't be used by people with disabilities. Alright, it's seeing something like that in the press is just horrendous for the product owner. So, like so you can avoid that sort of that issue. And in fact, so about five years after that, in the law world, one of the major publications there decided that all law firms should have accessible websites like accessibilities of the law. So, law firms should be accessible and they commissioned a company, not us, to do an accessibility test of the top 20 law firms websites. One of whom was a client of ours and so. They just got a phone call saying we're publishing in 24 hours. You've got 24 hours to respond and these are the problems we found on your site. Our client was actually possibly the biggest law firm in the world and they went into panic stations at the idea that they were going to be criticised in their own trade press, so some of these are genuine issues. They're not theoretical, this really happens. Next issue, corporate social responsibility. Oh dear, we're getting a bit negative. Uh you know you'd hope people would do accessibility just because it's the right thing to do, but a lot of people don't respond to that. Actually CSR is probably the reason why for the most part, the banks were very early adopters of accessibility going back 20 years ago, when almost no one was doing it the banks were. If only because it was a tick in the CSR box. So look, we're not big nasty corporate giants, we actually do touchy feely stuff for the benefit of everybody. Then the very last button that we push is the legal compliance button because people rarely respond positively to that. If you go up to them and say you need to make your website accessible because the law says you've got to that gets people's backup. They don't like being told they've got to do something. Even if it's actually true. Uh so that is generally the very last thing that we do, and in terms of legal compliance. It's a bit of a confused landscape. If you're in the public sector. Then it's very much the law. There is a specific public sector accessibility law that came in in 2018. And crucially it's got teeth because the government digital service pick about 1.5 thousand public sector websites a year at random and test them and if they find accessibility issues. You get a report saying, “You've got three months to fix it or you’re in trouble. And that doesn't apply to the private sector, although it does apply to private sectors suppliers of services to the public sector. So indirectly applies also in the private sector. There is and always has been the Equality Act and prior to that the disability Discrimination Act. And although that's been around for more than 25 years now that doesn't have teeth. No one’s monitoring it and as a result, no one really paid much attention to it. There’s the occasional court case but it's generally only the very largest companies ever got taken to court for that. So it wasn't much of a threat. And there's the possibility that a new law will come in for the private sector like the public sector one. But we don't know if that'll happen because the public sector one started as EU legislation that was transposed into UK law before we left the EU. And following down the tracks a few years behind is the public sector version that will happen in the EU. We don't know if our government here may or may not choose to adopt that or something similar. Benjamin Ellis: Yeah, and it's interesting in the Disability Act and conversations that I've had recently with employers about reasonable adjustments and so again, it's certainly the case that employees could say well, “Look you know, I need to use this website to do my job. It doesn't work with the tools that that I use can we get this sorted out please”. You know, is it is a reasonable request. Steve Green: It may be, and the thing about the Equality Act is that it is all about reasonable adjustments and a court will take into account all kinds of factors like number of people affected, the cost of fixing the issue the life of the application. So only a court can tell you if you're compliant or not. So that makes it a little bit difficult for any company to know if they're compliant. And the difference with the public sector regulations is that that simply says that your website has got to meet a WCAG 2.1 AA, there's none of this reasonable adjustment thing you've got to meet that. There is a disproportionate burden exemption, but you have to essentially put all the figures together to show that it would be disproportionately costly, whether financially or time-wise, to fix things. And anyone can request that assessment via an FOI request so you can't just say there's a disproportionate burden and you can be held to account for it. Benjamin Ellis: Yeah, so zooming back up your list from the compliance side. It has been interesting with our experience that actually putting the accessibility lens on and one of the things we do, oftentimes is we'll try a page or a design with a screen reader and it's interesting how many times when we pick something up it makes us go, “well hang on actually, that the text of that is not as clear as it could be or not as concise as it could be or actually could be laid out in a different way in terms of spacing between that. Actually putting that lens on helps us build something better for everybody and for us that that helps push up completion rates and the quality of data we get back so it's one of those things that actually building that skill set and going through the learning journey means that we're building a better product for everybody, regardless of their accessibility requirements is just making us think about “is this the best it could be in terms of how I use this?” When I put on different lenses in terms of you know, maybe reading’s overwhelming for me. Or maybe I'm using some really small screen. It's another example. That's being accessible across a really broad range of devices that there is this kind of a rising tide of it actually improves everything and there's a lot of talk about user experience at the moment and the user experience design is exploding. And for us accessibility has been a really very concrete goal around the user experience that we can work to and put on different lenses for different users to think how would this be for this person or this group of people. So, a question that we get asked from time to time is “should we create a set of rules to follow that ensure that all surveys meeting accessibility standard” and we talked a little bit earlier on there. There's the technical bits of it. There's kind of the bits and bytes that happen, and then there's what I would call the content bit so the questions that people write and how they kind of lay those out so what's your thoughts on that is there is there a kind of Golden set of rules? How do you approach baking this in almost at a policy level as it were? Steve Green: Right well, I'm not an expert on survey construction. I'd say the web content, accessibility guidelines already exist and to some extent, you don't really need to do more than that. But I'm certain there will be like writing guidelines for how you write your questions. But that is way outside of my expertise. Benjamin Ellis: And it's like how people use media as well. It's like I know you don't get that very often. Interestingly surveys, there is still the whole thing we still see lots of things where people put kind of very rich content in there. That's not necessarily accessible that again should be kind of a well known thing, but yeah, it's less so. Are there any particular tools or techniques that you'd recommend people would use to either kind of up their knowledge or to help them start to make some assessments ahead of bringing in experts to look at things. Steve Green: Hmm. I'm tempted to say no to that. What I generally advise people to do if they want to go down the path of learning about accessibility is rather than try and go and learn about it generically, actually it because it's such an enormous topic, and you can spend a lot of time learning about things that you'll never use, I think actually you're better off getting a small amount of testing done on a real product where it's gonna have real benefit to you. Maybe only couple of days testing by a specialist company or specialist freelancer maybe, and then looking at all of the issues that arise from it and in particular, how they need to be addressed because even a very small project testing, maybe 10 pages you might find that you've got 20 or 30 issues to fix, across perhaps 10 different types of issues, some of which could be visual things like colour contrast. Others could be under the hood like semantic structure or JavaScript related things. And you will have to learn how to fix 10 different types of issues and that will then take you onto into all the technical specifications for the different elements, scenario roles and everything and that will generate plenty of stuff to study but it all has an immediate impact and it's like a bite size thing. It's easily digestible and so you can implement those changes within a couple of weeks. You've now improved your website, tangibly, you've learned some techniques and then. Do the same thing again. Test something else, learn some new techniques and that way everything you learn is relevant to what you do and it gets embedded because you're doing, it, whereas if you start to study stuff that you're not actually using you'll just forget it. Because some of it's pretty esoteric. As for using tools you need to be careful there because. Although you could download a screen reader or magnifier or dragon voice recognition software, or something. If you start to use it without having had professional training. You'll probably be using it wrongly and you'll probably come to the wrong conclusion about your website and make the wrong changes to it. So, if you are going to use assistive technologies, I recommend actually paying for professional training, which might only be like half a day, a few £100. And that's what I did when I started this way back in the day because there was nothing on the web back then. You couldn't read any articles about the screen readers. That wasn't anything so I just paid professional trainers to teach me how to do it. And then in terms of testing tools because there are some automated tools for testing website accessibility. The problem with those is they can only do a small proportion of the tests that need doing so, they give you a full indication that everything's OK, when it isn't. They also have false positives, so they are told you something's wrong when it's not. And you need experience to know when the tools are lying to you. And, of course in the early days you won't have that experience, so I'd be very wary of sort of trying to do things on your own before engaging with an accessibility professional. And I'm not trying to sell our services here. Benjamin Ellis: You're reminding me. The three levels of mastery, which was explained to me once is know the rules, know when to break the rules, make the rules. And it is interesting, that quite a bit of accessibility is craft and art almost is that experience to know well. I've got a warning about this, but actually here that's not gonna be a problem for users whereas this will be and again a lot of this comes back to connecting with users and we've certainly benefited from some of our bigger customers have internal stakeholder groups who are very good at collecting together feedback and going “yeah, here's the challenges we've experienced in our environment” because there's always interactions with the fun things that IT have put on their machines and the tools that they're using that. So on that. The thing that comes up from time to time is people ask: “what is an accessibility statement” because they come across this term and then like well, what's an accessibility statement? Do I need one? How do I get it? So, for people who are new to that, what's an accessibility statement? Where is that kind of applicable? Steve Green: Right so an accessibility statement. It is well, I suppose it depends on your context really, but I'll deal with the context in which it comes up mostly. So in most cases, it's a web page that explains how accessible your website is. It'll list the things that you can do such as zooming the page to 400% without content overlapping or getting truncated. And it will list all of the known accessibility issues and the impact on you so you can know if you read it before you use a website you will know what you can and can't do. If there are any, cause with a lot of websites that they might be largely accessible. But there might be specific things that are not like videos might not have the captions or perhaps there might be some documents attached that are not accessible so the accessibility statement will tell you that, so that as you go through the website. And you know when you come to a document that it might not be accessible to you. The accessibility statement should contain contact details in case users need help or if they want to report an accessibility issue and ideally it should also contain a road map that states, when you're going to fix the known issues or if you don't plan to fix any of them. And so, you'll find accessibility statements like this on all of the public sector websites that I mentioned that it's actually requirements of the law that came in and that so they all have this and they all have to be updated every year. And there are other types of accessibility statement or to use the full-term accessibility conformance statement. So the statement that I've just described is intended for the benefit of users. It's on the website in question. The other type of conformance statement is known as a VPAT which stands for voluntary product accessibility template and that is intended for buyers, and it contains some of the same information. But it contains a lot of technical stuff and that won't be on the website generally. That is something that a third party software supplier like your company and you know, people like Microsoft and Adobe. They will have VPATs for all of their products or SAS services. And if anyone is thinking of buying or subscribing to those products and services. They can call up Microsoft or whoever and say, “Please send me your VPAT for Microsoft Office” and it'll get emailed over or it might actually be on a website somewhere. And the idea is that it's a standardized format that a buyer can look at if he's thinking of three different products he might buy you can put the VPATside by side and decide which is the most accessible. So the VPAT is not intended for users so it's an entirely different purpose. So those are essentially the two types of accessibility statement. Benjamin Ellis: That's super helpful. I think one of the things that there is like a minimum take away is the whole contact piece. I've been surprised a number of times I've used something and see something really obvious that makes it hard to use like I would like to tell somebody and you can't find a way to do that, so accessibility statements if nothing else is from that point of view. If this is a problem, we know about and if you spotted something different you've got a contact point there to get help as well. And again for us, that's one of the things I'm trying to make sure that users can get help when they need it if we've missed something as well. Because you're not always going to get everything that yeah, there's always unique twists of tools. You haven't come across before or a specific disability that perhaps impacts in a different way that you haven't considered in the design of the survey or the platform. Steve Green: And it's worth remembering that although almost everyone aims to meet with WCAG 2.1 AA, and when you get it’s like “ohh fantastic, we've achieved full conformance.” There are another 28 requirements at level AAA that you probably haven't met. And then there are all of the user needs that aren't addressed by WCAG at all for various reasons, so, although meeting AA is great, it by no means guarantees that your website or mobile app is going to be accessible to everyone. Benjamin Ellis: Yeah, and that that whole experience thing again for you know for us. A big part of the journey is the impact on the content that people put in so how you ask questions. The question types that you choose. Whilst, you can be technically compliant. You can build something that’s actually quite hard for people to use if you use the drop down question with 100 question choices, that’s probably difficult for most people. But if you're using that with a screen reader. You're going to be there for 10-15 minutes. While it's reading through the choices and it's just not a pleasant experience. Whereas actually we need to step back and go well, can we break this into two or three questions or use a different question type just to make that a bit more friendly? And again, everyone benefits not just folks using screen readers. Everybody gets a better experience as a result of that process. Benjamin Ellis: Well, I would say that that's a very Steve, but you have been and your team have been invaluable in terms of helping us up our expertise and you know, really pushing us on moving forward accessibility. I mean, I'm very encouraged these days by if I go back. Even just three four years and both in the public sector and the commercial sector. It was not something people talked about and we always kind of built it into the product and we tell people we've done that. But nobody was interested. Now actually even in the last few days, actually, every conversation. It's come up like is this accessible? Has it been tested for accessibility? How do I build surveys that are accessible? There's much more of an appetite to actually try and build services and experiences that are accessible to as broad a range of people as possible. There is some hope. Whilst the technology might be making it harder, there is an increasing desire to be more user centric in what people build which is encouraging. Steve Green: Certainly if you're a third party supplier to the public sector. Then you can expect them. At some point to insist that your service is not just accessible but you can show that it is. Benjamin Ellis: Yeah. Steve Green: And so the public sector started by sorting out their own websites and that’s sort of taken three or four years, but now they are very much starting to focus on all their third party suppliers and we've worked for quite a number of people in your sort of situation who suddenly been told. If you can't make your website WCAG conformant or we are not going to be able to use you. We'll have to get someone else's service. So it could well be an issue for anyone in the private sector who supplies the public sector. Benjamin Ellis: Definitely something to focus the mind, but thank you very much for your time Steve. It's been absolutely brilliant to talk to you. We will include links for people for a lot of the things that we've mentioned here and also for the podcast as well, and hopefully we'll speak to you again sometime, thank you so much for your time today. Steve Green: Thank you for inviting me. Links: Accessibility guidelines: https://www.gov.uk/service-manual/helping-people-to-use-your-service/understanding-wcag https://www.w3.org/TR/WCAG21/ The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 https://www.legislation.gov.uk/uksi/2018/952/made Government Digital Service (GDS) https://www.gov.uk/service-manual/helping-people-to-use-your-service GDS sample accessibility statement https://www.gov.uk/government/publications/sample-accessibility-statement Three/four stages of learning blog (Test partners) https://testpartners.co.uk/blog/blog_software_quality/the-shu-ha-ri-kokoro-learning-progression.htm IAAP: https://www.accessibilityassociation.org/s/ Webaim: https://webaim.org/ The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 https://www.legislation.gov.uk/uksi/2018/852/contents/made Equality act: https://www.legislation.gov.uk/ukpga/2010/15/contents