The Not-Boring Tech Writer

In this episode, I’m talking with Kenzie Woodbridge, a documentarian and self-taught accessibility advocate. We talk about how feeling “not expert enough” is no reason to skip content accessibility, four ways you can make your content more accessible right now, and ways you can serve as an accessibility advocate as you review content and work with contributors.

—

Kenzie and I discuss why content accessibility is something we all need to think about as we create content. You don’t have to be an expert to improve your content’s accessibility. We discuss four areas you can focus on right now:

We also discuss some dos and don’ts with alt text, providing feedback to content contributors who aren’t following accessibility guidelines, tools or processes to help identify accessibility bugaboos in your content, and so much more. Check out the resource list below to sponge a ton of useful resources from Kenzie, too.

Kenzie works at the British Columbia Institute of Technology (BCIT) in British Columbia, Canada, as a Tech Writer, Trainer, and Knowledge Strategist, and is currently a co-chair of BCIT's Accessibility Committee. They have spoken about documentation and other topics at multiple technical conferences, including Write the Docs (their favourite). Kenzie is also a parent, a tuba player, chronically ill, a crafting dilettante, a gamer, and all around nerd who wrote their Master's thesis about prosocial community in multiplayer Minecraft.

Kenzie is awesome and you totally want to have them as your friend (offer of friendship void where local laws do not permit, not guaranteed in all circumstances, skill-testing questions required).

—

We love hearing your ideas for episode topics, guests, or general feedback:

Join the discussion by replying on Bluesky

—

Kate Mueller: [00:00:01] Welcome to The Not-Boring Tech Writer, a podcast sponsored by KnowledgeOwl. Together, we explore topics and hear from other writers to help inspire us, deepen our skills and foster our distinctly not-boring tech writing community.

Kate Mueller: [00:00:18] Hi, I'm Kate Mueller and this week I'm so excited to welcome to the pod, Kenzie Woodbridge, whom I met, I want to say, back in 2018 at Write the Docs Portland, probably at the QWERTY event there. I was so excited to be able to get Kenzie on the show, because they are probably one of the best advocates, in my experience, in the Write the Docs community for accessibility. So Kenzie, welcome to the show!

Kenzie Woodbridge: [00:00:45] Thank you very much, that is incredibly flattering.

Kate Mueller: [00:00:49] Kenzie, to start off, for our listeners who don't know you, can you tell me a little bit about your, I call it, tech writer villain origin story? How did you ever connect with this community in the first place?

Kenzie Woodbridge: [00:01:02] I fell into tech writing sideways, which in my experience, in talking to lots of other folks, is very common. We're a person who is doing another job, but then it turns out we're also that one person in the office who has that natural push inside of you to write things down. Or people keep asking you questions. You're like, what if I wrote it down in a document and gave it to you? Then you could do it without asking me. It turns out that now you just asked me where the document is. It's a slight improvement in the process.

Kate Mueller: [00:01:39] It's a faster answer.

Kenzie Woodbridge: [00:01:40] It's a faster answer, exactly. When I was 6 or 7, what I said is I wanted to be a writer and a teacher. I was in my mid 30s when I suddenly realized I succeeded. I am a writer and a teacher. I work at the British Columbia Institute of Technology, which is a polytechnic institution. We're the second largest post-secondary in British Columbia. The University of British Columbia is the biggie, but we're second largest. We have between 40,000 and 50,000 students a year. We have close to 3000 faculty and staff across five campuses. We do training in anything from business, financial management, computer information systems, to nursing, to medical radiography, to carpentry. A huge range of things that people can study with us. At first, I was in the internal temp pool, and I was just doing three month contracts here, there and everywhere. Which was a really great foundation for the rest of my career over time, because you get to know all these people and you work in all these different areas. I ended up with a three month contract in the web team after about four years. I'd been there four years when I got this three month contract with the web team, just copying and pasting content from the old website into the new CMS. Basically, a little copy pasta monkey one of my colleagues called it.

