Going from good to great in digital accessibility – Digital Accessibility Experts Podcast 7

Stop press: Our podcasts are now available on Apple Podcasts, Spotify & Google Podcasts. Check our library of podcasts out – there’s a lot of great accessibility insight in there. And don’t forget to subscribe, so you can pick up our latest podcasts as soon as they’re out.

Welcome to podcast 7 of our Digital Accessibility Experts Podcast series.

This month we’re doing something a bit different, talking with Rob Wemyss, one of our Hassell Inclusion Accessibility Managers who helps organisations mature in accessibility.

We’re looking at going from “good to great” in accessibility – what do you do when you’re good at this stuff but you want to push it to that next level?

We look at some great tips like:

We hope you enjoy listening to it as much as we enjoyed recording it! And if you’d prefer to read the podcast, rather than listen to it, read the transcript below.

 

What do you think?

We’d love to know your thoughts on this podcast. Please share your comments below.

Want more?

If this has been useful, you might like to sign-up for the Hassell Inclusion newsletter to get more insights like this in your email every month.

Transcript of audio

Jonathan Hassell:Welcome to the Digital Accessibility Experts podcast. This morning we’re looking at accessibility “good to great”. What do you do when you’re good at this stuff but you want to push it to that next level? I’m delighted I’ve got Rob Wemyss with me today. Hi, Rob. Rob is from my team at Hassell Inclusion, and we’ve known each other for how long?

Rob Wemyss:Feels like forever.

Jonathan Hassell:It does feel like forever. I’m really excited this morning because I think Rob has in his head a lot of the insights to unlock that good to great. I think we’re going to have some interesting time looking at things like how does this work in terms of testing? Is audit everything, or is user testing a great idea? How do you get good at this when actually it’s not you creating the product but it’s, maybe, a number of different organisations who are doing that for you? How do you get all of that working?

We first met when Rob was at the Royal Mail. You asked me some really good questions about BS8878. You also asked some really good questions about the Accessibility Issue Prioritisation Matrix, so it’s always been an interesting conversation between us about how to get accessibility right in organisations, how to do it efficiently.

At the moment, you are working for us supporting a really large organisation who are trying to get good at accessibility across a huge number of products. We’ve been in there for a number of years now and we’re, kind of, at that stage where the organisation is getting pretty good at it.


I guess the first question I wanted to ask, just to start us off, really, was what’s the difference between an organisation who is getting good at accessibility and one that you think is really good at it, or maybe great at it?

Rob Wemyss:I’ve been thinking a lot about this recently. Many organisations are getting good at technical accessibility, compliance, being able to follow WCAG guidelines, being able to audit and come up with a set of results. That will get you to ‘good’ as an organisation. To get you to ‘great’, you need to then start involving users and making sure that the experiences we’re creating for all our customers is a great experience, so moving from technical compliance, which is obviously important, to a great user experience for everybody.

Jonathan Hassell:Is there a best role for audits in an organisation that really is doing very well with accessibility?

Rob Wemyss:From my perspective, it’s almost too late when you get to audit. What I’m trying to do is pull back so we’re getting much better before we even go to audit, so at design stage we’re looking at: are we going to flag any accessibility issues in audit from these designs? Have we followed a WCAG checklist – with regards to the key points? Have we tested this before we go to audit? We’re now getting to a point where the audit stage should be surfacing way fewer defects, making it a much, much more efficient process of delivering accessible products.

Jonathan Hassell: What’s a reasonable number of defects, you think, for an audit to be finding?

Rob Wemyss: It entirely depends on the product, number of screens, etc., etc. To put a rough number on it – say you had 15 screens – I would expect less than 15 defects, anyway.

Jonathan Hassell: That’s very different from organisations right early on in their journey. We don’t do very much testing in our organisation, but we work with lots of organisations who do. One of the things that we always had to do was to try and almost enable organisations to pick themselves up after an audit. If you’ve got, like, 60 errors in there and the document is like 90 pages, it’s one of the first things that we were talking about in terms of prioritisation of, “What do you fix?” because the first thing is, if you’ve got, like, 60 issues, you feel awful. You feel like you’ve completely mucked up already. And, especially if it’s late on in the process, you feel out of control and unable to even think, “Where do we start with fixing this stuff?” If you’ve got 15, it’s all fine.

