Ady asks the MoTaverse #4 Mindset chapter draft
23 Sep 2026
Hello and thanks for reading. This is a draft of the mindset chapter for The Inclusive Mindset, from my attempt at a book titled "Thinking in Testing: Harnessing the power of deliberate thought in the AI era" (working title). I thought I'd start with something familiar. I want to make this as useful as possible which is why I'm sharing an early draft. My questions to you are.Ā
- Did you find it useful or interesting?Ā
- What was good or bad about it?Ā
- Is anything missing? (more examples, stories, theory etc.)Ā
- Does this make you want to read more, and if not, what could I do to make it more interesting to you?Ā
Thank you in advance for your assistance and help, and if you want to chat about this at MoTaCon please come and say hi.Ā
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, the inclusive mindset means approaching testing with empathy, 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 in a healthy dose of user-centred design thinking, and you've got the roots of it.Ā
Tim Berners-Lee had a core but very simple philosophy for the World Wide Web when he invented it in 1989. āThis is for everyone.āĀ
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, hasn't been tried one-handed, hasn't been 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.' What happens instead is 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 do teams overlook it? Usually not out of malice. It's more that it's invisible until you go looking. If everyone on the team shares roughly the same abilities, environment, and assumptions, there's no natural moment where the gap shows up. It has to be deliberately sought out, which is rather the whole point of a mindset you choose to switch into.Ā
You have probably heard of some of the examples of software and technology designed by one group that just doesnāt work for another because they were not there. Automatic soap dispenser that doesn't recognise darker skin tones. Facial recognition software that cannot differentiate some ethnicities. Wearable smart watches with data dropouts or incorrect readings for darker skin tones. From simple things like not having alternative text on sale icons so those who cannot see them miss out. To not being able to order food because they cannot navigate to checkout. But if it is not you, it take effort ot think about it.Ā
Iām not innocent in this. Before I began to learn all about digital accessibility and then related fields, Iād never given it a second thought. There wasnāt that much information about back then. But the more I learned, the more it felt like common sense to me. Iād just never had the prompt to move to the mindset. So donāt be as hard on yourself as I was. 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 making a difference and improving quality for everyone.Ā
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. Product owners get a bigger addressable audience, which, if we're honest, is also 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 of 15% of the global population are people with disabilities.Ā
Something to ponder. Only around 15 to 17% of people are born disabled. The majority become disabled through illness, accident, or simply through aging. So next time you are pondering whether to think about access, remember you are one bad day away from joining the demographic at any time.Ā
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.
There are a couple of cognitive biases worth naming here. The false consensus effect, assuming other people experience things roughly the way we do. And availability bias, where we test for the situations that are easiest for us to imagine because they're the ones closest to our own daily experience. The inclusive mindset is largely a deliberate counter to both these and related ways of thinking.Ā
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.
- Any mention of 'edge case' users (screen reader users, keyboard-only 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 here include running through input and interaction methods deliberately (mouse, keyboard-only, touch, screen reader, voice), and applying something like the accessibility angle of SFDPOT (Structure, Function, Data, Platform, Operations, Time) specifically asking who's excluded at each layer. There are so many different ones, donāt focus on one or two. Try a range and see what works for you.Ā
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 deficiancy 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. The colours are all shades of grey, so a colour change could present no visible change for them.Ā
What happens when I do or don't use it?
Signs you're using it well. The team naturally asks 'who might this not work for?' without being prompted. Test scenarios include more than one input method and more than one kind of user by default, not as a bolt-on accessibility pass at the end.
Signs you're not, or you're overdoing it. Every requirement gets treated identically regardless of actual risk, so low-stakes internal tooling gets the same exhaustive accessibility scrutiny as a public-facing product. That's overuse, and it burns goodwill for when it really matters. Or the opposite happens. Accessibility only gets checked right before release, as compliance box-ticking, treated as a separate phase rather than something baked into how the team already thinks.
What helps me?
Tools in general can help, but donāt over rely on the 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?
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
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
Meet at MoTaCon 2026
Review Conference Proposals
Write
Demi Van Malcot
I found it very useful and interesting, I especially like how clear the examples and excersizes are.
At some points/sentences I am unsure on whether it is a (sub)title and the formatting didn't copy or if you meant it to be jsut a sentence (in that case I do think it's missing subtitles).
What I miss is some variety for some fo the examples. In the paragraph that begins with "You have probably heard of some of the examples..." many exampels seem very similar in what wasn't thought about in that example. I think it needs more variety (or just more examples?).
I'm also missing some more concrete steps on how to start getting this mindset. Was expecting that in "how do I get better", but what follows isn't about that. Is it in a next chapter maybe?
Also wondering if the person indicated in "what works for me" and "how do I get better" are the same persons.
I am interested in reading more!
Ady Stokes
Thank you so much Demi. Some great points raised.
Formatting didn't move over.
I'll edit to make the headers bold to see if that helps.
Great feedback about more examples. Great idea to add an 'How to get started using it'.
There isn't a 'what works for me' section. Is this about the heuristics section where it says, 'see what works for you'?
Sign in
to comment
BearQ continuously tests your app, reducing test maintenance and uncovering gaps scripted tests can miss.
Explore MoT
Thu, 1 Oct
A tech conference to help you navigate the ever-shifting landscape of Quality Engineering, AI, Leadership, Product, Accessibility and Security.
Boost your career in software testing with the MoT Software Testing Essentials Certificate. Learn essential skills, from basic testing techniques to advanced risk analysis, crafted by industry experts.
Into the MoTaverse is a podcast by Ministry of Testing, hosted by Rosie Sherry, exploring the people, insights, and systems shaping quality in modern software teams.
