Making Tech Tutorials Accessible: Practical Techniques for Educators
Technical tutorials often exclude users due to situational, temporary, or permanent impairments. Addressing these barriers requires a shift from the medical model of disability, which views the individual as the problem, to the social model, which identifies the environment and design as the source of the disability. Accessibility features function as learning tools that benefit not only users with permanent disabilities but also non-native speakers and those in noisy environments.
An accessible video workflow involves several specific technical implementations. High-contrast thumbnails with large text ensure readability across devices. Scripts are simplified using AI to adhere to plain language principles: short sentences, active voice, and one thought per sentence. In DaVinci Resolve, subtitles are added manually with a minimum duration of three seconds and a maximum of five seconds per phrase to prevent cognitive overload. Audio tracks are recorded to match subtitles exactly, providing a baseline for low-vision users, while chapter timestamps in the video description create a navigable structure similar to heading hierarchies in documents.
Beyond video, general documentation accessibility relies on structural landmarks. Screen readers require proper heading levels rather than just bold or enlarged text to navigate content. Tools such as the built-in accessibility checkers in Microsoft Word, PowerPoint, and Excel, as well as online contrast checkers, help validate these elements. For German-language content, the Sachsen.de tool verifies adherence to Leichte Sprache (Easy Language) standards. Avoiding flashy red animations is critical to prevent seizures in users sensitive to motion.
This description was generated by Open-Source AI using the transcript of the session and the original submission contents.
This session took place in track Education, Career & Life and was classified suitable for novice domain by the speaker.
Submission
The proposal as submitted by the speaker before the conference.
Accessible content isn't just for people with disabilities—it makes tech education better by design for everyone. International learners, people on noisy trains junior developers and tired seniors at the end of the day—they all benefit from subtitles, simple language, and clear structure. Yet most developers who become educators have never learned how to make their content accessible. This talk shares practical techniques I use creating tech tutorials for deaf and hard-of-hearing learners. Since June 2025, I've been creating Excel tutorial videos with manual subtitles in simple language for a YouTube community (~400 subscribers). My partner is hard of hearing, which taught me that accessibility isn't optional—it's essential. The techniques could be applied to any tech content: Python tutorials, data science courses, documentation, or workshops. The talk follows this structure:
- Understanding Barriers (5 minutes) Who benefits from accessible content? People with permanent, temporary, and situational limitations.
- Creating Accessible Videos (15 minutes) My core workflow: manual subtitles in DaVinci Resolve with timing based on text length, using AI tools to simplify technical language, visual clarity with arrows and highlights, and the insight that you can't be accessible to everyone—focus on your target audience.
- Clear Structure for any Content (8 minutes) Applying video principles to any format: logical heading hierarchy for navigation, alternative text for images, using built-in accessibility checkers, and simple language techniques.
- Getting Started (2 minutes) One action to take this week, free tools to use, and resources for continued learning. I completed the W3C "Introduction to Web Accessibility" course and will be conducting a guest lecture on accessible learning materials at MSB Medical School Berlin (January 2026). As a non-native German speaker, I understand language barriers firsthand. Attendees will leave with practical techniques they can implement immediately and the confidence that accessibility is achievable without being an expert. No prior knowledge on accessibility is required.
Transcript (auto)
Auto-generated from the recording utilizing Open-Source AI. Speaker labels (Speaker 1, Speaker 2) reflect diarization, not identity. Timestamps refer to the recording.
Speaker 1 [00:06]
Good afternoon to you all. My name is Sumaya Nalukwago, and I'm the session chair for this session where we're going to be looking at how tech tutorials can be made accessible and they will be giving us practical techniques for educators. And this session will be by Tamara, who is a data analyst currently working at the National Association of Statutory Health Insurance Physicians in Berlin. And since June 2025, she has been creating accessible tech tutorials for deaf and hard-of-hearing learners. She also runs a YouTube channel focused on making Excel content accessible through manual subtitles and simple language. She holds master's degrees in migration and intercultural relations and sociology and social anthropology. She completed the W3C Introduction to Web Accessibility course and will be conducting a guest lecture on accessible learning materials at MSB Medical School in Berlin. She actually did it this January. As a non-native German speaker who is also a German sign language, Tamara understands language barriers and accessibility challenges firsthand. Please give her a round of applause.
Speaker 2 [01:26]
Hello, everyone. My name is Tamara Badikian. My sign language name is this sign. In German sign language, it means to learn. I chose this sign because I love learning new things. And in this room, I know I'm not the only nerd. So today I want to talk about accessibility and how we can benefit from it when creating tutorials or other educational materials. And I want to start with a personal story, how I came to accessibility. So my partner is hard of hearing and we communicate with German sign language used alongside spoken language. My sign language skills are not that great, I'm still learning. And whenever I would brag in front of him how much I learn Python or other data skills for YouTube, how much free and good education are just there, available to anyone, he would say, well, that's easy for you. For him, following this content is exhausting because automatically generated subtitles are not reliable enough, and if the language is complex or full of jargon, following the The content requires extra energy, extra effort, extra guessing every single time. And that is where the idea of creating my own tutorials came. So my first videos I made with my partner in mind. They are silent with subtitles and I keep the language as simple and direct as possible. No long sentences, just the information you need. Then someone called me an accessibility expert. Here I want to give a big shout out to Christian Rotter, who is tomorrow giving a master class. And yeah, I thought so, okay, well, I need to dig in and learn what it exactly means. And I learned I had been labeling my videos wrong. I was using the label Easy Red on my thumbnail not knowing that it was a regulated standard with rules and certification. Then someone from the accessibility community told me I could add voiceover to my silent videos and that would include people with low vision. I did that. Then someone told me that the animations I was using in the videos were too distracting, especially for people sensitive to motion. That is something I'm going to tackle next. So the process felt like debugging. I got an error, I tried to fix it, I got better errors. And here is the thing. Like testing, it's easier to think about accessibility early than try to fix it later. So let's walk through this together, starting with the why. There are two ways to think about accessibility and which one you hold shapes everything you build. The first is the medical model. The problem is the person, their diagnosis, their impairment, something to be fixed or accommodated. The second is the social model. The problem is the environment, the design, the barriers. A person who cannot use a mouse is not disabled by their hands, they are disabled by the website that requires one. A deaf person is not disabled by videos, by their hearing, they are disabled by videos without subtitles. Microsoft Inclusion Design Guidelines put it simply, disability happens when there is a mismatch between a person and their environment. And this shift matters because we create videos, we create courses, we decide whether barriers exist. So who is being excluded when we create content without considering accessibility? Well, more people than you might think. Accessibility guidelines identify three types of exclusion. Situational, temporary and permanent. Situational are temporary circumstances anyone can hit, like following a conversation in a noisy cafe or trying to use a keyboard while holding a baby. Temporary can last for weeks or days, like broken arms, perhaps tired eyes after looking on the screen the whole day. And permanent are deafness, low vision, dyslexia, or motor impairments. And any of us can move between these three groups at any time in our lives. Permanent exclusion, in particular, becomes more likely as we age. In Germany, almost 80% of people with severe disabilities are over 55. So, if we are likely to get old, we are all, statistically speaking, accessibility users. Now let's get into the how. Think of a fully accessible video, like software with optional modules. A complete feature set looks like this. You have closed captions you can toggle, a separate audio description track for blind users, a sign language interpretation track, playback control and the full transcript. And this is not just about disability in a narrow sense. People with learning difficulties or non-native speakers can also benefit from the same features. Think about how many people here learn Python in English not in their first language, or how often you rewatch a video just to catch a caught snippet that you are writing, that you are trying to copy. So subtitles can help you follow the content, playback control lets you go at your own speed, and transcripts make it possible to re-read and search. So these are not just accessibility features, those are learning features. And here is what I choose to prioritize in my videos and why. So my subtitles are always visible, YouTube supports toggleable captions, but my primary audience are hard of hearing, they need subtitles always on, that's why I have subtitles by default. I use some sign language in my videos, not a full interpretation track, but as a communication tool. It appears as a narrative moment, like in between the screen recordings. It is also partially because I wouldn't know how to sign technical terms like XLOOKUP or something like that. And a four to five minute video takes me 8 to 16 hours to produce alone. Editing, captioning, recording, reviewing, reviewing again. If I try to solve every accessibility requirement before publishing a video there will be no video. But the good news is each time you implement something new The next time it's going to be faster because you don't need to research it again. You already know how it works My me my videos are not barrier-free for everyone They are primarily accessible for deaf and hard-of-hearing viewers and people who benefit from plain language For others there are still barriers Knowing your audience and being transparent about that matters more than just a broad label saying accessible for deaf and hard of hearing tells people something real saying barrier-free often doesn't because barrier-free for a screen reader user doesn't mean the same as for a deaf person the label means nothing without content context and if you have already videos most accessibility features can be added retroactively. Subtitles, transcripts, audio description, a sign language version. Plain language is the only thing. For that, you need to recreate another narrative, and perhaps the best way is just to have the second version in plain language. Now let's walk through my workflow step by step. I started with silent videos, just subtitles and visuals. My newest video also includes a voiceover. Firstly, I choose the topic, for that I keep a running list on my phone. Whenever an idea pops up, I add it to the list. Then I pick the one that feels right for that moment. The first thing I do is design the thumbnail. I learned it from YouTubers, if no one clicks, no one watches. And here is where accessibility starts. Thumbnail needs large, readable text, high contrast, so that people watching on mobile phone can also see what is being shown. And before creating, before publishing the thumbnail, I make sure I test it on free available online tools when you can see how it will look like in a browser mode, in search mode, or in mobile mode. The first thing, before writing anything, the first question is, what story are we telling? What the viewer will gain, and is the video delivering what the thumbnail promises? If it doesn't, that's a clickbait, you lose the viewer's trust. the whole script I pay very close attention to the language so that it's easier to understand and for that I use AI. Once the script is done, it goes straight into the DaVinci Resolve, the free version. I add subtitles manually, one by one. Here's how it looks. Each one has a duration of five seconds. If the sentence is very short, I go lower, but never less than three seconds. Sometimes I also make it longer if I think like the idea is too abstract or it needs more time to land. And yeah, for the subtitle design, I use the templates available in DaVinci Resolve, the free version. After adding the subtitles, I record the screen, sentence one take each recording fits the subtitle exactly so and and to direct the attention I use also some icons or camera moves I want to show you a short fragment what it actually looks like in practice So you may have noticed the animations, the red frames, the icons, that is what I was talking about earlier that people sensitive motion can suffer under that and this is what I'm going to to change in my next videos and yeah the next step is the voiceover I read the subtitles aloud at the end of editing no extra commentary the audio matches exactly what is in the in the subtitles and the audio track is useful for people with low vision, for blind people you need a full audio description where you narrate everything that is going on the screen. I try to explain my tables before showing them, before demonstrating, so that people can understand what is it that I am showing. Yes, and when I upload the video I add chapter time steps to the description, viewers can jump directly to what they need and come back to specific parts later. This is how it looks. And yeah, so that's the video workflow. But the same principles could be applied beyond videos to documentations, tutorials, slides. So let's look at the few practical tools that could make any content more available, hard to read text, get read multiple times or not at all. And readable texts do something else, they give the reader a sense of achievement. Understanding something easily feels good, that feeling keeps the reader going. In German there are two distinct standards worth knowing, Leichte Sprache which is regulated and the einfache Sprache which is not regulated and it roughly corresponds to A2 to B1 German level and this is what I'm striving to in my videos. Those are the five principles of five languages that you can accommodate. Short sentences, active voice, one thought per sentence, if you find yourself writing which in order to then make two sentences out of that explain the jargon or use simpler words and then clear structure headings white space structure is not decoration it's a navigation and a quick way to check the text is to read it out loud for yourself if you stumble simplify and if you want to check against the German Leichter Sprachstandard, there are tools like this one from Sachsen.de where you just copy your text and it says which difficulty level it is. Something I learned from Claudio Zeni, a blind accessibility consultant, accessibility means creating structure in websites, in documents, so that machines can navigate it. Screen readers are machines. If the structure isn't there, they can't navigate it. In a video, chapter timestamps do that. They let the viewer jump to the part that they want or rewatch it later. And in a document, heading hierarchy does the same thing for humans and machines. A heading is not a font size, it's a navigation landmark. Screen readers use levels to jump from one part to the other, and if instead of heading you have just bold text or bigger font, the machine cannot read that, so the screen reader user wouldn't know what they are watching at. And most documentations have built-in styles that you can use. And you saw it already that I pick high contrast subtitles from DaVinci Resolve, and the same principles could be applied for any documentations, and there are tools to check contrast between text and background. One example is this one here. You take the pipette, and then it shows the contrast between the font and the background. One tool worth knowing is the built-in accessibility checker, which is in Word, PowerPoint, and Excel. You find it under the review tab, just run it before sharing anything. And if you want to fill yourself what barriers are, try one of the two free browser games on this slide. Or you can also try navigate a website just using the keyboard or activate on your phone voiceover and try to open an app. There are ways to kind of simulate how it feels when you have certain kind of impairments. Yeah, and I'm coming to my closing. Often we frame accessibility as a legal framework, a compliance checklist, a deficit to fix. That framing is itself is a kind of medical model and those legal and ethical frameworks matter because without them real harm can be done but that's not why we should do that. When I started thinking about disability something else happened. I thought harder about how I communicate, I questioned what I assumed was obvious and then it changed what I make and how I think. For me it's been one of the most creative challenges and there is a quote from Eric Belay, he's an accessibility advocate and developer. He says, I don't hate fun, I just don't want to hurt people. It's about animations, he himself enjoys animations but he knows that it can harm people who are sensitive to motion and once you know that, it changes how you make your decisions. So next time you create a tutorial, think about who else might be using them. The people who benefit from accessible content are not a small age group. People on noisy trains, people working in a second language, people new to the field or junior developers. And when you create content with accessibility in mind, you make better content for everyone. If you want to connect with me, please and I thank you very much for your attention
Speaker 1 [21:00]
Thank you so much, Tamara. I personally enjoyed the session and you have a number of questions here. Do you know of any linter for the plain or easy language mentioned, for example, to report sentences that are too long?
Speaker 2 [21:16]
Unfortunately not, no. I'm just using AI to simplify the language and also this, there are not only from this, from Sachsen.de, but there is also one other thing available that you put the, like the paragraph and it makes it in Leichter Sprache, so it simplifies it. But yeah, that's one I use.
Speaker 1 [21:44]
Okay. Let me see some other questions. How do you decide which animation is okay to include and which one is not? Is there a rule of thumb? And thank you so much for the inspiring talk.
Speaker 2 [21:59]
Yeah, thank you. Actually, the worst thing that I have chosen is this red animation because it's red and it's flashy and red can really create seizures for people who are sensitive to motion. And just don't pick red. Try to pick other colors and maybe make less motion or I don't know. I haven't figured out how I'm going to do that because I myself also like this popping up and that, so I have to also kind of restrain myself. I'll figure it out.
Speaker 1 [22:35]
Okay. How can I convince my company to improve the accessibility of our product? Their product is, they have e-learning video courses when their counter argument is that too few customers would benefit and it doesn't justify the cost.
Speaker 2 [22:52]
What is the question? How to convince them?
Speaker 1 [22:54]
Convince the company to improve the accessibility of their product, which is e-learning video courses. And their counter-argument is that too few customers would benefit, and it doesn't justify the cost.
Speaker 2 [23:06]
Yeah, well, you can tell them that it's not just a few, we all will benefit from them. And as I said, hopefully we will all get old and we will all rely on the accessible content. Yeah, I think the legal regulations are getting stricter. I mean, I don't know if you have ideas, please write to me. I would also love to convince companies. Okay.
Speaker 1 [23:36]
Why do you prioritize subtitles and sign language? Are subtitles not sufficient?
Speaker 2 [23:42]
Subtitles in plain language? Yes, because you can understand it easily and if the subtitles like long sentences so people are getting confused especially if you are showing you go to this tab and that tab I think it's just too much load for our head and I am trying just to make them as easy to consume as possible.
Speaker 1 [24:10]
Okay. The animation highlights are awesome. Can you share what you used to build it?
Speaker 2 [24:16]
I do them manually with DaVinci Resolve. That's why it takes me ages to produce one video. I do them manually. It's not a couple of moves. But you can also create a kind of form that you can reuse again. It is there and then you are just moving on the part on the screen that you want to have it. So, yeah, but it's all in DaVinci Resolve.
Speaker 1 [24:50]
great talk. Thank you for sharing. Will you share your slides on Discord?
Speaker 2 [24:54]
What to share?
Speaker 1 [24:56]
What to share? Sorry.
Speaker 2 [24:58]
Sladek okay yeah the slides I can also send you if you get in touch with me yes I will do that
Speaker 1 [24:58]
The slides, your slide deck.
Speaker 2 [25:04]
I will just make them available on the pre-talks I think it's called because I'm not on this court okay is that okay
Speaker 1 [25:15]
yeah it should be fine okay uh thank you so much for such a wonderful thank you
Speaker 2 [25:18]
It was a wonderful talk. Thank you.