Kenzie Woodbridge: [00:03:14] Once I got in that position I was like, I want to stay here. This is the place I want to do more of this because I really like using technology, I like using systems, the systems all make sense in my head, so I could understand all the parts. But then because I had this enthusiasm, I got tapped to be the backup administrator for the whole of our knowledge base, which was started in 2005. Then I also got quite involved, because at the time we had people in a different department providing the training for people and using the content management system. They had it set up in this way that was extremely earnest and well intentioned, but didn't really meet people's needs. The people, like a program assistant, in the nursing department who just wanted to update the information about nursing on the website, didn't want to do the six hour session that was giving them the history of web design.

Kate Mueller: [00:04:21] I don't need to understand how it works.

Kenzie Woodbridge: [00:04:24] I just want to log in, go to the thing, make the change, submit it, and then run away again and not think about it for another month. I took over that in 2007, and I reduced it down to, initially I took it from 12 hours down to 3 hours of, here you go, you log in, you do the thing. There I am, I'm just doing trading and I'm doing technical documentation. Suddenly in 2014 my friends said to me, I heard about this conference, it's called Write the Docs, it's about people who do some of the stuff that you do. I was like, there's people who do the stuff that I do? I feel so alone!

Kate Mueller: [00:05:09] I think that describes a huge percentage of the folks who go to Write the Docs.

Kenzie Woodbridge: [00:05:14] Exactly. Honestly, it changed my life. It was so affirming to go there and realize the stuff that I'm doing, other people are doing it. They have suggestions on how I could do it better, and I have suggestions on how they could do it better. There can be this great back and forth here, and I have peers.

Kate Mueller: [00:05:34] It's not just you in a silo talking to yourself about how to improve it. You can be like, there are other people who think about these things and are excited about these things and have different approaches to them, and we can actually collaborate. What a crazy idea after being a solo person for so long. I knew that the concept of technical writing existed, but in my weird little brain, it was like, those are paper manuals for things. When I got into writing instructions for software, I never connected the two. I didn't think of myself as a technical writer at all. I still kind of don't. I really didn't until I went to Write the Docs, and I only went because I started working at KnowledgeOwl. They were like, we are a sponsor of Write the Docs, you should totally go. Then I went and I was like, these are my people. I didn't even know there were this many of us, this is great! I belong to a community of people who do this. A lot of us are making it up as we go, but communally we're making it up as we go. And that's kind of awesome.

Kenzie Woodbridge: [00:06:45] And communally, we could make it up better. Honestly, one of the most important things in my career was to make those connections. Make some of those friends that have been my friends now for 11 years and all the learning. That really changed a lot for me, was to suddenly realize that there is this career that people do. I'd seen manuals too, of course, and I knew that people had written them and I am one of those people who does read the manual. But a lot of manuals for things are clearly written by people who aren't thinking about it from the point of view of the user. Sometimes it's not even about the tool or the user, it's about, here is the thing that I never want to have to talk to you about ever again or something like that. One of the biggest struggles that I've heard about from other people, but I've also seen for myself, is that tech writers need to be right in the middle of things. They're not just receiving information from devs, but able to provide feedback back into the development process.

Kenzie Woodbridge: [00:08:02] That's some of what the UX writer role came into was, we're going to do a better job, make a better user experience with the text within the thing or the UX designers, how these things are laid out. There's problems that people want to solve with tech writing that you can't solve with tech writing that are much better solved with better design, with better configuration of the tool. If you don't want people to do a thing, you could write down in a document that they're not going to be looking at when they're doing the thing to not do the thing. Or you could make it impossible for them to do the thing if it's really inappropriate for them to do the thing. Don't make it possible for them to do the thing that is wrong. I'm happy to put it in the docs, but I am telling you right now, it won't prevent people from doing the thing. That's not the power that documentation has.

Kate Mueller: [00:09:02] Or if there is a small edge case where somebody should definitely do that thing, so there still needs to be some access to it.

Kenzie Woodbridge: [00:09:12] But you can't do those sorts of things if you don't have a solid back and forth, instead of just, they give me the information and I document it. I know that's a situation some people end up in, that's the way some organizations are set up. But because I started out being embedded in the web team, then I therefore was already accidentally set up with that access to say, we should do this better.