One of the things that we were talking about a lot, like early days with organisations, was how do you prioritise amongst all of those issues? I guess it’s still there in some ways, but maybe the better thing is that, yes, by the time the audit happens, it’s not finding very much stuff.

Rob Wemyss: That’s where we want to be, but you’re right. Prioritising defects is still a key part of an accessibility manager’s role. Getting the teams to work on the right defects that are going to have the most impact in, again, getting to that great user experience for all customers is key.

Speaking pragmatically, you’re not going to be able to fix everything before “go live”. In an ideal world, we’d have unlimited time and resource to have products fully signed off. That’s what we’re aiming for. In reality, nothing ever with a high defect; medium defect, maybe. You can negotiate on slightly lower defects that have a more cosmetic feel about them. That’s where we’re trying to get to now.

Jonathan Hassell: In an ideal world, your audit finds very few issues, because you’ve been testing earlier. Who do we then rely on, to get that testing done earlier? Is it the people who create stuff, or is it someone else?

Rob Wemyss: What we look at now is using automated tools before you get to audit. A developer can be running an automated accessibility checker across their code. A QA person can then be running a similar type tool across their code, so we’re going to pick up, maybe, 30-plus accessibility defects at that point. Then I’d hope there would be a manual check for things like keyboard accessibility etc. we can’t pick up with an automated tool.

Jonathan Hassell: You mentioned QAs. We’re training QAs a lot these days. The QAs are actually more important on the accessibility journey than the auditors, because the auditors do an incredibly important role, but they’re too late. Does it work – getting the QAs actually engaged and testing accessibility alongside the other things that they do? Are you finding the impact of that in the teams that you’re working with?

Rob Wemyss: QAs, when they are made aware of accessibility, they’re then very open to adding that into a test script, having a script to work against, so, “This is what we’re doing for accessibility,” “Great.”If they haven’t heard of accessibility and it’s not in their remit to be even testing for accessibility, then it’s not going to happen. Building in accessibility for QAs is just what it should be with regards to moving a product through a logical process.

Jonathan Hassell: Yes, and it saves a lot of money, presumably. The place that you find the defect, that’s the main factor in how much it costs to fix that thing, yes?


So we’re now more efficient. Now the teams are getting more confident because they know they are loads of things that the audit won’t pick up, because they’ve fixed them all already. Half of it is fixed, so it’s literally the few areas that they may have missed. So we’re now in a better place. We’re already good, but great is to actually get the users involved in it. Why is that helpful?

Rob Wemyss: We can then surface the actual flow of the journey for somebody. Technically, I can access all the information on the screen, but some of the copy might be confusing. It doesn’t help me get through the journey. It doesn’t trigger the right error message or give me some feedback that something’s actually happened here. So, basic usability principles applied with an accessibility lens on them.

Jonathan Hassell: Sure. I guess if that’s “great”, there is an assumption there that usability has something to do with accessibility, too. An audit is very much based on a perspective of, “I want to be compliant because that’s the important thing.” When we’re looking at user testing, it’s about that user experience because we’re saying, I guess, “We care.” Is that what marks out an organisation who is really getting accessibility done well? That they do actually start caring about a higher level of things?

Rob Wemyss:I think we’re caring about customers, we’re empathising with all customers. We’re putting a clear stake in the ground that we want our products to work for everybody. Why would we want to exclude anybody from a technology point of view? We don’t have to do that now, and from an experience point of view. Disabled people tend to be more loyal customers at the end of the day. Certainly large organisations are aware of this now. The cost of getting a customer initially is very high. Retaining them, again the cost goes down.

Jonathan Hassell: And to do that you need to really understand people rather than the guidelines. I’m going to take a perspective that I just want to get this product out there. So, if I’m the product manager who’s sitting there going, “Yes, I thought we had accessibility sorted. We’ve now got a really efficient process where we’re not finding all of these accessibility problems at the end. We’re actually, probably, finding them earlier. Therefore, life is easier for the whole team,” Now you’re saying, “Actually, we need to find all sorts of problems that may not necessarily be in WCAG.”

