Kill accessibility rework.

Reading time is around 2 minutes. You can also read this online. A Head of Product can't review every accessibility decision and I don't think they should even try. I bet this makes you feel like you're off the hook. It may even feel reassuring at first. But mind you, all important decisions still get your attention if you want to catch mistakes before they create rework. You just don't want to become the bottleneck. If your people start waiting for approval instead of using their own...

Reading time is around 2 minutes. You can also read this online. What happens after I listen? This will sound simple, but for me it took a lot of practice and I still mess it up quite often. So once someone explained how they got there, the first rule is I don't rush to a response because then I'm back to "if I were you" territory. Instead, I say back to them what I heard in my own words. You had two days to build this, the usual component didn't work and nobody tested the new one with a...

Reading time is around 1 minute. You can also read this online. Gary: We finally talked about why accessibility issues keep appearing right before a release. Sarah: Good. What did you learn? Gary: Nobody was responsible. Sarah: Okay. So who's fixing it? Gary: Nobody. We haven't found anyone to blame yet.

Reading time is around 1 minute. You can also read this online. How did this happen? I always thought this question sounded more like an accusation. But I never meant it that way, even if it could sound like I was asking who I should blame. I’ve always asked that question with good intentions and watched people become defensive. They would start explaining themselves instead of helping me understand the work. I've switched it a bit since. Now I usually ask people if they can walk me through...

Reading time is around 2 minutes. You can also read this online. Just because I listen doesn't mean I agree. I can understand why you shipped an inaccessible feature and still say we need to change it. It took me a while to learn that. I used to worry that asking too many questions would weaken my position. So I thought showing up to a meeting with all the answers meant I was coming in from a position of strength. Sometimes I was right. But being right was usually much less useful than I...

Reading time is around 2 minutes. You can also read this online. I used to talk to people and think my job was to have all the answers to their questions. Someone would show me a design or a piece of code and I'd immediately see what I would change, what's wrong and what's worth keeping. If I were you... I'd start saying. There's a problem with that approach. I wasn't them. I didn't have their deadlines. I wasn't in the meetings where the scope changed. I had no idea which technical...

Reading time is around 1 minute. You can also read this online. Accessibility rework rarely starts when QA finds a bug. It starts earlier, when you skip a decision or leave it hanging. But when? And how do you figure that out? Here are three questions you can ask your team to find out. When do we first discuss how a feature works with a keyboard, screen reader or zoom? If the answer is "during QA" or "after release," the team is learning too late. By then, design and code may both need...

Reading time is around 2 minutes. You can also read this online. There's certainly a point when "done" is defined too late. But can you define "done" too early? Yes, I think so. A Definition of Done should reduce ambiguity, not create fake certainty. So there's probably a point in your process when you could potentially get ahead of yourselves. That's when you write rigid acceptance criteria before you understand the problem. You define detailed accessibility behaviour for a flow that may...

Reading time is around 2 minutes. You can also read this online. When you don't define "done" early, you often end up defining it under pressure, close to the release. That's a terrible time to do it because that's when the decision becomes the most expensive and people the most unreasonable. Days before the release, "does this need fixing" becomes tangled with roadmap commitments, customer promises, stakeholder expectations, engineering capacity, QA time and the emotional fact that everyone...

Reading time is around 1 minute. You can also read this online. Gary: We now have a new accessibility success metric. Sarah: Great. What is it? Gary: Number of accessibility tickets closed. Sarah: Sounds sensible. And if the same issue keeps coming back? Gary: Then we get to close more tickets. Sarah: That's not success. Gary: It is if you look at the chart.