[Intro Music] [Title: technica11y]
>>MICHAEL BECK: Welcome to technically. So ladies and gentlemen and all variations there upon, welcome to this November edition of technically, for the new folks, I'm your host Michael Beck, the operations manager at Tenon. Today we are honored to have with us Kevin Kalahiki, the founder of Halemano designs. Did I say that correctly?
>>KEVIN KALAHIKI: Pretty good. Yeah. (Chuckles).
>>MICHAEL BECK: Welcome.
>>KEVIN KALAHIKI: Thank you.
>>MICHAEL BECK: Kevin will talk about how accessibility and design are like two languages that share common root and that root is usability. In this webisode, he'll talk about some common issues, and how you can bring them up with your design partners in ways that you'll both understand, and you know, won't be talking past one another. And hopefully, you'll be able to implement these to make your project accessible to all users. So without further ado, the virtual floor is all yours, Kevin.
Oh, and one quick thing, since we don't have a little Q&A box on these meetings, go ahead and just put any questions you have in the chat and we will get to those at the end. So... all yours.
>>KEVIN KALAHIKI: Excellent. Thank you, Michael. And thank you Tenon for having me speak this morning. Thank you all for coming in. I'm in the US. Today's a little weird, last night's a little weird. So for anyone watching this on video, hopefully, things work out however you wanted them to work out. All right, and that's as political as I'm getting today.
Accessibility, design, usability, like Michael said, you know, all sides of the same coin. Before we dive into this, though, let me talk a little bit, (computer makes noise) let me figure out my computer first and then let me talk a little bit about me.
The reason I want to sort of go into my background a little bit is to give you a sense of where I'm coming from, what experiences I had that led me to where I am now. So I started my career as a front end web developer at Wells Fargo back in like 2000. In 2007, I believe it was, Target was sued, that infamous lawsuit. And that's how I was introduced to web accessibility. Somebody within the product team that I was working with said, "Hey, this is the thing we should probably start paying attention to."
So that was it. In 2007, I started looking into it. 2008 I think it was I attended my first accessibility conference... And that was amazing! You know, I'm sure this is a something that's shared by most of the people on this call, you know, going, going to a conference seeing... for real firsthand what it means to be an advocate for people with disabilities, what like, what it is you're advocating for, was huge.
Throughout my career, I've led a dev team, prototype design team, design system teams and accessibility team and the product design team. So that's kind of where this is coming from. The idea that, yeah, within my experience, with accessibility, I've also been on the dev side on the design side. And through all of that, kind of realized that, when we're talking about accessibility, we are all kind of talking about the same things just from very different angles.
And then the last bit is, I know nothing when it comes down to it. There's this sense that every day, it's a learning experience every day, you're looking for something to explain something else. Every day, I've got a million more questions than I had the day before. I find that to be important, but also a precursor to this conversation. If you have any questions, please let me know. And I apologize if I don't know the answer to it, I'll try to get back to you.
So, usability, for those of us on this call, I'm going to assume most of us are coming on to this, this call joining this meeting from the angle of accessibility. But hopefully there are others.
So you say accessibility, they say design, you're both advocating for usability. That's the truth of it. You're both advocating for an experience that's clear, nothing's hidden from the user. You're both advocating for removing all roadblocks from the users ability to do what they came here for. You're both advocating for an experience that's intuitive, through the use of established patterns and relatable content. And you're both advocating for the user's ability to choose when and how they access the experience.
You know, the perceivable, operable, understandable, robust, the, these are pillars for usability for everybody, even though, you know, we talk about them within accessibility as a way to sort of group organize, make it easier for us to to understand how to achieve accessibility within any project we're working on.
These are pillars of usability that, you know, Designers don't necessarily call them by the same names, but they actually kind of use them. They may not know them that way, but they're there. And this is how... you, if you've been studying accessibility can help to bridge that gap, you've got these foundations of usability that are already a common ground with designers. Your focus may have been on advocating for people with disabilities, which is awesome, it's needed, it's absolutely needed. But when you're going into the conversation with the designer, just broaden that focus a little bit, you know, and I think that is, in my experience, how this connection starts to work. Because in the end, it's all about the user really.
>>KEVIN KALAHIKI: So conversations are kind of the key to all of this and some of them are really hard. These are some real fake quotes. I say they're real fake quotes, because I didn't actually pull them from anywhere, they're not attributable, but they're real enough, I've said these things so often, "Nobody else in the organization cares about accessibility." This is a hard one for those of you that feel like you're fighting the fight on your own. And it is, it is truly hard. How do you find your, your allies, your, your partner, someone that you can, you can really get together and help work towards a common goal with, when accessibility seems to be such a different principle than other people are advocating for. So that's one.
Another quote, "This pattern is used everywhere, we can't just change it." This one's pretty common, you have an accessibility issue with with, let's say, a form field and that form field is in an application that is form heavy and maybe that application, maybe those forms have never been componentized. So if you fix this one issue over here, you've got to fix it everywhere. And that's painful, that's going to be hard.
This is the truth. None of this stuff is easy, none of this stuff is going to be easy.
Another quote, "The color palette defined in the brand style guide doesn't have any viable color contrast options." This is something that I come across all the time with color contrast being one of the easiest issues to identify, sometimes it is one of the hardest issues to fix. Because I just had a project this summer where all of the text, except for where they were using black on white, all of the other texts absolutely adhere to their brand Style Guide, which unfortunately did not meet any color contrast minimums, the colors they had chosen for their brand just didn't work. So that requires this heavy, deeper conversation to go back up to brand.
Depending on where you sit in an organization, it can be really painful for you to be the one bringing up the fact that, hey, all the way up, that design change, somebody else needs to make a call that's going to impact everything. My point here being these are hard conversations, nothing here is going to be easy. Well, hopefully some things will be.
But there's a flip side to it, you know, coming from the design background. Designers also have to understand a few things. One of those things is, design is not about forcing a personal aesthetic on your user. I'm willing to bet that most of the people on the call if you've been doing accessibility for a while you've talked to designers, you get pushback, they just don't like the idea sometimes of using a higher contrast color because it doesn't look good. It, it offends a personal aesthetic. And that's a conversation that happens.
But as a designer, it also has to be understood that a personal aesthetic isn't what you're there to do, you're there to work in service of the user. And your personal aesthetic isn't about that. It's about what can get the user to do what they need to do. And so sometimes you have to help the designer come back, come back to that.
Another thing is innovation shouldn't come at the cost of the user experience.
For those of you that have had to build crazy complex new interaction patterns, new new new widgets, new components that do a thing, that's really cool. Sometimes it is really cool, this can be fun, this can be awesome. I don't want to belittle the idea of exploring and building and doing new cool things. But sometimes all that work sort of defeats the experience. I think we always, I always advocate for if there's a semantic element in HTML that does the job kind of look at that first because the experience is going to be easier for everyone, not just people with disabilities, anyone. Every browser knows what to do with basic form element, you know, that old thing.
So helping a designer understand sort of how to maybe sometimes it's worth reining it in. If you're advocating for the experience, just rent it out a little bit.
One other thing that I think is really important, and this is an extremely common ground here between designers and accessibility is, designers use things like research personas, journey maps, for a reason. They build empathy. They build empathy for their user. Designers have to kind of be all about empathy, how the, you know, you can't design a thing, unless you really, really understand why the person who's coming to use that thing, why are they doing that? What are they, what are they there to do? Why did they even come here? When they do get here, what do they need to do?
>>KEVIN KALAHIKI: It's kind of, it's kind of key empathy, this empathy thing, we have it, we build it up with accessibility, designers build it up. So lean into that, like rely on empathy. That's, that's going to be huge. That's a, that's a key tool that that both sides really advocate for and talk about.
Building trust, and I should, I should step back a bit and talk about what I'm, what I'm talking about in the beginning of this, is really just, some ways that you can maybe mentally approach what you're doing when you're talking to designers. When you're working with designers, I will get to some examples, a handful of examples as well in a little bit.
So building trust is really key. One thing that I've learned over time is, in most cases, designers aren't just being lazy when they don't incorporate accessibility or they don't want to do it. It's hard. This is a new thing, potentially, for a designer. Or it's a thing that's always been a pain to them but they've never quite understood the reason why, why, why, do they need to do it. So I'd say step back to that empathy thing. You know, try to find that common goal where the designer understands there's really an empathetic reason to be doing this.
Personas, you know, if you can get involved and help drive the conversation around design personas to include some elements of accessibility within them. One thing that I've done in the past is had personas that include users that use keyboards only. And you know, that covered a lot because we then had a persona that we had to, we had to address and that we had to test for, that said, this is a power user that just uses a keyboard, they don't use a mouse, they can use a mouse, but they don't. So we were able to work with design to sort of build that trust, doing things that way.
Understand that designers are looking for the best possible experience too. They're not really trying to block you, they're really looking for the best experience. So get with them and advocate rather for that experience together. One thing that's really hard is sometimes it feels like accessibility is getting in the way to a designer. And I think that's because accessibility is often the last thing to be considered. So really, from a certain point of view, it kind of is getting in their way. And that's key when accessibility is the last thing. It's, it makes it really hard.
So one other element of this is to see if you can build that trust, build that relationship and get in there earlier. Some ways that you can try to do that is talk to your designers. The idea of prototyping to me has been a key way of bridging the gap between design and accessibility because it gives you a way to walk through the experience together. Sometimes you don't need a prototype, sometimes you can just sit with your designer, one thing, maybe the first exercise I ever did that really opened my eyes to using an accessibility with thought, to help a designer discover for their, on their own, things that I was going to need them to address at some point. I just sat down with them, one on one, and had them walk me through a flow. And I sort of asked questions on every step of that flow. It was a form. My background is mainly in the in the financial industry, so I'm talking about a lot of forms about collecting information, moving money, things like that. But it was really important to be able to sit down with that designer and just say, hey, okay, you tell me how this works. And I'm going to ask some questions, just from a usability perspective. And what that was able to do is sort of allow the designer to walk themselves into these dead ends, into these scenarios where they were just like, "Oh, I haven't thought about that. I haven't thought about error handling yet. I haven't thought about what happens when this goes wrong. I haven't thought about how weird this experience might be."
So all of these little things that, when it comes to you, if you're, if you're in the position from an accessibility perspective, to have to code a design without ever having contributed to the conversation or if you're in the position of having to assess a design without having contributed to the conversation before that point, those things get really hard because it is being tacked on at the end. You are having to work with something that is fundamentally not going to work. But in a lot of cases that doesn't really have anything to do with accessibility, it has to do with the usability of a flow. And what I see maybe way too often is people whose job is to address accessibility. They're really trying to shoehorn usability into something that may not have been usable in the first place. So these walkthroughs are key, they're so key! If you can get in, get early, that's going to help everything.
>>KEVIN KALAHIKI: So whenever possible, show the experience that you're talking about. This is where prototyping comes in really handy if, if walkthrough of a static set of wireframes or mockups isn't really happening, or it's not getting what you need, or it's not even drilling into, let's say you've got a really complex interaction that you really want to show, hey, this is, this is weird, it's going to be a weird experience. Maybe in your mind, you're thinking of all of the ARIA craziness that you're going to have to sort of pile in to make a thing work. But really, that's also a flag for me, if you're, if you're thinking about having to pile on a lot of ARIA craziness to make a thing work, it might be good to go prototype that thing with your designer and walk through it. Because all of that ARIA craziness is really also sort of trying to serve some usability craziness that maybe could be simplified, maybe you could change. So building a prototype showing that tighter interaction in a way that actually shows the interactions, you don't even need to talk about accessibility at this point. But if you can, sort of through, I don't know, envision framer, if you can do sketch Figma. Build a basic prototype to get to the fidelity that allows you to have this more detailed conversation with the designer before, before a developer is trying to build it. Before anybody's concerned about the accessibility of the thing... get there early.
And the last bit understand the tools that designers are using well enough to use them to communicate each other's ideas. So kind of what I was saying with prototyping, a lot of the more modern design tools actually have prototype tools built in. So in little ways, if you know a bit about Figma, it really depends on what, what your design team is using, what tools they're using. But I'd be willing to bet at this point, most of them are either in their primary design tool or in a secondary design tool, like InVision. They probably have access to some sort of a prototyping tool. And as prototyping tools, you know, they generally don't get really into the details of interactions. So that's a little hard, because that's a lot of where we live when we're doing accessibility. It is really in the fine tuned interactions.
But this idea is all about taking a more abstract idea of the usability of a flow and making it more concrete. Prototypes absolutely help lead you towards that concrete idea. It, it refines the focus a little bit and puts both accessibility and design on a bit of a more common ground when you're talking about what the experience is supposed to be versus what it might be.
And this is all about conversations. I was working with a Content Strategy Team once who really opened my eyes to this. If you're if you're dealing with forms, if you're dealing with user input, really, you're talking about a conversation. What's your name? What do you need to do today? How much money do you need to send? You don't have that much money in that account. How about this account? Does that look good? All right, we're done. That right, there was basically a money movement transaction form.
It's not that simple. But one thing that I've come at, come to the conclusion of is, if I've been thinking about a flow, if I'm thinking about sort of any form field or any sort of user input, I think about it as a conversation. I imagine that two people are talking this thing through and then saying, Okay, what does, What does the first person say? What are the possible ways that the person that's trying to do something can respond to that. And what this does in my mind is also gives me an a framework that I am then able to go back to the designer and sort of talk through a flow.
Because, again, designers aren't lazy designers aren't, (mumbles: not all of them) designers aren't against accessibility. They're also under the gun. They've got a deadline. They may be working on a two week sprint where they've just got to power through these designs. And maybe they didn't have a chance to go talk to the product team about the requirements. So maybe they're dealing with their own problems that we never see, you know, and maybe all the problems that the designers are dealing with are just turning into this, really, they're really rushing through a thing. And they didn't have a chance to think things through as they were designing a flow. So for me thinking about a flow, at least in the the case of user input as a conversation really helps that because then I can go back to them when I'm having that sort of wireframe walk through with them, if I've got it, at least in my mind, what would this conversation actually look like? It helps to sort of drive that, you know, and again, it's not accusing a designer of missing things. It's just sort of walking through scenarios, a little bit of role playing.
>>KEVIN KALAHIKI: So continuing the topic of it being all about conversations, if you have a Content Strategy Team, anywhere in the organization, get to know them. This is something that I also learned early on in my career. One of the biggest accessibility issues that I had to deal with, fairly early, was a password strength. What do you call them? I should have thought about this ahead of time. But when you're entering a new password, you've got feedback that says, "Yeah, that's a great password." "No, that's a terrible password." "Here are the password minimum requirements." And in this particular case, none of that feedback was visible at first, it only started to show up after the user start typing things in and failing the requirements, then they would see Oh, you didn't do that. So you didn't do that.
So I pulled in the Content Strategy Team. And I said, "Hey, if we think about this, like you tell me Content Strategy (Team), how you would picture this information to be displayed back to the user?" how to like, you know, take it as a conversation. How would you want the user to know that these requirements even exist?
And I was able to actually kind of put this accessibility task back on the Content Strategy Team. And have them sort of figure out, "Okay, what is the content that we're trying to tell? How should this be presented to the user? Is it important for them to know all of this immediately before they enter the password? Or is it okay for them to discover this after they fail?"
You know, content strategy goals are often really aligned with accessibility, even if it's not explicitly about accessibility. They, the goals are about helping the user understand the thing. Content Strategy can be your ally in some of those painful conversations.
So like I was just talking about, it's not just in that particular case, it wasn't just me, against the designer and the whole design team, as it were, at that point. I was able to find an ally in the Content Strategy Team and have them come in. And sometimes it's good to just have friends on your side of the conversation, you know.
And also, they might be able to use your help, too. And maybe they'll give you a trophy, like they gave me, that was really cute. But that was fun. It was a there's a trophy screenshot here on this particular slide that I was given by the Content Strategy Team I was working with. And I was working with them specifically because of accessibility. And I was really trying to get them to help me define content types, define all sorts of things that I needed definition for. They existed, this is their world. So I really just kind of pulled them in. I gave them more work to do. But they gave me a trophy. It was weird. It was awesome. Content Strategy, I can't say enough, if they exist in your organization, get to know them, lean on them a bit.
And yeah, questions. Michael mentioned earlier that we don't have a Q&A. But if you have questions, start queuing those up because you don't want to listen to me talk for the next, you know, 30 minutes... just rambling like I am.
All right. Now, a few examples. But first, keep these things in mind, not everything has to be a flight. But if you find yourself walking headlong into a design fight, bring everything you already know about usability. So remember, the perceivable, operable, understandable, robust this principles that you already know, these are foundations of usability, just walk in with that. This isn't a fight. This is design and accessibility looking for common ground. That's all this is.
Okay, picking on carousels, I think we probably all have our own horror stories related to carousels and they never seem to go away. Just yesterday, I was writing up a requirement for a carousel. And the first question that I ask when carousels come up is, "How important is all of this content?" Right? You're talking about an element that is fundamentally hiding whatever percent of content it contains. If you've got a five slide carousel or a five segmented carousel, whatever you want to call it, you are fundamentally hiding four pieces of information from the user. At any given time, you are potentially hiding that from them forever. Depending on what you have, where this carousel lives, whatever the purpose of this particular screen happens to be. It's highly unlikely the user is going to see all five slides of the carousel, much less two of them.
So the next thing I ask is, "Which slides do you think are super important?" Because, you know, what's the default slide that's going to show up on the carousel? If, if you actually want, if you want all of the content to be given to the to the user, the fact is, they're not going to get all of that content. It's just not going to work out that way. Unless you're carousel happens to be living on a page where the carousel is the reason they're there. And they're there to sort of watch content flow through. But I think for most of us, that's not the case when carousel pops up, and most of us, for most of us, the carousel tends to be a sort of a lazier pattern. And I will say this, I think it's a it's a lazy design element. It's a lazy design pattern, not that the designers who implement them are lazy. It's lazy in the sense that it's a really quick, easy shortcut for everybody to be like, Okay, I've got all this content, it's maybe not that important. Let's throw it in the carousel that obligates, that meets our obligation to show this content in some way.
But these conversations that I'm having at this point often are not with the designer. This is also probably a key point to take away, sometimes you don't just talk to the designer. Sometimes you've got to have the designer and maybe a product person. Maybe whoever's driving for this content to exist, maybe it is content, maybe pulling content strategy in at this point would be a really good idea. Maybe it's them pushing for the carousel. Again, none of these conversations are cut or dry, cut and dry or necessarily easy.
Which slides are you cool with the user never seeing? That's an important question, kind of going back to what I was just saying. And how important is all of this content? Again, in a carousel, unless the carousels is the focal point of a given page, the user is never going to see all that content. So whoever thinks it's important for that content to be there really has to understand that the content is never going to be seen by everyone.
So moving on: Form fields: Alright, so I added two screenshots to this. The contrast issues with those screenshots came as they were on the screen, on the scene, that are sorry, on the site that I took the screenshots from. I won't say where I got them from but the screenshots are of form fields. And the form fields have no labels. So, "What happens when I type in the field?" This is a common question. Whenever I see it, a form field with no labels, with no visible labels, where maybe the placeholder is acting as the label. That's, that's usually my first question to a designer. "What happens when I type in the field?" Because labels make it clear when information is expected. And the opposite of that is 100% true as well.
If I've got three form fields with placeholders as labels, but no visible labels, and I enter values into each of those fields, now I've got three form fields with my values in them. I'm hoping that whatever I entered was right. But what if what I entered was not correct?
Now, I have no idea what the form field was about. And what happens when an error occurs? Users not always going to get it right. So you have to account for an error. And if your error state is just turning the box red and putting an unhappy face on there, with no additional messaging, not only do I not know what that field was, now, I don't even know why it's an error state.
So another conversation to have with the designers is, this kind of goes back to that idea of potentially, this is used everywhere, change is hard. This is an opportunity to help them build a design system that kicks a little bit more ass. You know, it's a little bit more robust. Hopefully, they're using a design system. Design system style guides, these are things that help build a structure and a sense of, sort of reusability, a sense of commonality across a site, across an app, that are really key.
>>KEVIN KALAHIKI: You know, developers, if you're a developer on this call, who's working on accessibility, you were probably a huge advocate for componitizing your, your accessible components, your accessible widgets. Build it once, reuse it often, bake in all that accessibility goodness and then use it everywhere you can. That same idea applies to design in a design system.
Within Figma now, there are still the notions, the same notions of components. You can build design components, of a form field, for instance, a text, a text input, can be designed and that component can be designed and then that component be added to a library that then is consumed throughout Figma files. And here I'm talking very specifically about Figma because that's a design tool that I'm currently using. But this concept works and other things like sketch and probably others.
But the idea that there is a design system that you as the accessibility advocate can now help tighten up, if you find yourself dealing with an issue where form fields don't have labels or form fields don't have proper error handling or messaging, work with the designer and advocate for them to create a design system if they don't already have one. Because the benefit that you already know, you get from componentizing things, they may not know that yet but it's pretty clear once you tell them, "hey, you fix this once, and then you push that out to all of your designs, and it just automatically gets that fix." That's huge. That's, that's awesome.
So this might be a really hard conversation to have once, twice, a handful of times. But hopefully, if you can get the designer to understand the the fundamental usability issues that are at play here, then you can also help them understand how to make their process and their practice work better.
Alright, links in text. So I totally stole a tweet from Shell Little. This happened to come out like just the other day If you look up the date, October 30th, the tweet and I apologize for the language, "Hi, I'm Shell and my only job is to remind designers to underline that beep (says "beep," to replace the swear word in the text he is reading) link. Thanks."
Links in text. This is an interesting one to me because I think you can come at this in a bunch of different ways. Well, maybe two different ways. The way I come that a link in text is, yeah, number one, that link definitely needs the underlying, it definitely needs a way to sort of stand out from the other text that happens to be sitting and sure that's the usability side of a link in text. But And just to be clear, what I'm talking about here, sorry, is the idea that say you've got a paragraph of text and within that paragraph, maybe you've got an email address that you want to be able to have a mail to link on. So within a paragraph of text, you've got one linkable active element, maybe that that content links to another page. So the underline will help to call out that within this regular text page right there in the middle, highly visible, easy to spot, is something that you can take action on. That's the usability part of a link in text.
My first question is always, should that link actually even be there in the first place? I think of links and text, I think of them like trapdoors, like you're reading along and then suddenly, bam, you're on a new page. So think about you're reading a paragraph of text. Then within the middle of that paragraph of text, here's this link. So you just click it, because you know, there's a link, you click it, and suddenly, you're not in that paragraph of text anymore, you're on a completely different page. So is the content that the user fell into more important than the content that the link was in? Like, to me, that's a super important question. And this is really taking what seems like a really simple thing, I'll link in text or an underline on that thing. And really questioning the fundamental idea of its existence in the first place, this really existential idea of should that link have been in the paragraph of text in the first place? Because remember, think of these things as as conversations, the users on this page for a reason, is that link functioning like a trapdoor in the middle of a paragraph of text, does that service, that conversation? Did you really think of the conversation as being, "hey, let's talk about this thing. We're talking about this thing, let's talk about this thing," boom, "now we're talking about this other thing?" And yeah, probably not.
That's probably not how the conversation would have been outlined if you'd had a conversation. It probably would have been more about discreet thoughts, discreet thoughts, maybe an action in support of that thought, after the fact, once you've got all the information.
So does sending the user away from this page help them do what they came here to do in the first place? You may not have the time to go into this very deep level of conversation about a link in text. But I do question given wherever I happen to be in a project, sometimes if I'm just the accessibility auditor, who really has to just like, Hey, this is an issue. Yeah, I'll say, "hey, throw a link, or rather throw an underline on that text". But I will also try to say, "and by the way, you know, think about this from a content perspective. You are providing a way for a user to lose their focus. You brought your user to this page but then you're giving them all of these little trapdoors to leave this page. Is that what you want to do?" You brought them to this page to do a thing, let them do that thing. And in the course of that, maybe inform them of these other options.
But keep in mind, are those things options or are they fundamental to the flow? And if they're fundamental to the flow, then probably you need to rethink the conversation in the first place.
And this is going to be the last example that I've got. Because I do want to leave room for questions and to sort of talk if, hopefully, people do have questions, but visible focus indicators. You know, again, all of these examples, I am not talking about them from an accessibility perspective, I'm talking about them from a usability perspective, usability for everyone. I'm not talking about them just from the use cases that we might think of them .When we're talking about a visible focus indicator, from an accessibility perspective, these are really truly from the usability perspective. And with a visible focus indicator, when you don't, I shouldn't say when you don't provide it because most of the time, what's happening is, it's actually being taken away from the user. You know, most browsers will by default, show a visible focus indicator that works for someone who's tabbing through a site or through a web app, or, or an app. But, you know, removing that default visible focus indicator is actually an explicit action in most cases. So talking about this from usability from a usability perspective, the secret usability tip is that sometimes navigating with a keyboard is actually easier, even for people who can use a mouse. Ask a bookkeeper, someone who is constantly, as their job, working on something like a spreadsheet or forums or data entry. Watch them, see how often they use a mouse. And it's not going to be very often.
So giving someone the ability to sort of use the keyboard as their dominant way of entering and navigating the site can actually really help out. Except when the person can't tell where they are on the page again, ask a bookkeeper. So if you've taken all the visible focus indicators away, let's say that you've got a Google Sheets type interface, for instance, and somebody is using that. They tab, they arrow, but they have no idea where or what cell they're in or if they're on a page long data entry form field, or form entry and they want to tab to fields but they can't tell which field they're on. So they've got a tab and click new type just to be like, "Okay, well, there it is. Okay, cool." That's very frustrating. It's very angering.
So these are just usability things. I mentioned earlier, the idea of leaning on some very basic design principles that you can use to help bake in your, the accessibility concerns that you might be bringing to the table. Personas, again, become a thing. So right here where I'm talking about a bookkeeper as being a persona that might actually need to use a keyboard all the time for their work.
If you aren't sure about this, advocate for user research, usability research. This is also a design thing. Hopefully designers are advocating for this. For them to be able to do their own work. But if they're not, if it's, if it's not part of the process, advocate for it. Go and tell your design partner, "Hey, I think we might want to see how bookkeepers use this thing that is fundamentally a tool for them. Let's go talk to 12 bookkeepers and really say, Okay, how do you do this? How do you do this on a daily basis? What do you do when you're working with a form field like this, or when you're doing something like this?" and just let them show you.
You know, that way, this research can help to provide a grounded unbiased approach to why you do something in the first place. You know, it could show you, the accessibility advocate, something that you'd never even thought of before. It might be able to provide you with some hooks into a conversation that again, when you're coming at this thing from accessibility, oftentimes there's this perceived idea that, you know, we're just talking about blind people or people who are using a screen reader. Like it's really hard to break someone out of that preconceived idea of, "accessibility is all about color contrast," and nothing else.
That's still a conversation I have on a, not a daily basis, but way too often. I'm sure everybody else does when you bring up accessibility, I think more people are aware of what accessibility is now, but still their scope of what they think it is color contrast or some handful of other things, text alternatives on images, you know. The accessibility is become more common knowledge but not to the, to the depth that allows other people who aren't accessibility experts to have an informed conversation on it. So what I always advocate for here is to try to meet on their common ground. Yes, you, you as an accessibility advocate, you have a very important job to do. And sometimes it sucks that nobody understands it. But in order to get people to understand that one way to do that is find the common ground that you have with them and bring it together that way. So if you can rely on things like personas, research, basic underlying principles that designers rely on, you can hopefully make that design accessibility conversation a lot more seamless, a lot smoother.
And that's it for me. I really hope y'all have questions. Otherwise, this is a relatively short presentation.
>>MICHAEL BECK: Not at all, that was 40, almost 45 minutes.
>>KEVIN KALAHIKI: Okay. (laughs relieved)
>>MICHAEL BECK: I actually really liked that you brought up look at a bookkeeper. I was a librarian for 20 years before I got into accessibility. And the cataloging systems that we use, I was a cataloger and the cataloging systems we use, I would use the keyboard constantly because having to use the mouse to flip in between fields because it was all forms. Basically, I was filling out forms to catalogue books and other materials. And my boss would always use mouse and she had carpal tunnel because of it. She learned that or figured that out. But I learned how to use the keyboard very quickly. But there was there definitely were some focus issues and I, our provider at the time, I actually let them know about that. And in a later iteration, they actually did fix that.
>>KEVIN KALAHIKI: That's awesome.
>>MICHAEL BECK: That was, that was, I was very impressed with how receptive they were in the end. I think that they knew that. But then whenever they pushed out the the version that we got, they weren't quite there yet. They hadn't quite figured it out yet. So I kind of just gave them a little, gentle little nudge to something they already knew was an issue and now they actually had the user who was like, "Hey, what about this?"
>>KEVIN KALAHIKI: Yeah, yeah. You'd be surprised how often that becomes the thing. I, one of the projects I'm working on right now, they are taking on accessibility not because they got sued but because two or three of their users have said they can't read the type on their on their app. And yet, sometimes just reaching out to people and just being like, "Hey, I can't use this."
>>MICHAEL BECK: That's great for your client, actually having the wherewithal to be like, "Oh, yeah, let's, let's do that. Let's get ahead of this."
>>KEVIN KALAHIKI: Yeah.
>>MICHAEL BECK: That's good... Well have any question? That'd be amazing questions.
Sarah has a comment that said, "The best use case she has ever seen for carousels is to stop arguments about what goes on the homepage. But that's, an it's an internal user problem."
>>KEVIN KALAHIKI: Yeah. Which in that case, I'm curious. So Michael, how does this work? They can chat back, right? If I have a question for Sarah? Okay. And Sarah, you don't need to reply to that, but...
>>MICHAEL BECK: Mmmhmmm
>>KEVIN KALAHIKI: Okay. And Sarah you don't need to reply to that, but...
>>MICHAEL BECK: Sarah can actually unmute herself if she would like to have an actual conversation.
>>KEVIN KALAHIKI: Yeah, that would be awesome. But, Sarah, I'm curious about that. Do you mean in the sense that everybody wants something on the screen and they're like, equally have weight in the conversation? So just somebody is just like, "Okay, look, but we'll put it all there in a carousel. There. You all have your content."
>>SARAH: Yeah, that's it exactly. Especially since it's usually something of really important to themselves. So I work in a state agency. So they're doing some sort of marketing campaign to push a certain program but that's not what the users are actually coming to their site for. And and it would be, you know, people would have to scroll for miles before they could actually get to the things that the users care about.
>>KEVIN KALAHIKI: Yeah.
>>SARAH: So so that kind of solved that. And I think that that even doesn't even actually happen as much as it used to because so many people now, don't go to the homepage and navigate, right. They're searching from someplace. (giggles) So some of those arguments have gone away. But but it did make that whole discussion just change course. We stopped wasting time having conversations like that.
>>KEVIN KALAHIKI: Yeah.
>>SARAH: And they were happy because their content was right at the top of the page and we were happy because we didn't have to look at. (Laughs)
>>KEVIN KALAHIKI: That's, that's a really good point,ya know. I don't think any commonly derided element necessarily needs to just be banished and go away. I think what you just talked about is maybe a really good use case for a carousel. As long as it's accessible, as long as you can put controls on it, like pause, stop, play, toggle through, maybe it is a really good way to sort of bury some things and bury a potential fight between partners. That's it. That's a really good use case.
One of the other things that I've done on carousels, when it hasn't been necessarily so many people fighting but somebody advocating for things was just be like, "Hey, go check your analytics. You go go look at the analytics of this. Tell me how many people have accessed all of the content in your existing carousel, from the carousel."
That oftentimes is a really good argument because then there's like, "Oh, we get no return on investment for these slides that are buried deep in the carousel, because nobody's even clicking on them. yet. We're spending all this time figuring out content design accessibility for the carousel."
I think when you point out how much work goes into something that users never use or see, sometimes that's a good argument as well.
>> SARAH: I do. I do like carousels for pictures. If I'm shopping, I like being able to swipe through pictures of the product I'm looking at from different angles or somebodies photo album. It's, you know, especially use touchscreens a lot. So swiping is easier than scrolling.
>>KEVIN KALAHIKI: Yeah, it is, that is an absolutely great case. I did try to call it out at the beginning. Like that idea that sometimes the carousel's purpose actually is why someone's there. Shopping. You're You're totally right. I think that's that's an excellent use case. That is exactly why, if I'm shopping and I need to see a thing or at least understand what this thing is, the carousel probably is really helpful for that.
>>MICHAEL BECK: Alrighty, anybody else? Back to my zoom meeting area. Nope. All right. Well, thank you, Kevin. That was, I really liked that you kept advocating for pushing left as we say at Tenon. Getting this, getting everybody involved in beginning so it's not an afterthought and therefore accessibility becomes a pain.
>>KEVIN KALAHIKI: Yeah, that that really is it man, you. All of these things are eased up so much. I mean, I'll tack that on, the idea, ya know talking about my career path. At the beginning, this is kind of that idea, I think my career path shifted left, if you will. And it helped to drive the conversation on accessibility. It helped to wedge it in earlier because that's, my role became more about being in the on that left side of it. So it's it's huge. That is, that really is, you're right, Michael, that really is where that conversation needs to start, where it needs to be.
>>MICHAEL BECK: We're working with a client now that came to us for an audit and now they're actually excited about injecting us into their, in their workflow, because they're, they're new, they want to make sure they do it right the first time.
>>KEVIN KALAHIKI: Nice!
>>MICHAEL BECK: Fantastic. Alrighty, so that brings us to the end of this webisode of Technica11y. So enjoy the rest of the year, as much as you can. Thank you to Kevin again for that wonderful talk and all of you for joining me, especially making it here today. And I will see you in the new year.
>>KEVIN KALAHIKI: Thank you!