As a product manager, I might agree that those would be really useful things to find in an ideal world, but do you get pushback? Do you get people saying, “I thought we’d done enough already”? We’ve done all of that WCAG stuff. That was hard. Now you’re bringing in a whole load of other stuff. Do they know how to fix those things when you give them that – those issues that are in the middle of usability and accessibility?

Rob Wemyss:To be honest, not always. There can be pushback. We take the findings and we work very, very closely with the product owners and teams to identify where we can change the experience for the better, and hopefully for everybody. That’s the ideal. It’s not just for one subset of people. By making this change – maybe it was a copy change to make it more understandable – it actually is going to work for everybody in the end.

Those are the types of findings that are a lot easier to sell in at that point, but it’s up to the accessibility professional to be able to look at the reports and work out what is an issue that’s actually going to help everybody, and what might be an issue that is just not going to be achievable.


Jonathan Hassell: Part of this is the motivation, I guess. In an organisation that really does accessibility well, people actually care. It’s not about… I tend to think of organisations a little bit like the ones that get excited by accessibility and see the opportunities, the possibilities in it. They’re quite open to greater levels of insight, greater feedback that you would get from testing. Then you’ve got the other sort of organisation who just, kind of, want to keep it in its box. For them it’s just, kind of, like, “Actually the best thing that could come out of a test is we don’t have to do a single thing, because we’ve got to whatever level that you needed to get to. We don’t want to go any further.”

You’ve worked a lot with trying to enable people to want to do more. How do you take an organisation that is quite happy with “good”…? If, say, for example, you’re an accessibility professional in that organisation and you want to push them to another level, how do you excite people about what the possibilities are with this?

Rob Wemyss: I think sometimes you have to start with almost the shock factor of showing somebody really struggling, logging into whatever your product may be – somebody having real problems there. It doesn’t have to be a full usability test. It could be done quite quickly and cheaply, but actually showing somebody having an issue is powerful, but then moving from that to, “Okay, what are the steps we need to take to make this work?”

People often don’t know what types of different technology people are using, how they’re using it: voice activation, screen readers, etc. It’s an education piece. People are often a little bit afraid to ask, to dip into the water with regards to assistive technology, so it’s introducing accessibility in a safe way to people, for them to be able to ask the right questions.

Jonathan Hassell: Is there anything that you’ve done that made people sit up, and take notice and say, “Actually, this is cooler than I thought”?

Rob Wemyss: In the past, we’ve been running empathy type sessions with teams, which works really well. Taking their own product and just showing them how it works with different bits of technology – and potentially letting them try it out, as well – is very powerful. It just gets them… gives them that little bit more motivation that that need to start on their journey.

Jonathan Hassell: Yes, it’s all those, kind of, voilà moments of, “Oh, that’s why I need to do that sort of thing.” We’ve been doing a lot of stuff like that with screen readers and things. I know you’ve introduced lots of people, who probably never thought they would go anywhere near a screen reader, to how that technology can actually be of interest to everybody, really.

One of the things that are happening at the moment is voice activation. Apple, that’s one of their big new things in iOS 13, macOS Catalina. Do you see that sort of thing opening up the ideas of, “Actually, it may not necessarily just be for disabled people, but actually I might want that, too”?


Rob Wemyss: I see possibilities and I think that’s almost the key, going forward, to accessibility: making these products that we all want to use. That’s where building in accessibility into native mobile apps, which is something I’ve been very heavily involved in, means it’s going to work when Apple release something great like this that everybody can use of a high quality that it’s good enough to replace an expensive product. That works for one group of people, but actually for everybody, potentially, using this technology when I’m temporary disabled, or in any other situation, is fantastic.

Jonathan Hassell: Yes, I wrote the first version of my book using speech to text, because I was tired. I was writing in the evenings. Actually, there’s something quite interesting about speaking. The way you answer your questions is different, because we’re actually having a conversation, than if you were writing something down. I see all sorts of really interesting things coming out of that. You can almost tell when somebody has used some of those technologies as part of their creative process.

