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. 

A spike, or sprint spike, is a deliberate pause for learning. A short, time‑boxed piece of work the team uses when they’ve hit a “we don’t know what we don’t know” moment. Or a way to experiment, investigate or understand something. Instead of guessing or hoping, a spike gives you space to explore, experiment and reduce uncertainty before committing to a full solution or more permanent change.  The idea originated in Extreme Programming (XP), where it was used as a metaphor of driving a spike into the ground to test whether it would hold. If the spike is solid, you can build on it. If not, you’ve saved yourself from constructing something on shaky foundations. The same principle applies in software. Prove the concept first, then build with confidence.  To stay useful, spikes need a little discipline. The best ones are time‑boxed, have a clear purpose and outcome, and are reversible. Think of them as a sketch, not an oil painting. Quality Engineers and professionals like spikes because they are low-risk and potentially high-reward. A spike lets you “test the idea” first. They can expose hidden dependencies, highlight awkward integrations, prove or disprove theories, and identify architectural unknowns long before they become late‑sprint surprises.   At their heart, spikes are a strategic pause, a reminder that sometimes the fastest way forward is to stop, learn and remove the unknowns. They turn “we think this will work” into “we know how this will work, and here’s the evidence.” 

A sprint is essentially a focused, time-boxed burst of work. Instead of trying to build the whole product at once, a team takes small, manageable slices, works on them for a set period, and delivers something meaningful and / or valuable at the end. It’s the heartbeat of incremental and Agile development. The concept was born out of Scrum in the 1990s. In contrast to traditional or Waterfall methodologies, moving to shorter cycles allows teams to get faster feedback, learn from their mistakes sooner, and avoid those nasty "end-of-project" surprises that keep everyone up at night.  Sprints usually last anywhere from one to four weeks. The team itself is usually cross-functional, meaning you’ve got developers, designers, Quality Engineers, etc, all pulling in the same direction. It’s not all about who has what job title. It’s about the shared commitment to getting a "done" increment out the door. A sprint isn't just a calendar entry or a block of time. It’s a habit of working in small incremental steps, adding chunks of value. It creates a rhythm that allows the team to tighten their feedback loops and build quality into the product. It is a method that helps teams learn and improve with every cycle, often through retrospectives, and versions of sprints are the way a majority of software development happens.