Kate Mueller: [00:09:38] What is your title? Does it actually include the word 'writer' in it in any capacity?

Kenzie Woodbridge: [00:09:41] I am a senior systems analyst. That's because we're a unionized environment, and everyone who works in the IT department is a junior, intermediate or senior systems analyst. I used to, in training, introduce myself by saying that I was an intermediate systems analyst, which was true at the time. Then I could say that means that I analyze intermediate systems. That's a very dumb joke. I apologize, but it's the part that gets the laugh just as it was for you. The problem is, with ‘senior systems analyst’, that means I analyze senior systems. It just doesn't land the same way, it's not as good a joke, but the pay is better.

Kate Mueller: [00:10:24] Do you identify with the tech writer label?

Kenzie Woodbridge: [00:10:29] I admit I'm a big fan of the documentarian title, despite the confusion with documentary filmmakers. Win every lexical argument, just because of the way it's been framed as being inclusive of anyone who has as a part of their job.

Kate Mueller: [00:10:50] What is your villain origin story? It sounds really dark if I put it in this context, but how did you come to be interested in accessibility within documentation or within your training?

Kenzie Woodbridge: [00:11:01] I give a lot of credit to my colleague, who I worked with for many years who really cared about web accessibility because one of her best friends from university is blind. I don't know that I would ever have been disinterested, but it really had a sense of urgency. Back in the day, we were doing image replacement for headings so that way you could have nice spiffy looking headings on your website that theoretically were accessible because the heading is still on the page. It's being read out aloud, but that forgets that there's actually a difference between people who are blind and people who have low vision. People who have low vision might be using very high contrast things. Then if you were doing that, then the image replacement would change the image. That's why everybody having a little bit of a grounding in basic accessibility is really important. I think that content accessibility is a little bit different than physical access accessibility. Very few of us are, on a day to day basis, designing buildings or building entrances. Any of us might be putting boxes in the way of the automatic door opener or something dumb like that, which is a useful metaphor for content accessibility. To a great extent, physical building accessibility, those built structures, built environment accessibility, many people feel, probably somewhat justifiably, that they can leave that to the experts, the people who are building the structures. But with content accessibility, we're all creating content all the time. Is Word accessible? Yeah, it's a pretty solid, accessible tool. But does that mean that everything you make in Word is accessible? Absolutely not. Are PDFs accessible? They absolutely can be but they're not necessarily just because they're a PDF.

Kate Mueller: [00:13:16] I think it comes back a little bit to, you do what you know and when you know better, you do better. This is one of those places where you can keep learning so that you can do better, but you have to start somewhere. Something is still better than nothing, some improvement is still better than no improvement.

Kenzie Woodbridge: [00:13:38] Because I was doing the training for people to use our content management system, then I could just include in every single training the basic stuff about accessibility. Use clear descriptive headings that are headings, not bold text, headings, friend. Don't skip levels of headings. These basic things that, if you know, are very easy to do. They're not complex things, you don't need to know HTML to select heading two or heading three in the drop down menu in the WYSIWYG editor just to use headings at all.

Kate Mueller: [00:14:19] Or conversely, don't set something as a heading just because you want to style it bold and big if it's not actually a heading.

Kenzie Woodbridge: [00:14:28] Worse was, for a while, people liked the styling on our table headers better than our regular headings. They'd make a table with one cell just so they could use the '<th>' to get that styling. There was a whole team, they didn't like the styling on the headings. It's not an aesthetic choice, people. It is what it is. They'd be like, we're going to use heading threes and then bold text instead of heading twos followed by heading threes, and things like this. With the training I was able to at least get the message out to more people, and about how to use clear descriptive link text instead of click here, check it out, read more, things that don't help you when you're just hearing the link text read aloud without the rest of the context around it. Also doesn't help you for search engine optimization either, people.