There are lots of really cool things. And, obviously Apple, and Microsoft and people like that are investing a lot of money. Presumably, they think that there’s a lot for them to gain there. That’s great for the big companies. The difference between those and pretty much everybody, everyone else who’s a client of ours, is that they create operating systems, they create browsers, they create the underpinning for what most of our clients do, which is to create the websites and the apps on top of them.

I’m interested in pushing things a little bit, being a little bit innovative. If you have, say, one of those mobile apps. What can you win if you go a little bit further in accessibility, to try and really respond to the sort of needs that you might find in a user-testing session?

Rob Wemyss: To give you an example, I was at a large theme park a couple of weeks ago, downloaded the app in the queue. Great. The most useful part of the app was the ride times: “How long am I going to have to wait on particular rides?” Fantastic, great. My eyesight isn’t great. I didn’t take my glasses with me, because I didn’t want them flying off when I’m on a rollercoaster.

Jonathan Hassell: The user experience of, “I can’t actually see the park, because my glasses are somewhere in a field” is not a good one, yes? (Laughter)

Rob Wemyss: I have my dynamic font size set to halfway between largest and medium, so everything is bigger. The app didn’t respond at all to that. The actual ride times were in a, sort of, lightish grey font against a white background, so it was impossible for me to read, to understand, so what I had to keep doing was keep passing the phone to my wife to tell me how long.

Big deal. But for me, if they’d gone to the understanding of, “Yes, some people are going to need to be able to see this in a slightly different way,” that would have just made my experience just a tiny bit better so I didn’t have to keep going, “Can you read this, because I haven’t got my glasses and I can’t access this information.” My kids, you know, “I can read it,”

Jonathan Hassell: It doesn’t add to the day, does it?

Rob Wemyss: No, it’s just one of those small things that make you think, “If it had happened, that would have been a great experience.”

Jonathan Hassell: Sure. There’s something really interesting there. We did some research for an organisation in the Middle East a couple of years ago about theme park accessibility. The interesting thing about the theme park is that you have accessibility from all sorts of different angles.

You’ve obviously got accessibility of the rides. My nephew uses a wheelchair, and, when we went to one particular theme park, there was an accessible lift to get to the start of the ride. We’d literally got to the start of the ride, which was, kind of, like a rollercoaster type thing, and then they, because he uses a wheelchair, they said, “Can you walk…”, I think, “18 steps?” or something, “In case there’s a problem on the ride.” He said, “No,” and they said, “Well, you can’t go on the ride.” The entire family were there, just about to get on the ride. It had an accessible lift to it, so it was like everything was set up. There was even accessibility information in the app and the leaflets and everything, and yet when we got there we couldn’t do it.

The user experience was appalling from our viewpoint because our day had gone from, “We’re going to go on this great ride,” to, “Oh, no, we’re not. We’re inclusive. We either all go on it or none of us go on it, so that ride was out of bounds and we were really angry, actually, because they hadn’t told us until we got there.

I was talking to a guy who used to work at Disneyland and he was saying that it’s all about you’re trying to, kind of, surf this amazing experience of the day. If you pop the bubble, as it were, because something doesn’t work, you can possibly do that once. But, if you do it twice, then that’s normally a whole family whose day has been ruined. That’s a lot of money to give them back when they complain.

There is a really interesting thing in here about how the experience of one person with a digital product fits in with the people around them, and also the stuff that they’re doing. In the new ISO standards, 30071-1 one of the things we did was we said, “Everyone just keeps on talking about websites and apps, but nobody really thinks about how they work in what we would term ‘hybrid’ situations, where the app is part of a wider experience.” I think there are real possibilities there where we can say, “Digital isn’t just itself; it’s actually part of a bigger user journey.” Any thoughts about that?

Rob Wemyss: The example you gave, if that had been user tested, because obviously on paper they’d gone through the steps: “Okay, get to there, we give the information, we have the lift, we have the…” But the one final step that would have come out in user testing with a yes/no answer would then have made them go back to – almost go back to – the drawing board to say, “Okay, we need to fix this. How do we take that extra step?”

From a digital point of view, logging onto a product, if you can’t do that and you have to have somebody else do it, then that’s someone else’s time and it’s wider than just that person using the product. It can actually be having to have help in doing my online shopping, whatever I’m doing there.

