Shifting left on accessibility

Episode transcript

[Music]

Scott Shaw: Hello, everybody. Welcome to the Thoughtworks Technology Podcast. My name is Scott Shaw. In this episode, we're going to be talking about shifting accessibility left for more equitable technology. We have a couple of experts in the field with us here. Also, our co-host is Prem Chandrasekaran. Do you want to introduce yourself, Prem?

Prem Chandrasekaran: Thank you, Scott. I'm a longtime Thoughtworker and regular co-host of this podcast. Glad to be here.

Scott Shaw: Our guests for this episode are going to be Kate Linton —

Kate Linton: Thanks, Scott. It's great to be here. I laid out design practice here at Thoughtworks, and I'm based in Sydney, Australia.

Scott Shaw: — and Katie Peterson. Katie, do you want to introduce yourself?

Katie Peterson: Thanks, Scott. I am Katie Peterson. I'm a software developer based in Sydney, Australia. I'm also an accessibility advocate.

Scott Shaw: Thanks. Let's start out by just talking about what we're trying to accomplish with accessibility. I think we can look at it in a lot of different ways. I know I've heard Kate and Katie talk about it, and I think you'd have some interesting observations about it. Is accessibility about bringing people with disabilities up to even with everybody else? Is it a matter of removing barriers, or is it something more than that?

Kate Linton: It's absolutely all of those things, Scott. When I think about accessibility, I often think about it in terms of inclusive design. As a product designer, I believe I do have a responsibility to ensure that everyone can use the digital product or service that I'm designing. As part of that, I need to ensure that I'm incorporating accessibility into that product. Certainly, removing barriers for people with disabilities is part of it. I also like to think that by doing that, I'm improving the experience for everyone.

Scott Shaw: I'd like to think technology cannot be more than just a barrier that- a lack of barriers. I'd like to think that technology can actually improve inclusivity, that it can augment and make- people with disabilities can make their experience even better.

Kate Linton: Absolutely. I mean, technology can change people's lives. For people living with permanent disabilities, technology has proven to be such an amazing enabler. Particularly looking at things like devices and smartphones and how they can really transform the way people with disabilities are able to engage with the world. Technology really empowers all of us, but can provide a real opportunity for people with disabilities to engage with the world.

Prem Chandrasekaran: Thanks, Katie. You talk about accessibility, the first thing that comes to my mind is websites, but is there more to it than just making websites more accessible?

Kate Linton: Yes, it's certainly broader than websites. I've been working in digital for over 20 years, and websites is certainly where it all began in thinking about accessibility. It really covers every experience that we design for people, including in the physical realm. We think about ramps and curb cuts and enabling people in wheelchairs, but our area, what we're talking about today is really digital. It's broader than websites. It's digital experiences that include a whole range of different touchpoints, from mobile apps to kiosks to websites. It's fairly broad. Our interest is certainly the digital world.

Scott Shaw: Kate, you used the phrase permanent disabilities. I think what we're talking about here extends beyond that, right? All of us have disabilities at some time or another, and it depends on our environment.

Kate Linton: Yes, that's exactly right. The way that the World Health Organization defines a disability is very much around permanent disabilities. We understand that 15% of the population have a permanent disability, but everyone can experience a temporary disability or a situational disability. The example that I often bring up in thinking about situational disabilities would be things like intermittent Wi-Fi, poor data. That can affect your experience and your ability to get information on content on your devices. The images will be the last thing to load, style sheets will be slow to load if you've got a poor internet connection.

That's something that we all experience. Accessible design will make that experience better. Similarly, temporary disabilities are also something that everyone can expect to experience at some stage. For myself, I don't have great eyesight. I don't think of my visual impairment as a disability, but if I take my glasses off, then I really struggle to be able to read what's in front of me. It really does affect everyone, but for 15% of the population it's something that you learn to live with permanently.

Prem Chandrasekaran: It sounds like there is a strong business case for accessibility. It's not just a nice to have. Is that right?