Kate Mueller: [00:15:17] Maybe I date myself a little here, but there was a period of time where information foraging theory was really big on web navigation. A huge part of the things that they tell you to do there is to increase your information sent on any link. Anytime you're trying to get somebody to go somewhere, you want to give them enough of a scent to be like, is that the information I actually want? They're trying to make a decision about whether they're going to click on the thing. 'Click here' doesn't give me a whole lot of context to say, am I interested in that thing? Whereas, 'refer to this thing if you want to figure out how to do X', that gives me a whole lot more information to be like, that is or is not the thing that I want to click on because X may or may not be the thing that I want to do. Overall, thinking about it through an accessibility lens can help reinforce some of those content best practices, like headings and not skipping levels in between. I will be honest and say, three years ago, I didn't really pay attention to that.

Kate Mueller: [00:16:21] Since I've started learning more in the accessibility realm I was like, that's a bad thing, I should stop doing that. Then I started paying attention to the places where I did it and sometimes I was like, what even happened on this page? How did I end up here? Was this a copy paste fail? I don't even know. But it does prompt you to take that step back and say, am I actually constructing the hierarchy of content on this page appropriately? Because for somebody who's listening to it being read by a screen reader, does this even make sense? Because if it doesn't make sense for them, it's probably not making sense for the sighted person who's reading it, either. They're probably scrolling back and forth. When we're talking about content accessibility, what are some of the big things that we should be paying attention to? Talking about using headings, using consecutive headings, good link text, but what are some of the things that we're really trying to look for as we're making decisions about that content?

Kenzie Woodbridge: [00:17:21] I think the biggest thing is exactly the people piling boxes next to the accessible door opener. More often than not, I think we get in our own way. We do more creating a barrier rather than not doing enough, if that makes sense. We do things like, make a whole table with one cell to get this heading style. That's an example. Every time we come up with new fancy ways to make websites, doing the image replacement for headings, was a lot more work than just using a heading. Those are the kinds of things that I think, often as developers or as the people designing the site or thinking about it, about putting those barriers in the way. I'm in favor of the KISS principle with only one S, just keep it simple. We don't need to be casting aspersions at anybody about their intelligence. Just use semantic markup, don't try to reinvent the wheel. Don't go, I want this to be a heading so I will make it bold and big and I'm going to change the color to this. That's not great from a web content maintenance thing either. It's not good for search engine optimization and it's not good for accessibility. Just use the headings. Don't make every link into a button if it's not a button. Just use the things that are appropriate. The HTML standard is pretty solid. Nobody's saying it's perfect, but we've been working with it for 30 years, it's good enough, just use it.

Kate Mueller: [00:19:11] Many of those semantic concepts exist for a reason, in part because those are things that should be styled differently. If you're using an H1 versus an H4, they should look different to a sighted person because they're denoting different things. An H1 is like, this is my page title. Everything belongs to this. Whereas H4 is like, this is a little side note about this thing nestled way down here. Those semantic elements exist smartly to help be able to style and display that stuff. So use those tools because they're available to you already. I want to ask you a question specifically about alt text. I feel like this is one of those areas where a lot of us understand that we should be using alt text on images, but I also feel like I see a lot of alt text that's like, screenshot of X. There are some good resources, we will probably link to a couple of them in the show notes, but can you talk a little bit about alt text on images and whether or not you would want to say, this is screenshot of X.

Kenzie Woodbridge: [00:20:23] A good reason for distinguishing what kind of image it is. I would not bother telling them it's a photo, a screenshot, etc. Let's say you've got a whole bunch intermixed and there's a reason why you'd want to distinguish, then only in that circumstance, maybe. For the most part, you want to keep your alt text a visual description of the content and meaning of the image. I say that because there are different audiences for screen readers, therefore different audiences for alt text. People who are blind, the alt text fully replaces the image for them. That's why you don't want to just describe what the image is in, but you want to give a little bit of a nod to why you're putting the image here. What are you trying to communicate? Because an image is there to communicate a thousand words, but we don't use a thousand words in our alt text. I'm giving you this image to give you a feeling. In our circumstance, we've got a picture of a bunch of students engaging with a thing. What is the feeling I'm trying to give you? I just want to give you a tiny little nod to that in my description, if it's appropriate, just through word choice.