We want people to be able to use technology independently. As an organisation, that’s what we’re trying to achieve. Independent living is very, very important for everybody, and it’s something that drives me to help make sure products are more accessible.

Jonathan Hassell: Yes. I’m trying to work out why they got that wrong. Part of it, yes, could be because it wasn’t clear enough in WCAG. Because obviously WCAG and apps you can apply WCAG to apps, but especially if it’s a native app, you’ve got all of, like, the iOS guidelines and all of those sorts of things. Stuff can get missed between the sets of guidelines. How do we bridge from here to here?


Rob Wemyss: Rewinding back slightly, if it had been built in a procurement phase – because I’m guessing this company didn’t build this app themselves, so they would have gone out to market – if accessibility had been built into the requirements at that point, it’s much more likely that it would be working, because it’s a fairly basic thing to be able to get right in an app.

Jonathan Hassell: Procurement is a really interesting issue because people get it wrong all the time, don’t they? (Laughter) The two slogans from our course on procurement: ‘If you don’t ask, you don’t get,’ and, ‘If you don’t check to see if you’ve actually got it, you may not have got it.’

It felt like for a long time we were trying to get organisations to at least put something in their procurement guidelines to say, ‘It needs to be accessible,’ but where it feels like we’ve got to now is that most of the companies out there are a bit savvy to that, so they, kind of, go, “Oh, well, yes, you’ve mentioned the word ‘accessibility’ in there, so we’ll just say, ‘We’re doing WCAG 2.0 AA’. Then we’re going to, kind of, hope that you don’t pick up on it.”

We had one new client who we looked at their product and we said, “This website isn’t very good,” and they said, “We didn’t make it.” We said, “It’s not compliant,” and they said, “No, it should be, because it’s in our contract with our supplier.” We said, “How long has this contract been going on for?” and I think it was a number of years where they’d asked the right question at the start, but they hadn’t actually checked to see if they were getting it. You could almost feel like knives being sharpened in the room as them going, “Hold on a second. We thought our supplier had got this,” and they hadn’t… And that even assumes that WCAG 2.0 AA is the right thing. One of our first conversations was around procurement, because when you were at Royal Mail you had a product where you had loads of different suppliers on there and you were trying to use BS 8878, as it was then, to try and enable all of them to understand what the requirements were. Can you say a little bit about that?

Rob Wemyss: One specific example I remember is when there were three different vendors in the market and the accessibility requirements were in there, in the RFP.Two of them came back on a similar level, saying they couldn’t really do accessibility. One came back to say, “We can do accessibility,” but the cost was a third more than the other two vendors, which then becomes a difficult argument. We want to do the right thing, but we have a limited budget.

We’re still seeing that these days with white-label products or vendors who, again, want to do the right thing. This comes back to legacy products, as well  They’ve actually built something, and to change it does mean changing it for one client, it means changing it for all their clients, which to me sounds like a great idea because it means that we can make one product accessible and improve the experience for all these companies using this product, but there still seems to be some reluctance there.

I can, sort of, understand why. Any big technical changes can have a big impact. All of a sudden, if another competitor, another person using the product finds that this has changed, even though it’s changed for the better, they might still be wondering, “Why has this changed? It doesn’t work as it used to for our customers.”

It’s a really interesting, continual challenge. I think we can get better at this. I think now building something that’s going to be white labelled across multiples… we can build it right, that’s the time to really be using standards.

Jonathan Hassell: Your point there is really well made because, to me, the benefits for that white-label vendor are potentially huge. One of the first clients that we had at Hassell Inclusion was a third sector organisation. They had lots of volunteers and they all needed to be trained. They used to have it on a phone line, and they had just gone through a procurement exercise to get a booking system online.

Literally the day after they signed the contract, somebody said, “What about accessibility?” and so we did some user testing and we found that this product was awful. So, I said, “Okay, how are we going to sort this situation out?” I was almost like the umpire. Two sides of a table: one side was my client; the other side was the supplier, with me trying to enable the supplier to understand the problem that my client had, in such a way that they would actually devote some time to fixing it, because they didn’t have to, because it wasn’t in the contract. From my perspective my client was doing them a favour. My client had spent X amount of thousand pounds with us doing user testing of the supplier’s product to find all of the problems in it. The supplier should have done that already. They should have known what the problems were, and fixed them.