Kate Linton: Yes, I think that it's easy to build a good business case for accessibility when you can see that potentially there are an additional 15% of customers who are going to use your products or services if you design for accessibility, and it's probably broader than that 15% when you can see that for people with disabilities, it's quite often their friends and their families and their careers who are going to be using your services if you design for accessibility. That's a great business case in its own right. It's an incredible opportunity to extend your reach. There's a lot of other sound business reasons to think about accessibility.

I don't like to talk about the legal aspect of it because I don't think that should be the first reason that you would consider accessibility, but it is enshrined in law that if you are providing an essential service, then you need to ensure that customers are able to use it. In Australia we have the Australian Disability Discrimination Act. Most regions do have provision for this as well. There's a similar act in the US, Europe, so there's really good reasons to consider this, but I think it's just an incredible opportunity for businesses to grow their customer base, and to improve the experience for all of their customers, not just people who experience disabilities.

Scott Shaw: I think it's really, I think our public sector customers are really helping to move this forward in trying to make government services available to everybody, and provide fair and equitable access to those public services. I think that's actually making us think about this a lot more.

Kate Linton: Certainly public sector leads the way when it comes to providing accessible digital services. Increasingly we are seeing the private organizations in retail and in technology and digital products also really leading the way in this area. Organizations like Microsoft really try to improve the experience for people with disabilities by providing accessible products. We are seeing companies like in Australia, Coles, they've recently won an award for the accessible website, and that was after- back in 2014, they were sued for failing people with disabilities. We're seeing organizations really pick this up as a priority. It's certainly starting to improve. That's really encouraging to see.

Scott Shaw: Katie, I think my experience has been that this is probably not thought about enough that so many of the websites and the mobile apps that I try to use are not really that accessible. They don't have alternate text or they may not be particularly suited to screen readers. Why is that? Why is it that we don't see more attention paid to accessibility?

Katie Peterson: The reasons we often hear is that it isn't a priority or that companies don't want to invest the money. As we've just spoke about, the lack of return on costs is potentially huge. There is a massive market out there for permanent people with disabilities and also temporary and situational disabilities. Actually that encompasses most people. We think the real excuse is that people just don't know how to implement accessible products.

Product teams don't know how to build accessibility into products that everyone can use. If that is the case, it's more of a capability and that's something that we know how to do and something that we can fix through training and mindset and building accessibility into the product life cycle earlier.

Prem Chandrasekaran: What it sounds like then is that this can actually be a business advantage. A more accessible website makes it easier for machines as well, for example, search engines and crawlers to discover information more easily, not just for humans. Is that right?

Katie Peterson: That's definitely true. Screen readers behave very similarly to how an SEO would perform, and by having alt text on images for example it means that you can then search for that image. SEOs can't see an image but if you do have an accurate alt text that describes the image, then you'll be able to perform better in your search results.

Prem Chandrasekaran: I can totally relate to this. We are working with a travel company whose business is heavily dependent on their products figuring prominently in search results. I can see how making an accessible product can make a truly amazing product.

Scott Shaw: Katie, you didn't mention it in your introduction but you were the technologist in this team and you know a lot about how we build and test products for accessibility. What do we mean when we talk about shifting left, what are we talking about? What does that mean?

Katie Peterson: When we're talking about adopting a shift left approach or shift in accessibility left, we're meaning you need to start incorporating accessibility very early in the product's lifecycle. When we talk about the product lifecycle we're talking right from discovery or what we call discovery is also known as research through to the delivery of the product, and throughout each of them stages we can incorporate accessibility into the different phases. For example, when we are talking about the research discovery phase we can incorporate disability personas or overlays into our personas to really make sure that we're encompassing different perspectives.

By thinking about it from the very beginning of the product's lifecycle we then can feed it in throughout. As we moved into the delivery stage, when we start thinking about our cross-functional requirements, so how we'd like our system to be, we can state that we'd like it to meet a certain WCAG, WCAG being the Web Content Accessibility Guidelines. We're currently at 2.1 and a good standard is the AA standard, and from there the team can start building accessibility into the user stories and at a more granular level depending on what stories are coming up.

Scott Shaw: Are there any techniques that you've found to be particularly useful, especially in those early stages, in the design stage?

