Inspired by this week's TWiQ (This week in quality) session and the "Making testing jobs safer for neurodiversity: Manual of Me" article by Maddy Kilsby-McMurray. I decided to make my own README.&n...

Community stars and ducks are a great combination in the MoTaverse. Celebrating 2222 stars 

Charles Penn asked  What resources do you use to decide what is most vital when you start advocating for Accessibility in an application? What resources do you use when you start testing for A...

New Collection

Simon Tomes asked:  Can you provide a list of legal accessibility frameworks/guidelines from across the globe?  I don't know every law, statute, and legislation across the globe, unfortun...

The RACI Matrix is a chart used to determine who is responsible for what. In software development projects, it’s far too easy for tasks to fall through the cracks because everyone assumes someone else is handling it. RACI addresses that by giving every task a clear set of "owners."  RACI stands for Responsible, Accountable, Consulted, and Informed. Here is how that breaks down: Responsible: This is the person (or people) actually doing the graft. They are the ones with their hands on the keyboard or the tools.Example: If the task is "Write the automation scripts," the Testers or SDETs are responsible. You can have more than one person in this bucket. Accountable: This is the most important one. The Accountable person is the one who has to answer for the work if it goes wrong and signs off on it when it’s right.The Golden Rule: You can only have one Accountable person per task. If you have two, you have none. It’s about having clarity to ensure things actually get finished to the right standard. Consulted: These are the people you need to talk to before or during the task. They have the expertise or the context you’re missing. It’s a two-way street—you ask for their input, and they give it.Example: If you’re setting up a new test environment, you’d consult the DevOps team to make sure you aren't about to break the network. Informed: These folks just need to know the result. They don't need to help or give permission. They just need a heads-up once the job is done. This is one-way communication.Example: Once a release is live, the Customer Support team is informed so they know what to tell users if they get a call. RACI isn't just about bureaucracy. When a team knows who is driving (Responsible) and who is ultimately answering for the journey (Accountable), decisions get made faster, and there’s less "blame game" when things get tricky. It’s a simple way to build TeamEx by removing the friction of ambiguity. 

Inspired by the following challenge: Create a Moment: Ask MoTaverse Anything.Thought I'd put myself out there to try my best to answer any questions about accessibility testing. It's a topic I've a...

Since I found out that my chronic back pain was caused by having one leg over 2cm longer. Since using a heel lift I’ve slowly been building up my walking. In honour of the Ingrow Cricket Club boys ...

Insightful session by Charlie n growing and maintaining an accessibility champion group within an organisation 

Looking forward to a talk on championing accessibility at A11y North. Tips to follow. 

Looking forward to discussing all things accessibility in Leeds tonight at Hippo Digital 

A stakeholder is anyone with a meaningful interest in the success, direction or impact of a software product. They influence decisions, shape priorities and experience the consequences of the team’s choices. Sometimes directly, sometimes from a distance. In Quality Engineering, understanding stakeholders is essential because each group values different outcomes, risks and information. There are many types of stakeholders. Here are a few examples:   Users and Customers  These are the people who actually use the product. They might be end‑users, clients, or internal teams. Their focus is simple. Does it help me do what I need, reliably and without friction? Roles can include users, customers, support teams, or operational staff. Their interests primarily centre on usability, trust, performance and stability.   Product Leaders  People like Product managers, product owners, or UX leads care about solving the right problems and delivering value. They focus on outcomes, customer impact, roadmap alignment and reducing uncertainty. Quality to them often means confidence. Predictable delivery, clear insights and fewer surprises. They could potentially have driving forces you may not be aware of.  Development Leaders  Engineering managers, tech leads and architects mainly look at feasibility, maintainability and technical risk. They care about system health, technical debt, scalability and the cost of change. Quality Engineering helps them see where the system is fragile and where investment will pay off.  Business and Executive Leaders  Directors, VPs and executives mostly focus on revenue, reputation, risk and strategic alignment. They want clarity, not detailed signals indicating whether the product is safe, stable, and moving in the right direction. Quality work becomes meaningful when it’s translated into business impact.  Developers  Developers are stakeholders too, although they often get forgotten about in that capacity. They tend to care about clarity, testability, feedback loops, and the ability to work without going back all the time (rework). Their focus is on building things that are correct, maintainable and easy to evolve.  Understanding stakeholders' values and needs means understanding what “quality” looks like from each perspective, so that quality professionals shape conversations, provide relevant evidence, and support decisions so everyone pulls in the same direction.