So, actually, they’d already given the problem to the client and so I thought that was good of the client to share it back. In my mind, there was lots of quid pro quo that could happen: “We’ve tested your product. That’s cost us some money, so can you fix the product. That will cost you some money? By the way, if you fixed your product, then it will be more saleable for all of the other organisations out there,” especially governments, who actually can’t procure a product that isn’t accessible. But that issue around how things change and what the actual costs might be across all of their suppliers’ clients never really came up, but I think that’s, kind of, key.


You push a lot against people who, in an ideal world, would really love to do loads of this stuff, but they have a deadline right now, or, “Yes, it’s too late and it’s going to cost.” Large organisations who are already good, chances are the difference between the organisation being good and great might be consistency. It may be that their main products are doing well, but they have those other products that are always Cinderella-ish. If ‘good to great’ is about consistency, any hints and tips on getting the guys who don’t want to move, in line?

Rob Wemyss: I think it’s key to raise the awareness in organisations. Events tend to be a great way of bringing senior people to the table, and telling everybody how important this is to the organisation: “One of our key pillars”. You very rarely find that from the top down they’re not interested in accessibility, inclusion, diversity – key drivers in all large organisations. That message needs to filter down effectively so somebody can actually take away from one of these events: “What do I do next?” The next stage might be, “Okay, we’ll put you in touch with one of our accessibility managers”, like myself, “to then get into the detail of “what can we do, then, to help you?”

From a strategic point of view, we know what great looks like for a project: assessing your team with regards to accessibility, getting the right role-based training in place, enabling them to be better so they can almost self-serve with this stuff. They can reduce the number of defects, therefore speeding up product delivery, and be delivering really great, quality products that everybody in the team can be proud of.

By putting the accessibility lens on it – there are lots of other lenses as well when delivering a product, obviously security, analytics, etc., etc. – but embedding this into the project team, it can be done. It needs to start from the product owner and business analysts, from requirements into design, engineering, leaving audit at the bottom of the pyramid, is the way I like to look at it.

I think it’s really interesting at the moment that people are creating design systems and toolkits out with those design systems. How does accessibility play within those? This is the right place to be with regards to feeding into a design system to then potentially have a component library of accessible components that teams can then start feeding off, taking those components and building out accessible products. We’ve done all the hard work at design system and toolkit stage. We’ve tested live components. Teams are then consuming those components into products. As new patterns are created, we then have a robust process of reviewing, making sure that before it goes into the actual component library that it’s properly accessible.

That’s where we should be with regards to building at scale. Obviously, there can still be issues with component libraries, even accessible component libraries. There’s still the potential to build something in a way that doesn’t quite work, so there has to be that additional layer of awareness and knowledge, as well, when you’re building a product. But certainly I see that. If we can get component libraries right, we get the process right, we can then have a chance of starting to build much more accessible products, much more quickly.

Jonathan Hassell: Yes, absolutely. Anything else that you think will take us to where we want to be in terms of that impact?

Rob Wemyss: I think that the resources around accessibility we have… Obviously, there’s blogging material out there. There’s a lot of stuff on Twitter.  We have books, we have standards; we have various videos. There’s a lot of information out there just now. It’s how do we tie all that together in a coherent way? Some of the information tends to be difficult to interpret. You can get two accessibility people sitting down in a room and they will argue on a specific point where, “No, this is definitely how you should do it.” “No, this is how…” It’s not always black and white on that, and I think people need more guidance, potentially, and more access to easy-to-digest information.

Jonathan Hassell: Thank you so much, Rob. As I say, that’s been really, really helpful because one of the ways that we’re trying to get stuff out there is multimedia. So, if you don’t want to read it, you can hear it. If you don’t want to hear it, because that may be difficult for you, you can read it in the transcript. You can read it in the book. You can read in the e-book, all of these sorts of things. I think it will be really interesting to see where everything goes from here, but for now thank you very much. It’s been a real pleasure chatting with you.

Rob Wemyss: Thank you.