Kenzie Woodbridge: [00:21:44] I don't want to skip the clear visual description of the image because another audience is people with low vision, who not all of the time, but some of the time, may be using alt text to help them interpret what they are seeing. The question is, how much do you need to describe about a person or about the aspect of a person? The reason we don't say 'photo of screenshot of' is because we want our alt text to be as information dense as possible. We want it to be short, because we don't want to take up all of this person's time with extensive lyrical descriptions of the minutia of this image. Most people are glancing at the photo, we don't want to take up more of their time than that, but we don't want to leave them out. Ideally, we're using images very purposefully, aren't we everybody? We are not putting them in willy-nilly for no reason, taking up everyone's data and making the load times immense. We are doing it for a purpose, to communicate a thing and we don't want to exclude any audience from that communication.

Kate Mueller: [00:22:49] I've seen this sometimes in some knowledge bases. Where people will do something like, they'll show a screenshot of a navigation menu pointing to the element, but they won't have any text above or below it describing go here, select this and select this. Whereas if you have that text description, then the image is just serving to reinforce or ground somebody who's sighted to be able to be like, that's what that menu looks like, I'm in the right place. I have seen cases where folks have just taken the screenshot of the menu and haven't told someone where to go in text. That would definitely be a case where you should have alt text, but ideally you should have text, just regular text, telling somebody where to go.

Kenzie Woodbridge: [00:23:38] You should have regular text, but I also think there's even an element of accessibility in what screenshots you take, and how you take them, and how you crop them and frame them, and what's visible and what isn't. Whether a screenshot is the right tool for the job or whether this might be one of those exciting, rare opportunities for an animated GIF perhaps, or something like that. The other thing I'll say about training is, I really think that more tech writers should be trainers as well. It gives you this wonderful opportunity to test your documentation live on people, and to hear all of the questions people have and then go, now I understand that user better than I do just by sampling a few people here and there, and better than I do just by having a really good imagination. I do have a really good imagination, but sometimes you can't imagine the problems that some people will have. I think that's been a real benefit, to me, is to be able to test things on people. One of the things that has been interesting over the years is to hear people push back on accessibility. We're in this post-secondary thing, and there are certainly, I think we can all agree, not every job is going to be available for everybody.

Kenzie Woodbridge: [00:25:06] There's jobs that some of us, through our own innate abilities of all kinds, are probably not well suited for. I think I'm a pretty smart cookie and I'm nimble with my hands and things like that, but I should not be a surgeon because I have attention deficit disorder and I skip steps. Surgery is not the right job for me, it would not be responsible for me to be a surgeon. There are jobs, not everyone can do every job. On occasion we'd have an instructor and they'd be like, people who are blind can't do this job, it's not a job that you can do while blind. I'm not here to argue whether they're right or wrong about that specific job, so why does our content need to be accessible? The student might not need it to be accessible in that way. Although, maybe a person couldn't be blind and do that job, but blind people aren't the only people who use screen readers. People who have learning disabilities that make it hard for them to read fluently might use screen readers on occasion to get a large chunk of text out quicker than by reading it. People who have a migraine or are recovering from a concussion or brain injury might use screen readers, so they're not looking at screens.

Kenzie Woodbridge: [00:26:18] People who have English as another language, and whose alphabet isn't the same as the alphabet that we use with English, might use a screen reader if they speak relatively fluently but don't read fluently yet. There's lots of reasons why people might use screen readers, and all of that is included in accessibility. All of those people might well be a great fit for your program, I don't know. The other thing to think of is, maybe the HR manager who sits in the office and has to approve the funding for this person to come and take your program is blind, and they need to be able to see the information because they need to approve the program. Or maybe the parent who is really interested in what their kid's going to be learning when they come to your program is blind or has low vision or has English as another language or whatever it might be, they need that information. It's not on us to ever assess which content needs to be accessible and which doesn't. All content needs to meet those standards because we don't know why someone might be looking at it. We don't know what their circumstance is, and we can't accurately guess.

