![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
amazonv Integrating Accessibility Into The Software Development Lifecycle
Type: Breakout
Track: Development
Championing a culture of accessibility can be difficult. It is especially daunting when you are the only one in the organisation who seems to care. In this talk, I will cover different approaches that you can take to improve the accessibility culture of your team as well as the accessibility of your products.
>> Thank you, Ryan. Hi, everyone. Welcome to Integrating Accessibility into the Software Development Lifecycle.
So who is this talk for? Had it's for everyone involved in development of products from product developers to product managers, product owners, UI designers, UX researchers and testers and anyone, all stakeholders even investors and founders and thon technical founders-- everyone should be -- this talk is for every one of you. If you're in the audience-- I'm glad you are here. A little bit about me, my flame is Segun, I'm a software engineer, I live in lagos, Nigeria. You can reach reach me on Twitter.
What is a software development lifecycle? It's the series of snaps that are used to create software products. And the commonly defined sets are first of all, identifying current problems or product requirements, come up with a plan then design based on the plan and then build it that will transition from building to testing. Testing what has been built fulfills all the requirements and solves the current problems. And if our tests are satisfactory, feature or the product or the solution goes into maintenance mode. And this is a cycle. So it's repeating and going onto the next-- and we have different approaches for that which is beyond the scope of this talk. And here's infographic showing an alternate version where you have the planning and analysis of the problem or analysis of whatever you came up with during plans and you design and implement test and integrate with your current product. So and then you move on to maintenance again. So the cycle continues again.
So what really is the problem? From the steps defined earlier, they should be able to capture all the problems in a software product and solve them and address all, any problem. Because if you can identify the problem then we can solve the problem in most of the cases? What is the problem? The problem really is accessibility is usually not defined as a problem. Most of the time, the product will go into product lifecycle and we identify all of the problems inned product and things we want to solve and ignore accessibility. So even when for large part of the population for for users, a product is basically difficult to use or worsen is their quality of life, we in the team can consider that product and feature done while negatively impacting our audience. Why does this exist? Why do we have this problem?
And for the most part, in my experience, it's usually just the fact that, if you do not experience it, you do not know it. So people creating products do not suffer from debilitating disability. So we're blind sided from the realities and software engineers and designers who do not even know that there is a thing called a screen reader like I'm not exaggerating. That happened last week while I was reviewing some code and explaining why the code needed to be refactorred. And this developer, engineer, asked me what is a screen reader. I assumed they knew what I was talking about in the comments. So I had to get on a call and with them and show them what a screen reader was. And asked me what is the point of the screen reader? Oh, yeah, there are people who can't see the way you and I can see. There are people who are blind and they still need to interact with software. 13456BG they need to mainly interact with software more than you and I need to. Because for example, I can walk down to the store easily. * it's a lot more convenient for someone to avoid traffic if they can see or hear the traffic oncoming. But for someone who can't, they can easily order grocery,ing order shopping from home. And for them, software * is more important and we need to build it to where it caters to them.
So because -- the problem is because the majority who are blind sided by this problem, from this reality, we-- sorry. I'm going to go over that again. Being the majority and being blind sided by this problem, our biases and ignorance has shifted development culture and values and what is important. For example, what do we define as a good user experience? A lot of time someone says sleek UI, fluid animation. And these are all great and when done properly can be really be access I am. Often times we define these in a way that could be even-- unfruitsful with people with disabilities or other problems.
So this is why the problem exists. And I'm going to paint a scenario, Miriam needs to get groceries. But she can't go out to get them herself because he's visually impaired. And (READING). I live in Lagos, nitrogen nitrogen. This is typical. And also we're in the middle of a pandemic. She decides order online. And fills the cart with things she needs, jumping through many hoops because the site was not designed for her in mind which are-- because she's using the screen reader or babe the text is too small, not enough contrast. It can he ee numb rabble. She tries to check out. Someone who is a screen reader can't check out because the site, the check out button is not really a button. And so * it is not-- it can't take focus from a screen reader. And while this might seem an extreme scenario, it is a real one. We had a few-- we had the lawsuits for Domino's pizza some time ago because someone could not check out. We've had several cinema cases in different countries. And these are common. These are common. Sometimes it's a closed button with an icon and-- and it works if you have a -- only if you use a mouse. If you can focus on it. And even at that, it is not enough padding around it to make it tappable-- so people who have big finger iters or people who have tremors like people who suffer from Parkinson's disease-- you're making them focus on something very tiny because that's what the design says or because maybe as a developer you don't realize that there are people who interact with the web but not in this mainstream way of using, tapping on a touch screen or clicking the mouse.
So what failed Miriam in this scenario is did the UI developer? The product owner? Testers? Had everyone in this software development lifecyclehas failed her. When I prepared this slide, I said in a different scenario I said it could be -- emergency service. A few weeks ago there was a news on Twitter that the vaccine sites in the US were not accessible to people with disabilities. And it was being investigated.
And that's a real-world situation there. I don't think-- it was inspired by a evil team or evil developer but built by people that didn't depend on Assistive Technology or on very accessible sites for them to function. So they-- affecting people in realtime in real-world and the quality of life of people.
So how do we fix this? If you're here, you obviously care about accessibility. So you will be-- you are the champions that are going to help champion the new culture of accessibility of building accessible products. And you won't be able to do it 0 alone. If you're the only person that cares about accessibility in the company, it's going to be an up hill battle. So the greatest weapon at your disposal would be to educate others.
So yeah. Our greatest weapon is to educate. We would need to be patient and kind and gentle even though we also need to be firm while getting people in the right direction. It's not going to be easy for some of us.
So where do we tacklethis problem? I have six steps of lifecycle. At what point do you model it? At the beginning-- [Off Mic]
accessibility encoded as a screen reader I should get to log in. As a user, I need to Zoom in the screen to 200 percent encoding that in the requirement. And sometimes those requirements are not -- are not given by developers. Sometimes at the design change, you have to ensure that, before a design moves forward or is under the developer is accessible or explain what are the problems. It shouldn't just be oh, our site is not fancy enough or sleek enough. Yeah, while that is important because you need to get people's attention. You need to use animation to direct people's attention to the most important, you should also be able to, as we're gathering those requirements we should be gathering the accessibility requirements as well. Okay, for yeah, we need more fluid animations but also we need to be able to turn them off or opted out of them. These should be requirement to creating animation.
* we have a request to create, let's say, let's say a banner, for instance. Okay, part of the accessibility should be like, whatever message or call to action is also possible to non-mouse and nonvisual users, keyboard users, switch users, screen reader users, all of them can interact with these things and can actually get to the same goals which comparing things-- so to have this holistic solution, accessibility has to be a first class requirement at every point of the software development lifecycle.
So it has to become what, part of what we think of when when we do it. It's not something we try to hook in when we have a problem or when we get a lawsuit. It should be part of the whole process. When we're seeking what needs to be improved and can done, we should be seeking how these are impacting people who have-- I like to call it alternate experience of our products.
So notes from my personal experience because I have worked with teams who, you know, had no idea what you're talking about when it comes to accessibility. And I've had some-- I have experienced push back at some point by well meaning people.
I remember two years ago, I was leading a team. And the team were junior developers. And part of the requirements was every feature has to be fully tested with screen reader and keyboard to ensure everything is accessible. And one of the team members said to me, why are you doing this? I said, yeah, because people-- not everyone interACTs with applications the way we do. And he said-- I said, blind for example, if you're blind, you cannot use a mouse and a screen. You need another way of accessing the work. He said, honestly, he said, but I'm not building for the blind. And I had to educate him, take 30 minutes sit him down and explain you're building for the blind. The blind is-- the blind are required-- should enjoy the same experiences or similar experiences -- you need to do the same thing as you and I. And I said-- I asked him, if something happened to you today and you lost your sight, what would you spend your time doing? And he never thought about it. I said, more than ever, you will need digital experiences because you'll be cut off from other physical experiences. You can't go to see a game but you could experience it from home on your audio. You can-- because your interaction in public places are limited because you can't easily protect yourself especially in a place like Nigeria where there are provisions for people who have come disabilities. Yeah.
So for such people, digital experience has become more important, more imperative and it will be just terrible to ruin that for them. So we need to take more responsibility with that. So yeah, be prepared-- sometimes it's just sheer ignorance like honest, innocent ignorance. And that sometimes, on occasion you have a person who just doesn't care. But in my experience, they are like the exception. When you make your case and make it with empathy. Try to understand where you're coming from. One mistake people make is trying to vilify the opposition, hey if you don't do it, you're an awful person, a terrible person. And sometimes people think accessibility requires more effort than it does. So they basically say, oh, we don't have time for that now, so we can come back to it. And especially where they don't have, we're don't don't have repercussions is to do it immediately, you're willing to understand where they're coming from and educate and guide them because a lot of times you can get good accessible, you can go far -- it's like the-- principle. We've-- 200 percent of the effort you can get 80% of the good result. Sometimes you might have to settle for good enough instead of excellent. But it's-- but still -- still keep pushing. Because the idea is to change the culture, to integrate it at every step.
And the more-- as the culture changes and more people buy into the idea or more people begin to get involved, for example, if you had QA testers, testing -- or never tested for accessibility, start testing for accessibility. They can find bugs for accessibility and become things that need to be done.
Designers who are now accessibility conscious and begin to consider that, maybe push back when there were requirements to do things that don't make sense like disability. So getting -- that's why I said earlier, the biggest weapon at our disposal is education. If you can educate and get more people to buy into the idea, then you can have like-- you get people to buy into the thought process, into the culture of considering people, considering accessibility best practices all the way, then sooner than later it becomes ingrained in the product and helps people get better experience with the products.
So sometimes what arrangements do you have to make? How do you convince people? For example, earlier earlier as a team lead I had to sit my team down and explain to them. And I was able to say, well, these are the-- [Off Mic] so I could do that. If it doesn't meet these requirements it doesn't go forward. And that's actually one of the great things when the team lead, when the person, people leading teams or key decision makers are conscious of accessibility and the need for it and best practices. So you might be a developer and you don't make toyings. You'll probably be an engineer or designer-- engineer designer and you don't make the big decisions. But if you can get someone higher up to understand what you're talking about and show them how achievable it is, then it can become a part of what the team does.
I'll give you an example. I remember in had 2018 I was working with a team and asked, how long is it going to take to build X? And it's an estimation. Because they knew I was all about accessibility, the product owner asked me, how long is it going to take if we leave out the accessibility and come back afterwards. I said it will take the exact, same time. And I said, because making it accessible from are the get go takes like maybe just a few extra minutes for each step. So it's really not that much many of an overhead. So I gradually, this kind of question just disappeared because it just became, okay, we're going to make it accessible from the get go. And that was a way to win my team over or like, or the manager. And so it became part of what the team did.
So if you're like a team leader like I was then, you could basically say, give technical arguments. This is what we do here. This is the standard for us. It's-- sub participate if it's not accessible. This might not be a good argument to make on the business side, this is a good argument to make with the team saying this is how to build products. This is how to build UIs and get the buy in of team members and colleagues because you're setting what is the technical argument here. This is -- if you don't build this way, you're not following best practices. And yeah. Technically people like best practices. So the other one is moral argument.
The moral argument is that it's just the right thing to do. Like I said earlier, for people who have debilitating disabilities, experiencing the world like those who don't have disabilities is not an option for the most part. For example, if it-- for people who are wheelchair bound, I was talking to someone earlier, I said in my country, banks are required to have a certain level of security. And that security prevents wheelchair users from accessing commercial banks. So a wheelchair bound person can't go into the bank without someone's help. They simply can't go in without someone else getting them through
>> Other means, regular means they can. I don't know how they go to the bank if they do. And so using mobile bank-- mobile applications for most banks in Nigeria have mobile applications that people access most of their banking transactions activities from the phone. For people who can't easily into the bank, such software is very important for their day-to-day experiences. And yes, it's very cash society, still doing leg bank-- credit cards are very- kind of like exotic here. We don't even do credit cards. So yeah, still you need to do cash based transactions with people who are disabled can do that from the come format of their homes. As a matter of fact you have short codes you press in your phone that work without an internet and people can do transactions from their banks with short codes on their mobile phones.
And the tech that follows that has made life easier. Now, imagine such applications are built in a way that people who are disabled can't use them? That's just -- at this point it's becoming evil. So yeah, so that's why it's the right thing to do. Our products should be built-- we shouldn't marginalized people who are already marginalized because of their circumstances.
Now the business argument, what you can make if you have to convince the people who sign the checks, for example, this is in the UK, there's something known as the purple pound which is the spending power of disabled people and their families. And it's estimated as of 2020 to be around 274 billion Euros. -- pounds. It's pounds. UK. Yeah. And that amount is rising steadily. So that's a lot of money.
And it's estimated that about more than 4 million disabled shpers click away from a website because they simply cannot. You go on YouTube and search blind shopping. There are a couple of people who blind bloggers who are have their experiences of shopping online. Many times at the actually get to help them. Many times it's just -- it's just more work and makes them less able to do anything they want to.
And also another argument you can make is that accessible sites tend to have-- can drive better traffic to the company and product. And definitely there's a legal part, I can split makerring a different argument dark -- people who sign checks don't wants legal problems. So let them know that, hey, not only are we doing the right thing? We're doing this is protecting business from lawsuits, from unnecessary expenses and as a matter of fact, refusing to-- making a product accessible is another thing you leave money on the table. Like I said earlier you might not be able to win every one at every time. You must understand that still, while you need to do to work, you need to convince people. It's okay if all you got was some but not all the way in. Because while 100% accessibility, some accessibility is still better than no accessibility. So if you don't get any enrollment, just keep doing the good work only your own.
Keep adding your bits here and there. If you're a designer, a little bit here and there. If you're a product owner, a little bit here and there. Product manager, same. Developer, same. Just keep doing your bits and making someone's life a little less terrible. Thank you.
>> Fantastic presentation. Thank you. Really appreciate your time. I think everyone in CHAT is very much identifying with your experiences. You know, I think your message of education and especially patience seems to be really resonating with folks.
Some folks may be not having the patience that you have.
>> Yeah.
>> We do have a few questions in here. And I'll just remind our viewers to put them in the Q&A section. And I'll make sure the top questions are addressed quickly here.
So the most popular question is something you, I think you really just finished talking about, but might be worth reiterating. So this person's asking, when dealing with external stakeholders who are pressuring for fast, for speed, foreign the release of a coming service, what strategies can you offer to help soothe that person into a position that you know, doing this right will actually take less time in the long run. What other strategies do you have? I know you mentioned a few. But with regard to, I think the personnel you're dealing with internally, maybe you can take that angle to this question. Which personnel internally are you dealing with to maybe have some success in this way?
>>
>> Okay, um, well, so when I talked about my product owner a few years ago, basically said, um, can we refuse to do the accessibility part and focus on the functionality? And how long is that going to take? And I said, it would take the exact same time, right? Because, I think, like I said earlier, the divide is usually that people think it will take more time to make something accessible. And sometimes yes, it does. But it's about giving people the idea that, like on understanding where they come from are. Okay they think it's going to take more time. They think that accessibility is going to make it faster and access slowing us down-- you need to understand that okay, this is where they're coming from and this is what you think about this problem.
And from then, you decide, okay, who am I talking to firms of all? Because like I said, there's an argument made for different people. If it's a technical person that is that said, oh, yeah, do it fast. Build it fast and let's go and we can come back here to do it. And then you turn -- one example, like I said, your argument asks to tailor who I'm talking to. You can let them know, hey, this is not good quality code. You do know that, when we have technical -- it will slow us down thought long run. And that could-- that could become a business problem because we get-- because the product -- the company gets sued because we're-- laws, depending on the country you're in.
If it's-- if-- I know people say, yeah, let's just rush especially when you're working with start ups. Everything's always like-- some cases, no matter what you say, whoever you're going to talk is just not going to listen. And that's why I said that, if you can't get buy in, you still do the bits you can. You might not get it as far as you want to get it, but like I said, with the resource tricks you have, you can still have some accessibility out there. You can still lay grounds work for your improvements even though you may not be able to get 100%. The truth is, if you don't do it, someone else who is going to do no accessibility at all and worsen people's lives.
For example, we had this vaccine stuff. We probably wanted it out there because old people should be vaccine natures. But in the process -- I have no inside information. But in the process they're basically cut off a lot of people who need in even more of-- if this was a private company, they could be in a lot of mess. I think it was-- the government site -- websites and they were -- I don't know the process in the US. But there were ways to deal with that.
So yeah, so what I'm saying-- I'm jumping in different places. Some of what I'm saying, you have the argument of who you're talking to and decide which strategy is more likely to convince this person. Is this person more likely to relate to-- if you're talk to the tech person -- the problem of technical-- [Off Mic] but it can become something that you have to agree entirely to be able to make accessible later and that is a big problem for the team, for the product, that's is going to take a long time. make the argument clear to be able to win them over. Someone on the business side, tell them what they're exposing themselves to, what money -- what they're leaving-- money they can be leaving on the table as well as the litigation they could be inviting.
>> Appreciate that. I think there are actually a lot of questions similar to that one. And I think you helped answer quite ail fuel in your explanation. Thank you.
One question I'm hearing here, and you alluded this to a little bit. You in the United States we have the Americans with Disabilities Act. We have section 508. We have a legal requirement. You mentioned the Domino's. Would Domino's with practicing legal disability if not for that lawsuit?
You can lead with the carrot or the stick approach. And the United States the unfortunate reality is most folks practice digital accessibility because of the stick approach. Without an ADA equivalent in Nigeria, how is your situation different? Are you -- do you only have the carrot option available? And do you find that to be easier or harder to tell digital accessibility?
>>
>> Yeah, I think here it's more of the carrot than the stick because we don't really have much many enforcement in terms of the law. One of the advantages-- I won't say advantage, the uniqueness of my situation is I have had experience to work with people all over the world and different continent. The difference in the experience all over the world and legal provisions.
But yes, how do you-- how do you incorporate that in Nigeria? This is one big problem with start ups in Nigeria. Everyone's trying to rush to market and get something. And many developers tell me, oh, uh, I wish that they're more interested in accessibility otherwise they will be able to build more accessible products. And I said, if you can't get anyone on your side to ensure accessibility, you might not be able to get management onboard but you can get the team onboard. You can get the design team, the developers.
For example, I worked with a team that had, the brown color for the company was like light green -- so sometimes we had their logos and text in lemon green on the white background. And I found out that, hey, this is a nightmare. Color contrast is off. We need to adjust the designs to make it better. And then we re-think the design and come up with color contrast. And there were other things there, subtle things that are not communicatedded in design, for example, application stage. So while building as a developer, I have to factor that in and being also, adding the engineers I was able to point them out doing code reviews and doing personal testing.
Like at some point you might not be able to get like-- you can't -- or you don't have the time to get everyone onboard. But if you're getting one or two people and they would go onto get somebody else onboard and gradually -- some people-- and sometimes they reach out to me individually and making a product accessible, making it respect accessibility, best practices. And while the industries are a bit younger than the US, I'm really excited the future here.
>> I love that mindset. I mean, every individual barrier, you're able to remove is a win, right? That's one less barrier for someone else to encounter. So great mindset.
Okay. We've got about four minutes left. Let's see if we can find a question that we can answer quickly. Let's see oh, how-- so I don't know if you want to answer this for your current role or past roles. How long did it take you to make a significant impact or a measurable impact?
>> That's-- that depends on the team-- yeah, like,-- yeah that depends on the team.
>> That's a bad last question to ask.
>> Yeah. Because it depends on the team, how bad the situation is. Yeah, but there have been-- if you're going to make some impact -- and notice that the product is a bit more accessible, maybe within the first month if things were not really in place because simply by talking to the designers, maybe you get a design -- can I get focused screens maybe? Can I get-- [Off Mic]
And then design goes back and get you back and then you begin to, you know, where-- Semantic HTML if you're a web developer. It might not be a huge result but it's additive. And in time it becomes more important. Like I said getting more buy inasmuch as possible is going to like make it exponentialal not just additive. That's how it works.
>> Great. Thank you so much for your time. I really appreciate it.
Everyone in CHAT loves you very much and identifies very much with what you're shared today. Really appreciate your time. Everyone in the audience, thank you for attend being and character about digital accessibility. Hope you have a great rest of the day at AxeCon.
>> Thank you everyone.
