Ady asks #5 Mindset chapter draft updated after feedback

14 Oct 2026

In this moment: Gokul Sridharan Melissa Fisher Gary Hawkes Jonathan Cole Demi Van Malcot Justin Holsgrove

Ady Asks the MoTaverse. Hi everyone, thank you for your great feedback on the first draft of this chapter. I've taken your thoughts, feedback, and ideas on board and here is the updated version. I've tagged everyone who commented previously, so you will hopefully take another look. No promises on whether I used your ideas, though :)

I'd appreciate everyone's thoughts. Is this better? Are any parts worse? Is it useful? Any feedback is welcome. Thanks

The Inclusive Mindset

Explore how to approach testing with empathy and a focus on diverse user needs, like those related to digital accessibility, usability, and inclusion. This mindset is the habit of testing for people who are not you.

What is it?

Picture a palatial building with a grand set of stone or marble steps leading up to the front door. Beautiful. Impressive. Opulent and completely in tune with the aesthetic of a place. And yet completely useless to someone in a wheelchair, someone pushing a pram, or someone who's just had knee surgery and is using crutches.

Now picture the same building with a ramp built in alongside those steps from the very start, not bolted on as an afterthought once someone complained. Done with an inclusive mindset, it may sweep from left to right on one side and do the opposite on the other. The design is totally in tune with the whole, and planting accentuates the lines to make it look like the staircase is embraced by the architecture around it. It works for everyone, including those with wheeled luggage. Same building. Wildly different experience depending on who you are.

That's the inclusive mindset in a nutshell. It's the habit of asking who else will access this building, not just the default person we imagine, which is usually ourselves.

In plain English, an inclusive mindset means approaching testing with empathy and deliberately looking at things from more than one person's point of view. Accessibility is a big part of it, but it doesn't stop there. It's about usability, emotional responses, and whether the thing we've built has actually thought about the person on the other end, whoever they turn out to be.

If you want the one-liner version, here it is.

You are not the user, so stop testing like you are.

Where did it come from?

This one didn't come from a textbook. It grew out of accessibility and usability practice bumping up against the much older, much simpler idea that software gets used by actual humans, and humans are wildly different from one another. Add a healthy dose of user-centred design thinking, and you've got its roots.

Tim Berners-Lee had a core, but very simple philosophy for the World Wide Web. “This is for everyone.” The web is universal in design. Layers of complexity have undermined that. It should work for every ability, on every device, in every language, everywhere.

In 2016, the UN declared internet access a human right.

These are not new ideas.

The dogma it pushes back on is something I'd call 'works on my machine, for someone like me.' You know the one. Where a login screen gets tested by three developers on the same laptop, in the same office, with the same eyesight, using a mouse, in good lighting, and everyone declares it done. It works! Ship it! Except it hasn't been anywhere near a screen reader, tried one-handed, looked at by anyone who doesn't read English as a first language, and nobody's checked what happens in bright sunlight on a phone screen with the brightness turned down to save battery.

Where does it sit in our four groups? Philosophical and connected, alongside ethical and collaborative. That's not by accident. All three of those are about looking outward, past the ticket in front of you, to the people and relationships the software actually touches.

Why it matters

Skip this mindset and here's what happens. The software works, technically, for the imagined 'default' user, and fails quietly for everyone else. Quietly is the dangerous word there. Nobody gets a big red error message saying 'accessibility has failed.' Instead, someone just can't use the thing, gives up, and you never hear about it. That's a much harder problem to spot than a crash.

Why does it get ignored?

Why do teams overlook it? Usually not out of malice. It's more that it's invisible until you look for it. If everyone on the team shares roughly the same abilities, environment, and assumptions, the gap rarely shows up naturally. You have to seek it out deliberately, which is the whole point of switching into a different mindset.

Why inclusive teams matter

You have probably heard examples of software and technology designed by one group that just doesn’t work for another because they weren't there. An automatic soap dispenser that doesn't recognise darker skin tones. Facial recognition software that cannot differentiate some ethnicities. Wearable smartwatches that drop data or give incorrect readings for darker skin tones. From simple things like missing alternative text on sale icons, so people cannot see the bargains and miss out. To being unable to order food because you can't navigate to checkout. But if it is not you, it takes effort to think about it.

A couple of cognitive biases are worth naming here. The false consensus effect, assuming other people experience things roughly the way we do. And availability bias, where we test for situations that are easiest to imagine because they're closest to our daily experience. The inclusive mindset is largely a deliberate counter to both these and related ways of thinking.

The value of an inclusive mindset

Back to why it matters. Here's the value it brings to stakeholders. Developers get fewer late-stage surprises when accessibility is baked in rather than bolted on. It is considerably cheaper too. Testers get a genuinely richer set of scenarios to work with, not just a longer checklist. Stakeholders get a bigger addressable audience, which, honestly, is just good business. And end users get software that actually works for them, which is rather the entire point of building it in the first place.