Kenzie Woodbridge: [00:27:28] The world is too big for any of us to accurately guess that kind of thing. I just don't want to miss out on the point of, it's not about assessing which content needs to be accessible and which doesn't, I tend to think that it all does. It's also better to have it all accessible because you were planning it from the beginning, than to suddenly run into a weird person who needs it to be accessible. Inappropriate, obviously, to think of it that way, but that's the way we act. We're going, fortunately we are only making content for normal people, we don't have to think about the accessibility thing. That's a bit of a problem. If we instead just embed those very basic accessibility practices in everything we do, then when you've got that external vendor who gets that file you send them, that you send to everybody, that's auto generated by the system, and doesn't have tabindex in there so they can't figure out where to go to fill it out because they're using a screen reader, you're not scrambling at the last minute to redo the system. Instead, everyone gets the accessible document. It's not going to hurt anyone to get the accessible document.

Kate Mueller: [00:28:41] It's also worth noting that there are different forms of thinking about accessibility. We're talking a lot about visual presentation, but there are folks who can't use a mouse and are using keyboard navigation for everything. That's a form of accessibility that can be a really limiting factor on using your website or your knowledge base. If the tab order, for example, does not make any sense on the web page that you're presenting.

Kenzie Woodbridge: [00:29:10] That reminds me of a thing that I also want to say. If you're responsible for building a tool and you very thoughtfully and purposefully design some accessibility elements into your tool, like for instance, on a website, you correctly have the 'skip to content' links so people don't have to listen to your entire navigation menu every time they come to the page. Cool, but please make sure that in your development pipeline you have a QA check that always checks that something else that people do doesn't break that. Because you don't want to find out that you went through all this work of making this thing, and you didn't have a smoke test for it or whatever it was, and all the other things, and then two years later someone comes up to you and is like, by the way, I don't know if you know, but that 'skip to content' link, it hasn't been working for 18 months. Did someone tell you that? You're like, no. Just because someone made a small development thing, they changed 'this' to a 'this', or whatever it was that they did, and then suddenly it broke your accessibility thing. If you very properly build some of those structural accessibility things in, please also make sure that you're including them in your QA so that they continue to exist. I'm not speaking from experience, this definitely doesn't represent anything that happened at the British Columbia Institute of Technology.

Kate Mueller: [00:30:33] On that note, I think we'll take a break and we will be back shortly.

Kate Mueller: [00:30:39] This episode is sponsored by KnowledgeOwl, your team's next knowledge based solution. You don't have to be a technical wizard to use KnowledgeOwl. Our intuitive, robust features empower teammates of all feathers to spend more time on content and less time on administration. Learn more and sign up for a free 30 day trial at knowledgeowl.com.

Kate Mueller: [00:31:02] And we're back! Kenzie, I feel like maybe we started veering into this at the end of the first section, but part of what I was hoping to get from you here was, how can we, as content creators or content editors, serve to be advocates for accessibility on our teams? As you've noted, we're well positioned to be a voice for user empathy and to be a voice for the user. I think that also probably positions us fairly well to be accessibility advocates on some level. Even though a lot of us don't feel like we're experts, even though a lot of us don't feel like we're necessarily the most qualified. What might that look like? How could we try to bring that voice into the room?

Kenzie Woodbridge: [00:31:49] I think you start with the strengths of a tech writer. One of the strengths of a tech writer is breaking down complex information into understandable, easier to understand, not always easy to understand because some things are actually just very complex, but easier to understand bytes and that sort of thing. When people think of accessibility, it's very easy to be overwhelmed by just how much of it there is to think about. The WCAG standard is a large document. It has a lot of complexity, and it's written to be universally applicable in this way that can make it hard for people to immediately apply it in their head. I'm working in Word doing what now? It has to have all of that level of detail because we need that level of detail. But that level of detail is overwhelming. I think we sometimes, in the 'technology will solve all our problems' illusion that we all live in, because it is so attractive and sparkly and wonderful to think that technology can solve all our problems, the fundamental problem is us as human beings, and therefore in many cases the solution is actually just us also as human beings. Consistency in yourself, in always checking and telling them. People who want to do the right thing are embarrassed if you tell them too many times, even if you tell them very politely.

