Making technology more equitable by shifting accessibility left — Kate Linton & Katie Peterson
- Now, when we started out today, we talked about making technology better together. And I think our next talk is a super exemplar of that work. - Who do have we have Nigel? - Well, I'm going to introduce Kate because Kate and I hang out a bit. So, I know her the better of the two, although I'm going to get to know Katie pretty well soon. I think Kate goes by the pronouns of she and her.
So, that's pretty simple to keep it going. She's our Head of Design. Kate has a brazen disregard for time zones and foolishly works all over the world at all hours of the day, which is an amazing thought worker capability to somehow be compass mentors at 3:00 am for a design meeting.
Or look, if I run back over here, this gorgeous pink forward slash, I've got the wrong term for it, but that's what I would call it. Again and I went out bleak. And so, that's another one of the many things she's done. She's a mentor, she's a teacher.
She gets her hands dirty all the time. She helps clients. She helps all of us. And so she's part of the pair who are going to do an amazing talk today on well, I'll hand to you to explain them, - Along with Kate. - Finish off with Katie and what it's about. - Yeah, we have Katie Peterson. She goes by pronoun she or her.
And she actually changed her career to technology and joined as a graduate developer. And she now actually leads the AsiaPacific front-end community. She's very passionate about building products that are more inclusive and tries to kind of, improve on things every single day. And we have them here to share, represent the teams or championing the next generation of sensible defaults, trying to shift the accessibility left. And pretty much like both of them battling the refrains of it's very difficult or it can't be done or we don't see a need in it, and let's see what they've actually been through. - So accessibility, why are we even talking about it? It's not like it's new. It's been around for a long time.
But we think the reason why it's in the spotlight at the moment is because of the pandemic, COVID, that little gift that keeps on giving. It's forced us over the last couple of years to all work from home. And we've been doing everything online. Our work lives, our shopping, our social lives.
And so, businesses that can't offer equal access to their products online are falling behind. But accessibility and the need for it has always been around. The why occasion, Katie and myself qualified to talk about this, well, we've been focusing on accessibility quite a lot over the last year or two.
And the thing about accessibility is it actually takes a lot of different capabilities to be able to deliver accessible products. So, I'm a designer. I do a lot of design research, a lot of discovery work, and Katie is a developer, full stack, but particularly good at the front end staff, particularly good at the HTML. And you need a range of different skills to be able to make your digital products accessible. So, I said that accessibility is not new. This is Tim Burners-Lee, inventor of the internet.
And it was always his vision that the internet would be accessible to everyone. He says here, the power of the web is in its universality, access by everyone regardless of disability is an essential aspect. So, that was back in the mid 90s. And that was why he went on to establish the Web Accessibility Initiative, which gave us the web content accessibility guidelines, or WCAG.
And they were developed for people like us, people who develop digital products and services and create digital content. Now, Thoughtworks has been around for 30 years. We're actually older than these guidelines. So, you must think we'd be all over them. But it turns out we're actually not that good at it. And we suspect that a lot of you probably aren't that great at it either.
And over the last couple years, we've been trying to improve our own capability in accessibility, which is why we feel that we've got some things that we can share with you today. But first, let's talk about disability for a second. So, who's disabled? The World Health Organisation estimates that it's around 15% of the population, it's well over a billion people. So that's a lot of people. And if we just think about visual impairment for a moment, that's a lot of people who are blind or have a permanent visual impairment like colour blindness. There's a lot of visual impairments.
But in addition to that, a lot of us are temporarily disabled. If I just take my glasses off for a moment, I can't see very clearly the people at the back of the room. I can't read my notes up front. That's a temporary disability. And that's like 50% of the population.
That's everyone over 50. In addition to that, there's situational disability. Who's tried to look at your mobile phone in really bright sunlight? It's really hard to see. Another really common situational visual impairment is just intimate and wifi.
We've all experienced that. And the images will be the last thing to load when you've got poor data to your device. So, it really can affect everyone. Now, let's think for a moment about auditory disability. And let's talk about an innovation that's been around for a while now, but something that we've probably all been a lot of over the last couple years and that's closed captions.
Now, my hearing is pretty okay, but I use closed captions a lot . And often it's because I just don't have my headphones handy and I don't want to annoy the people around me. So I actually choose to turn the sound off and use the closed captions. We've all been using them on Zoom calls and we use them all the time. They're enormously useful for pretty much everyone. And closed captions are a really good example of what we call the curb cut effect.
So, the curb cut effect just refers to design interventions, specifically for people with a disability that actually can help almost everyone. So, in the case of that small ramp on the curb at a pedestrian crossing originally shows designed for wheelchairs, but it's incredibly useful for anything with wheels, prams, trolleys. And let's face it, no one wants to accidentally trip on a curb. So, it really benefits everyone. So, a lot of good reasons to ensure your products are accessible, but there's actually more. So if you are producing good semantic code, that's accessible and can be used by screen readers that disabled people use a lot, it means that it's also going to perform really well for search engines because they also rely on good semantic code.
So, who doesn't like pre advertising. So, so many good reasons to just make sure that our digital products and services are accessible. But there's more. We don't like to draw upon this last reason and it shouldn't be your motivation for making sure your sites are accessible, but it's actually enshrined in law in a lot of regions.
In Australia, we have the Australian Disability Discrimination Act, which actually makes it illegal to treat people unfairly because of their disability. So hopefully, you won't have to draw upon that as your reason for doing accessibility, but it's a good reason to keep in your back pocket if you are having to debate this with leadership. Because most organisations actually have an existential fear of being sued not so much because the cost, but it's the reputational damage. No one wants to be known as discriminating against disabled people. So that's just something to keep in your back pocket, but it's another reason. So, then why is it that 97% of websites, according to WebAIM, which survey the top websites every year, why is it that 97% of them aren't fully accessible? We, when we speak to product teams, the reason that they often give us for why their product or service isn't accessible, is because, oh, well, you know, management don't see the value.
They don't want to pay the extra money. They know it's going to take extra time to deliver an accessible product. Well, we don't believe that. I mean, opening up your market to everyone, to the extra 15% of people that have a disability, I mean, that's huge. There's an obvious return there. So, we think that's just an excuse.
We think the real reason why those 97% of websites and similar number of mobile apps, we think the real reason they're not fully accessible is because product teams don't know how to do it. We just don't have the skills. Now, the good thing about that is that's something that is in our control. We can fix that. And that's what we are really talking to you today about. But to begin with, let's just look at this very simplified view of the product development life cycle.
It starts usually with research on discovery. That's something I spent a lot of my time in. And then you move into delivery and you deploy and maintain. Now, where we see accessibility being addressed in that product life cycle is very often after you've deployed the product, after it's gone live.
And we think that a lot of product teams are quite focused on just getting it out there, just shipping it. They're in this minimal viable product mindset. They don't want to gold plate it.
And so, they think we'll just retrofit it on after we've got it live. The problem with that approach is that it's going to be really expensive and really time consuming to do it that late after you've delivered the product. And a much better way to go, really the only way to ensure that your product's going to be accessible is if you shift left and you address accessibility right from the start, right from discovery. And so, we're going to talk through what that looks like, and we're going to use the example of our own website.
So, this was our website well over a year ago. And you'll notice a couple things. Firstly, it doesn't have our current logo on it. So that was one of the goals with updating our website, was to rebrand it with our new visual identity. But we also wanted to rebuild the site on a new CMS.
We were on our old custom CMS that we built in house and we wanted to move to Adobe Experience Manager, AEM. So we're rebuilding the site, and we also had a goal that it needed to be accessible. We were aiming for AA accessibility.
And you can see here, this is how the site performed, the old site. So it was around 81% on Lighthouse. Lighthouse is a tool that we use in the digital team. It's an automated tool that measures the accessibility.
So, how do we go about addressing the accessibility side of things? So, I mentioned we needed to shift left and bring this as a primary concern in our research phase right at the start. So, what we typically see when people go out and talk to customers during the discovery phase is they have limited time. And so, they just focus on their most typical users. They focus in on what they believe to be the average user. And that's because they can't talk to everyone. Now, the problem with this approach is that there is no average user.
So, the more you start talking to your customers, the more you realise that everyone is unique and any one of them may experience a disability at different points in time. So, a far better approach to addressing this is to take what we call an inclusive design approach. And this involves looking at all of your users. And often when it comes to research and talking to people, the best way to do that is to look at the edge cases and to actually talk to people who have a disability and understand their specific needs and what their current experience is and how they want to engage with you. And if you can talk to them and understand their needs and design for them, you will be designing for everyone.
So, what we've got on screen here is what we call a persona. Personas are a model. They're representation of an entire segment of users, in this case grads, which are a very important user of our website. And what we've done here is we've had to think, how do we approach looking at the edge cases amongst our personas. Now, to begin with we made MRR grad female, which is actually slightly the majority of our grad candidates who approach us and look at our website for jobs. And we ensured that English was not her first language.
And we also wanted to incorporate some disability into this persona. Now you think, how do you do that because there's just so many different types of disability? So the way we approached it is what we call a disability overlay. So it's the one persona, but we look at that persona through the lens of different disabilities.
So what if Emma would had a hearing impairment, how would that change the way that she would need to engage with us and with the website? So, as soon as you user lets, you know, that captions are going to be so much more important, that all of your multimedia and video needs to be captioned. All of your podcasts need a transcript. And it changes the way you approach the interview process as well, which over the last two years has all been online. So, closed captions need to be turned on from the start. But what if Emma was autistic? How would that change the way that she needs to engage with us? So for autistic people and lot of neuro diverse people, they have their own challenges around language. So we need to think about the language we use on the website.
We need to avoid things like cultural idioms, metaphors, because they can be very difficult to understand for someone with autism. So, it changes the way that you write. So, these are examples around how we brought accessibility and researched people with disabilities into our discovery process. And now, Katie's going to talk to you about how we brought it into the design and delivery of the website. - Thanks Kate.
So if like us, you already have an existing product. Where do you even start with accessibility? It can be a little bit overwhelming as you start on this journey. So as Kate alluded to earlier, we used tooling. And the one that we used was Lighthouse, which is built into Chrome, but you can also use Wave for Firefox.
And with this tooling, we set a baseline and we found out what the common accessibility issues were that existed already on our site. Now, it is a great starting point, but it shouldn't be solely relied upon. Sometimes it can give you false positives and it doesn't actually tell you anything about whether your site is usable. But it does allow us to identify the common issues.
And the issues that we found on the Thoughtworks website are very common across the web. These being low contrast text. So in this image, I have some text and it's on a really, really pale background. So you may be struggling as you sit in the audience today to actually read what that text is saying. We also found that we was guilty of using ambiguous links throughout the website.
Things like click here, learn more, read more don't actually provide any context to the user around what the link is or where it will take them when they navigate to it. We also found that throughout the site, we used poor alt text. So alt text is alternative text, which describes to someone who can't see the image, what the image is.
So in this example, we have a head in which says, our clients include, and then the alt text says, our clients. It's not actually describing to you who our clients are. It is just saying, our clients. And this is the kind of thing that's actually quite difficult to automate because it's a human error.
We need to learn how to create good alt text that actually describes what the image is. So it just imagine you were on a radio show and you was trying to describe the image, think about what your alt text actually needs to say when you can't actually see the image. We also found that throughout the site, we'd used incorrect head in hierarchy. So here, we actually start with a H3 instead of a H1. And what this means is because screen readers generally read the site from the top to the bottom.
If you don't use the correct heading hierarchy, it can become nonsensical and you'll just start jumping around the site. We realise that we'd put a little bit too much flexibility into the site and we made it possible for people to use the headings that they liked based on the style only not the semantically correct one. We also found that throughout the site, we had purely decorative images.
So, they don't actually convey anything to the user at all. They're just patterns. We don't need to provide alt text for these images and we can just provide null alt text. So, because we use a CMS, we provided content creators, a way to communicate that this was purely decorative using a checkbox.
And this way it allowed screen readers in particular to just silently pass over the image, because it didn't need to convey any information to the user. So, once you've established the common accessibility issues on your site, how do we ensure that teams are empowered to improve the accessibility practises? A great place to start is by defining them as your cross-functional requirement. So a cross-functional requirement is a standard in which you would like your product meet. You could have auditable cross-functional requirements or security cross-functional requirements. It's a great place to find your accessibility standard.
So in this example, we have the system shall comply, shall be accessible to comply with WCAG 2.1 standards. Now, it is great if your team can become familiar with WCAG but ironically, it's quite overwhelming. And there's a lot of legal jargon on that. And there's a whole page on the website dedicated to actually understanding WCAG itself.
So, how do we put it more at a granular level? This is when you can start incorporating it into your stories. So, we could have a story using our identified user from earlier Emma, as a graduate developer. I would like to find more about careers at Thoughtworks so that I can apply for a job. So, we could have, given a user is on a homepage, when they navigate to Explore careers with us link, then they should be taken to the careers page. And we can embed accessibility into the acceptance criteria.
So we can state that it needs to be focusable with a keyboard when it does have key bold focus, we need to indicate that. And we also need to inform the user where the link will take them when it is clicked. So that sounds great. We've got us a cross functional requirement, we've embedded it into our stories, but what can you do tomorrow as a developer? And how do you start embedding default accessibility practises into your ways of working? We feel like these six practises enable you to build a more robust user experience. So these practises are, become familiar with only using a keyboard. Get rid of your mouse and see how you navigate around site.
Also test with a screen reader. Check the page structure of your page and whether it is semantically correct. With all the things that you build, do they have sufficient colour contrast? Also use the tooling that is already available out there. And automate your testing where possible. So, let's go through some of these in more detail.
Use only a keyboard. Try and navigate around your site with your eyes closed and navigate in with just the keyboard. As you do so, as yourself, are all elements reachable, and particularly usable with just a keyboard? Do all elements have a clear focus indicator? And is Tab in a logical order, or are you jumping all over the page? You can also use the built in browser tooling. And so, in here I am within Inspect in Chrome, but most modern browsers provide this functionality.
And you can check to see whether it is keyboard focusable and it gives you that instant feedback that you can provide to the team to let them know whether the element is actually focusable. Become familiar with a screen reader. So, all operating systems have a screen reader built in. Within Mac, we have Voiceover, within Windows, we have Narrator, for Google, Android equivalent is Talkback. And there's also quite a few commercially popular applications out there like JAWS. When you activate your screen reader, see whether the elements are reachable, understandable and usable.
Can you actually perceive what they are trying to tell you? Do all images and multimedia have alt text? and is navigation logical? A great thing to do is provide a way to skip navigation within your site as well. And you'll quickly get that feedback from using a screen reader. First hand experience with a screen reader is really, really invaluable. Make sure that the behaviour you're expecting to see is actually the behaviour you would like. So for example, with the link, is it reading out the link correctly or are you hearing something that doesn't sound quite right? As a develop, it really is quite unthinkable to release something to the website without having checked it on numerous browsers. Apply the same content to anything you build and always test with a screen reader.
Check whether your page is semantically correct and you using HTML elements appropriately, and that your heading hierarchy is representative. Headings are used by screen readers as a way to scan the page. And they allow you to move to the section that you're interested in. If your page isn't structured correctly, you could be sending people all over the page and it just becomes nonsensical. Ensure that you separate the meaning of your site from the style. It's actually quite fun to use some of the tools out there to turn off the CSS, of not only the site that you're building, but other people's sites as well.
See what happens when you do turn off the CSS. And there's plugins such as Web Developer and also HeadingsMap that allow you to do this. As part of our visual identity refresh, we change the entire colour palette to make sure that we could meet our accessibility goals. It's always useful to check the colour contrast of the elements that you're building. Even if you have been providing the colour palette from one of your team's designers, you stock or build in browser plugins that allow you to have that feedback really quickly. And also, don't rely solely on colour to convey meaning.
Use colour independent indicators, like shapes or text to make sure that you're not solely relying on colour to convey information. Again, you can get this information really quickly from the already existing tools. And then you can provide that information to your team and have them conversations about whether you are providing sufficient colour contrast. So, we're a developer. It's always great to use the tooling that exists. Include automated testing throughout your development process, and it will quickly catch issues for you.
Ideally, we want to catch issues as developers before our users report them to us. And if you keep checking back with the tools that are available, it's really, really satisfactory to find that you have reached 100% on your accessibility stores within Lighthouse. Caveat is to always use ongoing manual testing as well, and use the testing where applicable to make sure that you are reliably addressing accessibility throughout.
So, it's also really useful to use tooling throughout your development life cycle to ensure that you don't get regression and that your product remains accessible. So, one of the ways we can do this is introducing accessibility linters into our code, such as AccessLint and X Linter. Use unit tests to make assertions on the area attributes and the alt text throughout your code.
Again, make sure that you are writing meaningful alt text though. Use end to end testing to validate the state changes and the user behaviour and interactions throughout your site. And also you can look into acting tooling, such as Lighthouse to your pipelines that ensures that you are continuously looking out for any regressions that could occur within your code. So now, I'm going to hand over to Kate who is going to talk us through specifically, who is responsible for accessibility on your team. - Okay. So, whose job is it anyway? I don't know about you, but I've never worked in a product team where there is an accessibility expert who was able to do all of this.
The chances are that everyone on the team is going to need to pick up some of the skills required to make your digital product or service accessible. And we've spoken about some of these skills that you will need. There's during the research phase, who is going to go out and talk to your users and make sure that you talk to people with a disability? Who's going to do that? Who in your team is going to be responsible for ensuring that the design meets your accessibility goals? Who will be responsible for ensuring that the HTML is good, semantic HTML, that will ensure that your site is accessible? And then you've got all of the testing. There's the user testing.
You should be testing with people who have a disability. You should be ensuring that you do both, the automated and manual accessibility test. You need to do both because an automated test will not pick up that you've got rubbish alt text. So you need to think more in terms of the skills instead of the roles because within a product team, all of you have some level of responsibility and can pick up different aspects of this.
In addition, there's also the ongoing maintenance of your site. In case of the case of the Thoughtworks website, we have over a hundred people across the organisation who are responsible for uploading content into the new CMS. So, every single one of them needed to be trained on accessibility.
So, we developed the accessibility handbook for marketers and we delivered training to every region and function within marketing. And that's an ongoing process. It's also part of induction for marketers now.
We also introduced an accessibility checkpoint into the workflow in AEM. So now, before a page or content can go live, it needs to be checked by someone in the team who understands accessibility. But what can you do today? There's a couple of things. Firstly, if you're a social media user, then we hope you're going to be sharing today's talks and you might want to upload an image.
Now, social media apps make it really easy for you to add alt text to your images. When was the last time you actually stopped and used the alt text field on your social media images? And really think about the alt text, how would you describe that image to someone who can't see it? The second thing you can do is take advantage of all of the existing accessibility readers that you have on your device that come for free. Go into your phone and look at the accessibility settings. And look at your own website, your own products, see how they're performing. Download one of the many free accessibility tools that are available so that you can see how your site's performing.
And for our own site, it's an ongoing concern. Our site isn't there yet. We've made most of the landing pages accessible, but it can change from day to day. So it's something that you can continue to monitor and look at. In summary, you need to be continually promoting the value of accessibility to your leadership, and you need to bring real data about disability into your research so that you have a really good understanding of the very specific needs of people with different disabilities. And that data is available.
The World Health Organisation, the Australian Bureau Statistics, it's available user. You need to think about your default practises within your delivery team. And you need to bring ways of working around accessibility into the team. And you need to identify right from the start, who is responsible for those different ways of working in terms of ensuring that accessibility is brought in from the start. And lastly, you need to address your capability gaps, because we all know that we're still learning. No one's an expert and we make mistakes.
In summary, we wanted to finish with an inspiring quote. So, this is Haden Girba, who is the first deaf blind lawyer graduate from Harvard. And she's a real disability activist and an advocate for the rights of people with disability. She says here, "When you do disability accessibility, you're not doing charity. You're giving powerful work that helps your organisation grow. It helps you reach more customers and it drives revenue."
So we need to entirely flip the conversation around accessibility from being a cost, to being the amazing opportunity that it really is to reach all of your users. So, thank you.