Look up the purple pound / dollar, etc. or inclusive market, which is the spending power of disabled people and their households. Globally, it is estimated to be worth between 8 and 18 trillion dollars. In the UK, where I’m from, it is up to £446 billion annually. If anyone says, and this is an actual statement, “But we don’t have disabled users.” Tell them that if it is because of inaccessible software, they are potentially missing out on 10 to 15% of users and revenue. Source: We the 15. A global human-rights movement to raise awareness that 15% of the global population are people with disabilities.

It could be you

Something to ponder. Only around 15 to 17% of disabled people are born disabled. The majority become disabled through illness, accident, or simply through ageing. So next time you are pondering whether to think about accessibility, remember you are one bad day away from joining that demographic. So you could think of it as testing for future you.

I’m guilty too

This is where quality connects back to social value rather than just 'does it crash.' A perfectly stable, bug-free login screen that a screen reader user can't operate isn't high quality. It's high quality for a subset of people, and quietly indifferent to everyone else. I’m not innocent in this. Before I started learning about digital accessibility and related fields, I’d never given it a second thought. There wasn’t that much information about accessibility, user experience or inclusion back then. But the more I learned, the more it felt like common sense to me. I’d just never been prompted to shift my mindset. I felt very guilty about all the things I could have done to make things better for others. There’s still time. I became an advocate. I believe I’ve helped people understand and begin their own journeys. By embracing this mindset, you can begin your journey to start making a difference and improving quality for everyone.

How do I get started using it?

Start at the beginning. Sounds obvious? A bit ‘oh he’s on about shift left again!’ Sort of. You can think inclusively at any time, in any conversation or activity about anything. But to bring the focus back to software development. When you are looking at a new design, requirements or even a feature. Put your inclusive mindset on by thinking about how other people might use it. Remember, this mindset is about testing for everyone, not just ourselves.

I try to flip my defaults around. Think about scenarios that are the opposite of how I, or you, would interact with something. A few examples are:

If you use a mouse, use only the keyboard
- Can you still get to everything, navigate easily, and see where you are on the page?
If you can see the screen, use a screen reader
- Are you hearing an equivalent of what you are seeing? Are all the labels and buttons announced? Is anything missed or misrepresented?
If you have good vision, test zoomed in or with larger text settings
- Does the layout still make sense at 200%? Does anything vanish? Does text leak out of its frame?
If you don’t struggle on bright days, test high contrast
- Use contrast themes, inversion extensions, or any high contrast modes available. Does anything disappear?

I don’t want to bore you, but the best way to get started is to think of others. In 2018 at TestBash Manchester, wearing a Gotham City Police Department t-shirt (yes, I was that guy back then), I used my 99-second talk to ask three simple questions. That talk is available in a 99-second talk video from TestBash Manchester 2018 on the Ministry of Testing website.

I asked everyone who was able (inclusive mindset in action before I was more self-aware) to put their hand up, then lower it if they answered yes. See how you get on.

Do you wear glasses or contact lenses?
Have you ever had to zoom into writing or a document because the writing was too small?
Have you ever had to use a device with one hand because you were holding a pint, or a book, or even shopping? (Yes, that’s my priority order, you do you)

Did number 3 get you? It does get lots of people. In Manchester that day, after all three questions, only two people had their hands still up. I invited the audience to meet the ‘perfect user’ that most of our systems are designed and tested for. That's because we weren't, and still aren’t, thinking about accessibility from the start. You get the point, I hope. Not intentionally. Not to discriminate. Not to cause harm. Just because we were testing for ourselves, and not using an inclusive mindset.

Areas to research

Some of these areas are huge, so don’t put pressure on yourself to know everything quickly. Quality information, even small amounts, leads to questions and improvements. Read, watch, or learn something. Find out how to apply it to your circumstances. Add a bit more when you can. Everything in this book is a great step toward expanding that knowledge, becoming more inclusive, more understanding, and more thoughtful. Be kind to yourself on your continuous learning journey.

Digital accessibility
Inclusive and universal design (recommend starting with Microsoft’s inclusive design toolkit and following Kat Holmes, who led the work)
User experience
Standards and Legislation (Web Content Accessibility Guidelines, Americans with Disabilities Act, Section 508 of the Rehabilitation Act, European Accessibility Act, Equality Act 2010, Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018, local and national regulations)

Other areas to consider

Yes, sorry, there’s more. Same rule as above.

Emotional, cognitive, and compassionate empathy
Confirmation bias
Inclusive language
Readability
Cognitive ability

When should I use it?