Kenzie Woodbridge: [00:33:35] I'm never trying to ever shame anybody, but they don't want to be told that they did it wrong. They want to do it right. If you are lucky enough to be working with people who want to do it right, then all you need to do is consistently point it out instead of letting it go some of the time. When you let it go some of the time you're like, I guess it's not important. No, it's always important. Just being really consistent with those people. Some people aren't that committed, they don't have that same internal drive to be the good person doing it. They're trying to check something off a list, that's not what's going to motivate them. In those cases, I might not do it for them, I might push it back to them and say, I'm not going to accept it until you do it, it's more efficient for you if you just do it the first time. Some people, if you do that, it will never get published and that would be a loss so you might choose to do it yourself. Just compensate for them every time because you don't want it up there if it's not accessible. That's where it is, I'm not going to put it up and have it not be accessible.

Kate Mueller: [00:34:41] Otherwise, why do it? If you're motivated to do it, it's not like you're motivated to do a shit job. You're probably motivated to do it.

Kenzie Woodbridge: [00:34:51] It's a skill and you build it up by practice like any other skill.

Kate Mueller: [00:34:55] I'm thinking about the occasional content contributor, somebody who's not in the content a lot. I'm a big fan of using checklists for those folks. To be like, I don't expect you to go reread our entire style guide. Instead, I'm going to give you a checklist of, once you think you're done with the thing, can you just check these ten things. Did you do this? Did you remember to do that? It feels to me like that could be a good place to work in some of those accessibility elements that are easy, like headings. Are your headings sequential? Are you not skipping any levels in between there? I think a lot of us, when tasked with accessibility things it's like, I'm going to run Lighthouse in Chrome and see what it throws at me and see what I can fix. Not that there isn't some utility to doing something like that just to get a feel for it. Sometimes that will confirm for you, the color contrast isn't great. Here, let me go talk to my design team. It does give you some really detailed things, but it won't necessarily catch everything, nor would you expect someone to run that on every single article or every single page on a website. It's just not feasible.

Kenzie Woodbridge: [00:36:13] AI tools are not bad at generating a first pass at alt text. They're not going to know what you are trying to communicate with this image. They're not going to catch the meaning of it, but more than 50% of the time they're going to correctly identify at least what's in the image so that's a good starting point. In the great problem of, nothing more aggressively stares a person down from starting like a blank page. Maybe if you're struggling to figure out what you should put into alt text, take a look at that. To be honest with you, when I'm trying to figure out, what is the current consensus on how we're actually doing alt text these days, I might go to organizations where accessibility and so on is their whole purpose. They are a contracting agency that does accessibility assessments for such and such. I go, how are you doing alt text? Just looking at their alt text, things like that, to get a better understanding. I'm using their work for free, but I hope they understand I'm doing it respectfully.

Kate Mueller: [00:37:22] You're using it because they are people who are really thinking about it all the time, and therefore in theory, the practice that they're using should be reflecting that knowledge and that expertise. It's probably a step better than guessing, I'm sure it's a step better than guessing, but also a step better than relying on some 'rando' you found on the internet who suggested you do it this way. Helpful to see how folks who are really deeply embedded in that space are thinking about it.

Kenzie Woodbridge: [00:37:54] Contrariwise, if you are like, we should maybe contract with this agency about an accessibility audit, and you go to their website and they don't have alt text you go, or maybe we should not do that. Alternative perspective, what if 'no'? I think people can be very afraid to start and not recognize the field of knowledge in general. The amount that people know about it is so low that even just telling people about headings can give them this enormous, I can use the headings in the drop down menu. Sure, okay. That can be their entry point into accessibility, and it wasn't so hard. I think we're afraid, if we're not experts, to say anything. I don't know that I count. You were very flattering in the introduction, but I don't know that I count myself an expert in accessibility at all. I have no formal training in it. I've done a lot of reading, I've gone to conferences, I've listened to people, I've thought about it. But I didn't have all of that when I started telling people, by the way, headings and also link text. I don't think you need to be an expert to say some of those very basic four things. I think we build it up in our mind to be like, you need to have all this complex technical knowledge. But the reality is there are still people in the world using bold text for headings, so calm down a little.