Kate Linton: I think that during the design stage, it's just really helpful to talk to people with disabilities. At Thoughtworks, we've interviewed probably around 30 of our colleagues who have disabilities. We did that primarily to increase awareness around what it's like to engage with the world and use different digital products and services with a disability. Through talking to people, it just becomes far more real. It's much easier to appreciate some of those challenges.

During the design phase I would always encourage designers and researchers to talk to people with disabilities. At Thoughtworks, we work with external organizations to help us find those people, organizations like Intopia in Australia, Vision Australia. I think we all know people with disabilities. I certainly do in my own life, and so it's not too hard to find these people and observe how they use technology. That's really the starting point. If you're not doing that right from the start, then it's going to be hard to really develop a good understanding of what the experience is like for them.

Certainly watching someone with a disability use the product that you've designed is really quite illuminating. That would be the starting point for me, with design. Then of course later on we need to think about how we're going to test this product with people with disabilities and making sure that they're part of the process will really help ensure that you're designing for them and with them.

Prem Chandrasekaran: Wonderful. Are there means to automate the verification process? The testing associated with accessibility? What does it look like in this space?

Katie Peterson: Yes. Definitely including automated accessibility testing throughout development process can help you really quickly catch many accessibility errors before you deploy them. A great way to get started is by setting a baseline for your site, using the frequently visited pages or the critical user paths, so you know what common accessibility issues currently exist on your site and you can use free tools like Lighthouse for Chrome or WAVE for Firefox, which can provide you with a full audit of the accessibility of your pages.

It'll also let you know about performance as well so it's a great tool. There's also tools like tota11y, which again is a great tool that can let you know what the common accessibility issues are on your site. It allows you to adopt a more data-driven approach to accessibility because then you have hard data around what the most common accessibility issues are. The tooling can't be solely relied on. It is great to get started with and to maintain throughout. You can add Lighthouse to UCI pipeline so you get that continuous accessibility auditing and make sure you're not introducing any regressions.

It's also a great idea to add unit tests to make exertions around whether your alt text is there. Although with alt text you do need to make sure that you are writing good alt text that describes the image, and you can also make assertions as well on your ARIA attributes. It's also a great idea to have end-to-end tests that can test for different interactions, such as a keyboard interaction or different user paths depending on the flow.

Prem Chandrasekaran: What I understand is that it's worth reading accessibility as a first-class citizen, a sensible default.

Katie Peterson: Yes, definitely. There's a few default practices that you can incorporate into your development workflow, such as testing with a screen reader. All modern operating systems come with an inbuilt screen reader and it's a great idea to become familiar with the one that's on your machine. Mac has VoiceOver, Windows has Narrator and NVDA and the Android equivalent is TalkBack.

Scott Shaw: I think that's a great idea, for people to try the screen readers out for themselves. Part of what Kate was talking about in the design phase is building empathy. I think that probably applies to the whole team, to developers as well, to understand how those things are actually being used.

Katie Peterson: Yes, definitely. It makes you see things very differently when you start testing with just a keyboard or seeing how things work with just a screen reader. It's also a great idea to become familiar with the page structure, and make sure that you are using semantically correct HTML, this tooling as well, such as semantics map can help. These are all free already in the browser. Just a really quick way to check whether what you are building is accessible.

Scott Shaw: I wonder if you can point to any examples that you've seen recently. I know there were some issues with accessibility with Australia's last census, the online census application.

Kate Linton: The Australian Census has always been a paper census in the past, and it gets letterbox dropped to every household across Australia. It was really over the last eight years that the Australian Government or the Australian Bureau of Statistics decided to start collecting this data digitally. Back in 2021, we had a good accessible experience. We actually did achieve an online census that met AA accessibility, and probably many aspects of AAA accessibility in terms of good color contrast, keyboard-only entry, things like that, but it was the census prior to that.

Four years prior to that, there was both paper and digital, and the digital experience was pretty bad for a range of reasons but certainly, there was room to improve on accessibility. We are coming a long way in terms of accessibility and it's certainly changing, but yes, it's very much a journey and there's still a lot of work to be done to ensure that we keep this top of mind.

Scott Shaw: Can we look at accessibility as a benefit to other aspects of our business? For example, is it helping us to think about things differently and innovate?