Early, ideally. Backlog refinement and three-amigos sessions are a great place to start. An assumption in a requirement is far cheaper to catch and address there than three sprints later.

Signs you need this mindset right now

The requirement describes 'the user' as if there's only one kind.
Everyone in the room nods along with little or no discussion. That's often a sign nobody's pictured a genuinely different user yet, not that everyone's agreed on the right answer.
'Edge case' users (assistive technology users, users on old devices, users in a second language), if it comes up at all, comes up right at the end, almost as an apology.

Useful heuristics include deliberately running through input and interaction methods and applying an accessibility and inclusion angle. Specifically asking who's excluded at each layer. There are so many heuristics out there. Don’t focus on one or two, or even make up your own. Try a range and see what works for you in your context.

Scenario

A tester reviewing a new checkout flow notices the 'add to basket' confirmation only appears as a colour change on the button, no text, no icon. Automated tests pass fine, because the button's state changed correctly in the code. A tester applying the inclusive mindset asks a simple question. What does a colour-vision-deficient user see happen here? Nothing, as it turns out. A one-line fix (adding a text confirmation) prevents a genuinely confusing experience for a meaningful slice of users, caught before release rather than in a support ticket. A red-green colour deficiency is a common condition where a person has trouble telling the difference between red, green, and related shades like brown and orange. Because the colours are similar shades, a colour change may not be visible to them.

What helps me?

Tools in general can help, but don’t over-rely on automated checkers.

Screen readers (turn one on and actually try to use your own software with it). I wouldn’t recommend more than 5 to 10 minutes to begin while you get used to what it is actually telling you.
Colour contrast checkers and browser accessibility audit panels. Not glamorous, but genuinely useful.
Automated checkers and devtools. There are plenty of options for extensions like WebAIM’s WAVE tool. WebAIM is the Web Accessibility in Mind organisation, and the WAVE tool is a free Web Accessibility Evaluation Tool. They also provide the screen reader NVDA (NonVisual Desktop Access) for free too. Well worth checking those out and their training too.

Diagnostic heuristic questions can be useful for triggering the mindset.

Who did I picture using this while I was testing it?
Could someone complete this task without a mouse? Without sight? Without reading the language fluently?
Where does this software assume a 'default' user, and who does that default quietly exclude?
If I got a complaint from someone I hadn't considered, what would it likely be about?

Chapter exercise.

Pick a feature you tested recently. Try it again using only the keyboard. Then try it with your monitor turned off and a screen reader running. Write down every point where you got stuck or confused. That list is your inclusive mindset test charter for next time.

What to avoid

Overuse. Treating every feature as equally high-stakes for accessibility regardless of actual audience or risk, which burns time and credibility.
Underuse. Leaving it until a compliance audit or a complaint forces the issue.
Wrong time. Trying to bolt inclusivity onto a finished design rather than considering it while the design is still flexible.
Lack of understanding. Treating 'inclusive' as solely meaning 'accessible to disabled users,' when it's a broader lens covering language, culture, device, environment, and more.

How do I get better?

Have you used this mindset? Think of a specific time. What did you notice that you might otherwise have missed?

Has your team used it, even without naming it that way? What did that look like, and what did the team gain?

Has your organisation? If not, what would likely happen if it did, and what's stopping it right now?

Team challenge

In your next refinement session, spend ten minutes deliberately using only the inclusive mindset. Say nothing else. Just ask, again and again, 'who might this not work for?' Write down everything the team notices that would otherwise have gone unsaid.

A final thought. How does thinking inclusively help create better quality, in your context? Not in general. In yours.

Ady Stokes

Freelance Consultant

He / Him

Award Star

MoT Ambassador. Currently semi-retired and freelancing. I am, amongst other things, a writer, speaker, and accessibility advocate. Leeds Chapter Lead. MoT Certs curator and article editor for WonderProxy. Testing wisdom, friendly, testing songs and poems. Great minds think differently. STEC and SQEC Certified. Struggling to write a book about testing mindsets and thinking's application in software development.

Open To

Teach

Speak

Podcasting

Review Conference Proposals

Write

Meet at MoTaCon 2027

Attending MoTaCon 🤝

Chapter Lead

Ambassador

Demi Van Malcot

I like allt he improvements you made. Already lookign forward to the rest of the book 😉

6 minutes

Explore MoT

From test cases to AI-ready quality data: why structure matters

Thu, 15 Oct

Learn how to structure and organize test management data as an AI-ready foundation that gives AI systems richer context for testing insights and workflows.

Introduction To Accessibility Testing

Learn with me about what Accessibility is, why it's important to test for and how to get your team started with an Accessibility testing mindset

14 Apr 21

Course

This Week in Quality

Debrief the week in Quality via a community radio show hosted by Simon Tomes and members of the community