Kate Mueller: [00:39:38] I won't speak for other tech writers, I will speak for myself, I can tell you I am not an expert at every part of the domain, ever. But that doesn't stop me from trying to do my job. Accessibility is just one piece of that, that I know that I don't know enough about, and I probably could be way more expert in. But that doesn't mean that I shouldn't make the effort to do the bits that I know should be done.

Kenzie Woodbridge: [00:40:06] If you are able to get it into your standard, enforce that standard consistently. Advocate for making it hard to do the wrong thing and easy to do the right thing. The less cognitive load you put on people to do the thing you want them to do, the more likely they are to do the thing you want them to do.

Kate Mueller: [00:40:28] Just to wind things down, what is a great piece of advice you've been given? It does not have to have anything to do with anything we've talked about today.

Kenzie Woodbridge: [00:40:39] I honestly can't trace the source of this, but it is something that came out of that first Write the Docs that I went to. I don't know if it was a combination of bits of advice or the insight that came to me through that. The most respectful way to approach your coworkers about anything is to have the expectation that they want to do their job. Their job includes documentation, their job includes, in some cases, contributing to it, facilitating it, whatever it might be, their job includes that. Their job also includes concern for accessibility, because all our jobs include concern for accessibility. It really helped me to reframe that as, not me over here begging and pleading and cajoling and saying, 'please sir, if you wouldn't mind, could you perhaps write the documentation or review this thing to ensure it's still correct if it wouldn't be too much trouble'. That attitude was keeping me in this really stuck place. I'm not saying we shouldn't be polite. I believe in being polite and kind to people, but to have the expectation that the polite, kind thing to do is fully expect them to do their job. You shouldn't ever have to beg and plead for someone to do the basic parts of their job. You would just expect that they are going to do it, so you approach them with that expectation. It's like, I noticed that you didn't do this, just to remind you the standard is we use these headings in these ways because of accessibility. Thanks, I look forward to seeing it next time. That was the piece of advice, the piece of insight, the cumulative thing that came for me out of that first Write the Docs. I should just expect that people do their work, and what is respectful for me is to approach them as though they would want to, rather than to approach them like I'm asking them a favor every time. I don't know if that helps anyone else, but it's helped me a lot over the years.

Kate Mueller: [00:42:57] I like that, that's a good piece of advice. To close it out, if people wanted to reach out to you to talk about this more, is there some way they could do that? Do you have a website? You just want them to ping you in the Write the Docs Slack? Follow you on LinkedIn?

Kenzie Woodbridge: [00:43:15] Absolutely ping me in the Write the Docs Slack, but I'd also love it if you connected with me via LinkedIn. I have a lot of connections there, I might even help you to show up as a second level contact for that job you're going for, you never know. So I strongly recommend connecting there.

Kate Mueller: [00:43:32] Invitation to network, folks. You heard it here.

Kenzie Woodbridge: [00:43:36] I would have said Twitter back in the day, but unfortunately goodbye I guess, on that one. They told me that multi-factor authentication was only for paid users and I was out. That was what it took for me to be out.

Kate Mueller: [00:43:53] I think we all have had that moment at some point.

Kenzie Woodbridge: [00:43:59] Thus far, LinkedIn has not broken my heart so how about there.

Kate Mueller: [00:44:05] People can still find you there, excellent. Thank you so much, Kenzie, this was an absolute delight. I think it's definitely given me some ideas and hopefully it's given the folks who are listening to this some ideas. I'm really excited about the resource list and having a bunch of stuff to go watch or try to use or learn more. Thank you so much for being so generous with your time today.

Kenzie Woodbridge: [00:44:27] Thank you very much, as well.

Kate Mueller: [00:44:32] The Not-Boring Tech Writer is produced by the lovely humans at Astronomic Audio. With editing by Dillon, transcription by Alan, and post-production by Been and Alex. Chad Timblin is our podcast head of operations. Our theme song is by Brightside Studio. Our artwork is by Bill Netherlands. You can check out KnowledgeOwl's products at knowledgeowl.com. If you want to work with me on docs, on knowledge management coaching, on revamping an existing knowledge base, go to knowledgewithsass.com. Until next time, I'm Kate Mueller and you are the not-boring tech writer.