Kate Linton: I think it's absolutely an opportunity to innovate. There's so many examples of innovations that have started out being a solution for people with disabilities but have ended up benefitting everyone. A really great example that's top of mind for me over the last couple of years during the pandemic is just closed captions. Closed captions are essential for people with hearing impairments or people who are deaf, but they're really useful for everyone. They're just such a useful innovation. When I watch television or Netflix, I just always have the closed captions turned on.

They're incredibly useful for people for whom English is not their first language or they're learning a new language. They're really helpful for people that just don't want to annoy others with the sound of videos that they're watching on their smartphone. Turning captions on is just an amazing capability that we all use, and particularly with spending much of our work lives on Zoom calls, and team meetings are all online.

Those closed captions are just always going to be useful, and we share those recordings with those meetings and the closed captions are helpful for everyone who's playing back that meeting afterwards. That's just one example. There's many more. Siri for example, is essentially a product that was originally designed to help people with disability, to help people who are blind, but we all use that. It's essentially a screen reader.

Scott Shaw: If I've got a team of developers, I wonder what some of the things I can do to enhance their knowledge and ability to build accessibility into the product. Are there some practices, some deep practices we could adopt?

Katie Peterson: Yes. A great way to get started is becoming familiar with WCAG, however, WCAG ironically isn't that accessible, but when your team starts thinking about accessibility, you can start thinking about default accessibility practices, such as just testing with a keyboard, using a screen reader, using some of the tools that we've mentioned to check the page structure and make sure that you do have sufficient color contrast on things that you are building.

Use the tool in that is already available out there, that's built into your browser and automate testing where possible using your unit tests and new end-to-end tests and integrating it into UCI pipeline. It just becomes part and parcel of the way that we work. Accessibility really is a springboard for innovation and when you start thinking with an accessibility at the forefront of your mindset, it really is incredible work that allows your organization to grow. It enables you to build products that are more usable by everyone, not just those with certain disabilities.

Scott Shaw: I think of it as an analogy to security and the way that we manage security on our projects. Often we'll appoint a champion, we'll appoint one person on the team to be that advocate and always be looking after, making sure the rest of the team is thinking about security. Is that something you can do with accessibility as well?

Katie Peterson: Yes, definitely. The skills that you need for accessibility, it isn't a particular role, it is a capability. Regardless of whether you do have an accessibility expert in the team, there's things that everybody can start thinking about, such as disability research and accessibility design, and your HTML and UCSS and automated testing and manual testing, and by adopting a accessibility mindset, you really are creating a more usable experience.

Scott Shaw: That's great. Any closing thoughts? Anything you would really want people to take away from this and remember, in the area of accessibility?

Kate Linton: I guess for me, having been on an accessibility journey over the last year and tackling things like our own website, where we've really been focusing on improving the accessibility, it really is a journey. I don't think we're ever going to be 100% perfect at this. We're learning all the time as we go. I would just encourage people to focus on the small things that you can do to just get better, and things like- I often remind people on social media to include an alt tag when you are uploading images to share.

It's so easy to do that now. but people often don't realize that they can. It's those little things that are slowly shifting the needle. You need to start somewhere, and so if we could all just be a little bit better at delivering accessible products and it'll make an enormous difference over time to the people who are using those products.

Scott Shaw: Katie, what's the one thing you'd want developers to remember about accessibility?

Katie Peterson: I would like developers to know that the tooling is already available in the browser at the moment, and it is really quick and easy to check. Also, becoming familiar with a screen reader is just invaluable because it provides you feedback. You would never ship something without seeing how it looks. If you are going to build it with CSS, you can apply that same mindset as well to making sure that you are testing with a screen reader.

Scott Shaw: Thanks. This has been really enlightening, and I appreciate you all taking the time to be with us today.

Katie Peterson: Thank you.

Kate Linton: Thank you.

Prem Chandrasekaran: Thank you very much. On the next episode, Ashok and I will talk to Prem and Karthik Krishnan about their new book Domain-Driven Design with Java - A Practitioner's Guide. We'll discuss their perspective about how DDD has evolved in the last 10 years and some key learnings. Hope you'll join us for that conversation.

[Music]

[END OF AUDIO]