Accessibility as Culture Change: How Agile Can Drive Systemic Inclusion

Welcome back, equity champions! In our journey so far, we’ve embedded accessibility into stories, sprints, personas, dashboards, and release cycles. But now we zoom out and ask the big question:

How does accessibility become not just something we do, but something we believe?

It begins when Agile values align with inclusive intent and create a culture where access is no longer an afterthought; it’s a norm.

 Why Accessibility Needs Culture to Thrive

Tools can prompt awareness. Checklists can improve deliverables. But culture is what sustains inclusive design across time, turnover, and evolving priorities.

Without cultural alignment:

• Accessibility remains siloed with specialists
• Momentum fades after audits or compliance deadlines
• Teams revert to exclusionary defaults under pressure

With cultural commitment:

• Inclusion becomes part of team identity
• Accessibility is framed as innovation, not obstruction
• Everyone becomes accountable for equitable outcomes

 Agile’s Core Values as Accessibility Accelerators

Agile isn’t just a workflow, it’s a belief system. And every value has inclusion baked in:

Accessibility is change-responsive, user-driven, and iterative. It’s Agile at its best.

 How to Foster Accessibility Culture Within Agile Teams

 Normalize Inclusive Language

• Refer to access needs naturally in daily standups
• Use phrases like “barrier,” “perceivable,” “operable,” “cognitive load”
• Avoid saying “special needs” or “edge case”, every user is valid

Make Learning Ongoing

• Create internal workshops or lunch-and-learns
• Encourage team-wide accessibility certifications
• Share updates on evolving guidelines (WCAG, EN 301 549, etc.)

 Cultivate Psychological Safety

• Allow teammates to speak up when a design feels exclusionary
• Encourage accessibility champions (previous episodes) to lead without being siloed
• Make retros a place to explore inclusion openly

 Celebrate Inclusive Wins

• Highlight stories that improved usability for underrepresented users
• Showcase accessibility metrics alongside speed and scope
• Invite feedback from diverse users and communities

Culture Is the System We Operate In

Agile gives us a framework. Accessibility gives us purpose. Together, they form a system of equity, where teams continuously reflect, refine, and rebuild with empathy at the center.

Accessibility as culture means:

• It’s not a task—it’s a value
• It’s not owned—it’s shared
• It’s not the end—it’s the beginning

Ask your team: What silent norms are shaping our work, and how can we evolve them toward inclusion?

Next in the series: Agile Leadership for Accessibility: Driving Systemic Change from the Top We’ll explore how team leads and execs can model accessibility, fund inclusive initiatives, and embed access in product vision.

Would you like to turn this episode into a keynote-style deck or create a team reflection worksheet to start the cultural shift? We’d be excited to help co-design that with you!

Agile promises continuous improvement. But when it comes to accessibility, improvement often plateaus once initial barriers are addressed. How do we keep equity and inclusion alive, not just during sprints, but across quarters, product phases, and organizational shifts?

It starts with embedding accessibility not just in rituals, but in roadmaps.

What We Mean By “Accessibility Momentum”

Momentum here means keeping accessibility:

•  Prioritized amid changing team goals
• Embedded in strategic planning, not just tactical fixes
• Supported with resources, feedback loops, and leadership backing

Accessibility isn’t a feature, it’s a value system. Roadmaps are the place to reinforce it.

Strategies to Keep Accessibility Moving Forward

Here’s how to turn good intentions into lasting impact:

1. Build Accessibility into OKRs and KPIs

• Link accessibility goals to business metrics (retention, NPS, inclusive design adoption)
• Use key results like “100% of new components meet WCAG 2.1 AA”
• Report progress publicly to foster accountability

2. Create Dedicated Accessibility Tracks

• Include accessibility work as its own swimlane or initiative
• Don’t bury inclusive work under “tech debt” or “nice to haves”
• Forecast impact and budget for inclusive upgrades ahead of time

3. Use Feature Flags for Inclusive Design Testing

• Roll out alt text enhancements, improved navigation, or keyboard tweaks behind flags
• Let users opt into inclusive prototypes and give feedback
• Track adoption and iterate just like with any other feature

4. Make Accessibility a Release Gate

• Treat accessibility bugs like functional blockers
• Define “done” as accessible for all personas
• Have accessibility testing in your definition of readiness

 Building the Roadmap Itself Accessibly

Your roadmap should be inclusive too. Ask:

• Can stakeholders read it with assistive tech?
• Is it available in multiple formats (Kanban, spreadsheet, PDF)?
• Does it use high contrast, simple structure, and clear labels?

Tools like Product Board, Aha!, and Road munk offer accessibility options, choose one that aligns with your team’s needs.

Keep Communication Loops Open

Accessibility evolves. Your roadmap should, too.

• Run quarterly roadmap reviews with inclusion in mind
• Invite feedback from disabled users and advocates
• Celebrate accessibility milestones just like feature launches

 Thought Starter

Ask your team: Are our long-term goals building something that welcomes every future user, or just the ones we already have?

Accessibility as Culture Change: How Agile Can Drive Systemic Inclusion We’ll explore how to make accessibility a cultural value across teams, not just a checklist.

Would you like a visual version of this roadmap strategy or a set of OKR templates to kick-start inclusive planning? We`d love to co-create it with you.

Welcome back, advocates of equity-driven design! If you’ve been following the series, you’ve already seen how accessibility can transform Agile workflows, from user stories and CI pipelines to ceremonies and culture. But here’s a question we don’t ask often enough:

Are our Agile artifacts usable by everyone on the team?

Let’s explore how to craft boards, dashboards, documents, and visuals that don’t just organize work, but enable everyone to participate fully.

What Are Agile Artifacts?

In Agile, artifacts are physical or digital tools that support transparency, alignment, and collaboration. These include:

• User story cards or tickets
• Product backlog and sprint boards
• Burndown charts and dashboards
• Retrospective summaries and documentation
• Design files and wireframes

They may look simple, but when poorly designed, they can exclude people with disabilities or access needs.

Common Barriers in Agile Artifacts

Even high-functioning teams run into accessibility gaps:

•  Tight font spacing, low contrast, or color-only indicators
•  Tools that don’t support keyboard navigation or screen readers
•  Visualizations without alt text or contextual labels
•  Documentation with dense, jargon-heavy copy
•  Story cards filled with emojis or icons that don’t translate to assistive tech

Inaccessible artifacts create real bottlenecks for team members, impacting how they engage, contribute, and lead.

Inclusive Design Tips for Agile Artifacts

Here’s how to make your Agile tools welcoming and usable for all:

1. Backlogs and Boards

• Use high-contrast themes and readable typefaces
• Ensure drag-and-drop functions are keyboard accessible
• Label all columns and tags with clear, descriptive text
• Choose tools with strong support for screen readers (e.g., Jira with accessibility plugins)

2. User Story Cards

• Avoid emojis or color-only labels (e.g., red = urgent)
• Add plain-language descriptions alongside technical criteria
• Structure cards semantically for assistive tech
• Include accessibility flags as standard metadata

3. Dashboards & Charts

• Ensure charts include data tables or alt text
• Use patterns + labels to differentiate data, not color alone
• Make metrics explainable (avoid “mystery metrics”)
• Choose responsive layouts that adjust for zoom and screen size

4. Retrospective Docs

• Share summaries in accessible formats (HTML or tagged PDFs)
• Offer asynchronous participation options for feedback
• Use headings, bullet points, and simple language
• Avoid images or icons without alt text or context

 Tooling That Helps

Pro tip: Run periodic artifact audits using tools like WAVE, axe DevTools, or Lighthouse to catch common issues.

Artifacts Are Participation Gateways

Agile thrives when every team member can see, shape, and share progress. Accessible artifacts aren’t just ergonomic, they’re ethical.

When your dashboards can be navigated by a keyboard, when your story cards speak clearly to screen readers, and when your documentation welcomes neurodiverse contributors, you stop managing tasks and start enabling people.

Ask your team this week: Which of our artifacts are speaking, and who are they leaving silent?

Next up in the series: Maintaining Accessibility Momentum in Agile Roadmaps We’ll explore how to keep accessibility prioritized beyond day-to-day rituals, through long-term planning, OKRs, and strategic decisions.

Want help creating accessible design templates or an artifact audit checklist? I’d be happy to build one tailored to your toolkit!

Whether you’re building embedded software for next-gen diagnostics, modernizing lab systems, or scaling user-facing platforms, the pressure to innovate is universal, and AI is becoming a key differentiator. When embedded into the software development lifecycle (SDLC), AI offers a path to reduce costs, accelerate timelines, and equip the enterprise to scale with confidence. 

But AI doesn’t implement itself. It requires a team that understands the nuance of regulated software, SDLC complexities, and the strategic levers that drive growth. Our experts are helping MedTech leaders move beyond experimentation and into execution, embedding AI into the core of product development, testing, and regulatory readiness. 

“AI is being used to reduce manual effort and improve accuracy in documentation, testing, and validation.” – Reuters MedTech Report, 2025 

Whether it’s generating test cases from requirements, automating hazard analysis, or accelerating documentation, we help clients turn AI into a strategic accelerator. 

AI-Accelerated Regulatory Documentation 

Outcome: Faster time to submission, reduced manual burden, improved compliance confidence 

Regulatory documentation remains one of the most resource-intensive phases of medical device development.  

• Risk classification automation: AI can analyze product attributes and applicable standards to suggest classification and required documentation. 
• Drafting and validation: Generative AI can produce up to 75% of required documentation, which is then refined and validated by human experts. 
• AI-assisted review: Post-editing, AI can re-analyze content to flag gaps or inconsistencies, acting as a second set of eyes before submission. 

AI won’t replace regulatory experts, but it will eliminate the grind. That’s where the value lies. 

For regulatory affairs leaders and product teams, this means faster submissions, reduced rework, and greater confidence in compliance, all while freeing up resources to focus on innovation. 

Agentic AI in the SDLC 

Outcome: Increased development velocity, reduced error rates, scalable automation 

Agentic AI—systems of multiple AI agents working in coordination—is emerging as a force multiplier in software development. 

• Task decomposition: Complex development tasks are broken into smaller units, each handled by specialized agents, reducing hallucinations and improving accuracy. 

• Peer review by AI: One agent can validate the output of another, creating a self-checking system that mirrors human code reviews. 

• Digital workforce augmentation: Repetitive, labor-intensive tasks (e.g., documentation scaffolding, test case generation) are offloaded to AI, freeing teams to focus on innovation. This is especially impactful for engineering and product teams looking to scale development without compromising quality or compliance. 

• Guardrails and oversight mechanisms: Our balanced implementation approach maintains security, compliance, and appropriate human supervision to deliver immediate operational gains and builds a foundation for continuous, iterative improvement. 

Agentic AI can surface vulnerabilities early and propose mitigations faster than traditional methods. This isn’t about replacing engineers. It’s about giving them a smarter co-pilot. 

AI-Enabled Quality Assurance and Testing 

Outcome: Higher product reliability, faster regression cycles, better user experiences 

AI is transforming QA from a bottleneck into a strategic advantage. 

• Smart regression testing: AI frameworks run automated test suites across releases, identifying regressions with minimal human input. 
• Synthetic test data generation: AI creates high-fidelity, privacy-safe test data in minutes—data that once took weeks to prepare. 
• GenAI-powered visual testing: AI evaluates UI consistency and accessibility, flagging issues that traditional automation often misses. 
• Chatbot validation: AI tools now test AI-powered support interfaces, ensuring they provide accurate, compliant responses. 

We’re not just testing functionality—we’re testing intelligence. That requires a new kind of QA.

Organizations managing complex software portfolios can unlock faster, safer releases. 

AI-Enabled, Scalable Talent Solutions 

Outcome: Scalable expertise without long onboarding cycles 

AI tools are only as effective as the teams that deploy them. We provide specialized talent—regulatory technologists, QA engineers, data scientists—that bring both domain knowledge and AI fluency. 

• Accelerate proof-of-concept execution: Our teams integrate quickly into existing workflows, leveraging Agile and SAFe methodologies to deliver iterative value and maintain velocity. 
• Reduce internal training burden: AI-fluent professionals bring immediate impact, minimizing ramp-up time and aligning with sprint-based development cycles. 
• Ensure compliance alignment from day one: Specialists understand regulated environments and embed quality and traceability into every phase of the SDLC, consistent with Agile governance models. 

Whether you’re a CIO scaling digital health initiatives or a VP of Software managing multiple product lines, our AI-fluent teams integrate seamlessly to accelerate delivery and reduce risk. 

Proof of Concept Today, Scalable Solution Tomorrow 

Outcome: Informed investment decisions, future-ready capabilities 

Many of the AI capabilities discussed are already in early deployment or active pilot phases. Others are in proof-of-concept, with clear paths to scale. 

We understand that every organization is on a unique AI journey. Whether you’re starting from scratch, experimenting with pilots, or scaling AI across your enterprise, we meet you where you are. Our structured approach delivers value at every stage, helping you turn AI from an idea into a business advantage. 

As you evaluate your innovation and investment priorities across the SDLC, consider these questions: 

1. Are we spending too much time on manual documentation?
2. Do we have visibility into risk classification and mitigation?
3. Can our QA processes scale with product complexity?
4. How are we building responsible AI governance?
5. Do we have the right partner to operationalize AI?

Final Thought: AI Demands a Partner, Not Just a Platform 

AI isn’t the new compliance partner. It’s the next competitive edge, but only when guided by the right strategy. For MedTech leaders, AI’s real opportunity comes by adopting and scaling it with precision, speed, and confidence. That kind of transformation can be accelerated by a partner who understands the regulatory terrain, the complexity of the SDLC, and the business outcomes that matter most. 

No matter where you sit — on the engineering team, in the lab, in business leadership, or in patient care — AI is reshaping how MedTech companies build, test, and deliver value. 

From insight to impact, our industry, platform, data, and AI expertise help organizations modernize systems, personalize engagement, and scale innovation. We deliver AI-powered transformation that drives engagement, efficiency, and loyalty throughout the lifecycle—from product development to commercial success. 

• Business Transformation: Deepen collaboration, integration, and support throughout the value chain, including channel sales, providers, and patients. 
• Modernization: Streamline legacy systems to drive greater connectivity, reduce duplication, and enhance employee and consumer experiences. 
• Data + Analytics: Harness real-time data to support business success and to impact health outcomes. 
• Consumer Experience: Support patient and consumer decision making, product usage, and outcomes through tailored digital experiences. 

Ready to move from AI potential to performance? Let’s talk about how we can accelerate your roadmap with the right talent, tools, and strategy. Contact us to get started. 

Building Advocacy into Team Culture

Welcome back! We’ve explored personas, KPIs, inclusive ceremonies, and more. But without sustained advocacy, even the best practices can fade. That’s where Accessibility Champions come in, quietly powering momentum, culture, and accountability.

These champions aren’t always official roles. Sometimes they’re developers who raise accessibility flags in standup, designers who rethink layout for contrast, or testers who ask, “How would this feel with a screen reader?”

 What Is an Accessibility Champion?

An Accessibility Champion is someone embedded within Agile teams who promotes inclusive thinking in:

• Sprint planning and backlog refinement
• Design reviews and story writing
• Testing conversations and acceptance criteria
• Team rituals and learning culture

They aren’t gatekeepers, they’re bridge-builders, helping others adopt accessible mindsets without friction or shame.

 Why Champions Drive Culture Change

Processes evolve, but culture sustains impact. Accessibility Champions help:

• Normalize inclusive conversations in daily workflows
• Spot exclusion early and proactively
• Educate peers on practical solutions and empathy-driven design
• Ensure accessibility isn’t forgotten under velocity pressure
• Build internal confidence about what “good” accessibility looks like

Their advocacy turns compliance into compassionate collaboration.

 How to Empower Champions on Agile Teams

1. Name the role Whether formal or informal, give people permission to lead. Include champion duties in team charters or retrospectives.

2. Provide tooling and learning Offer access to accessibility checklists, test tools (like axe or Pa11y), and WCAG guidelines. Host learning sessions or micro-trainings.

3. Invite cross-function collaboration Champions don’t work alone. Encourage designers, developers, product owners, and QA to partner in spotting and solving issues.

4. Recognize the work Advocacy often happens “in the margins.” Celebrate contributions in demos, ceremonies, or team communications.

 Champion Activities That Build Inclusive Momentum

Even small nudges, like flagging inaccessible link text, build systemic awareness.

Culture Is a Shared Sprint

Agile teams thrive on feedback, iteration, and collaboration. Accessibility Champions are the ones nudging those values toward equity, day after day.

If every team had one champion—just one person willing to ask: “Who might this leave out?” ,we’d unlock a wave of designs that include by default, not exception.

Next in the series: Designing Accessible Agile Artifacts We’ll explore how to make user stories, sprint boards, dashboards, and documentation accessible and inclusive.

Agile ceremonies are meant to foster collaboration, transparency, and alignment. But when voices go unheard or participation feels risky, those goals fall short.

Inclusive Agile ceremonies remove barriers and elevate contribution, from every team member.

The Participation Problem

Common ceremony hurdles:

• Meetings dominated by a few loud voices
• Barriers to participation (sensory, cognitive, social)
• Lack of accommodations or varied formats
• Biases about who “should” speak or lead

Accessibility reframes these as solvable design challenges.

 Ceremony-by-Ceremony Breakdown

Let’s explore key ceremonies and inclusive tactics:

1. Daily Standups

These are quick, so make them equitable:

• Rotate facilitators to diversify leadership
• Allow responses via chat, cards, or asynchronous tools
• Use timers to prevent monologues
• Include remote and neurodivergent-friendly cues

Inclusive Prompt: “What’s one blocker, technical or environmental, you’re facing today?”

2. Sprint Planning

Where priorities are set, inclusion must begin:

• Provide agenda and backlog in accessible formats ahead of time
• Use plain language for story descriptions
• Define accessibility work as priority—not technical debt
• Invite input from roles that often get sidelined (QA, documentation, support)

Tip: Use inclusive personas from earlier episodes to frame story acceptance criteria.

3. Retrospectives

Time to reflect, and learn:

• Offer multiple participation modes: post-it boards, anonymous forms, live discussions
• Frame feedback as systems-oriented, not personal
• Ask equity-driven questions like: “Did any barriers surface this sprint that we didn’t anticipate?” “How might we support quieter voices?”

Tool: Try Liberating Structures or Miro boards with accessible navigation.

 Practical Facilitation Tips

• Prep Materials Accessibly: Use alt text, high-contrast slides, readable fonts
• Neurodiversity Aware: Avoid overload; give breaks; use structure
• Multiple Expression Modes: Voice, chat, docs, emoji check-ins
• Consent Culture: Let people opt in/out of sharing
• Asynchronous Options: Not everyone thrives in real-time

Inclusion Is a Ritual

Agile ceremonies aren’t just meetings, they’re cultural signals. They tell your team whose voices matter. When inclusion becomes ritualized, trust grows—and so does innovation.

Ask your team this week: How might our ceremonies better reflect the needs of everyone, not just the norms we inherited?

Next up in the series: Agile Accessibility Champions: Building Advocacy into Team Culture We’ll explore how roles like Accessibility Advocates or Champions can shape Agile momentum and culture.

Welcome back! So far, we’ve explored inclusive personas, accessible testing, story writing, and the core principles that connect Agile to accessibility. Now we ask: How do we measure what matters, not just what’s easy?

Why Accessibility KPIs Belong in Agile

Agile teams measure velocity, sprint goals, and user satisfaction. But accessibility? It’s often buried under “nice to have” or “technical debt.”

Making accessibility a Key Performance Indicator (KPI):

• Elevates inclusion to a priority, not a checkbox
• Aligns product development with organizational values
• Surfaces real user impact, not just regulatory compliance
• Encourages continuous improvement through data-driven reflection

 Types of Accessibility KPIs for Agile Teams

Here are five categories of KPIs teams can track:

1. Usability Feedback from Diverse Users

Track the number of testing sessions including users with disabilities or varied contexts KPI: % of usability tests conducted with diverse participants

2. Backlog & Story Inclusion

Are accessibility-related stories part of your backlog from the start? KPI: % of stories that include accessibility acceptance criteria

3. Defect Tracking

Accessibility bugs often go unnoticed. Start tracking them like any other issue. KPI: # of accessibility defects vs. resolved per sprint

4. Automation & Coverage

Automated tools aren’t perfect, but they help you catch what you might miss. KPI: % of pages/components passing automated accessibility scans

5. Team Learning & Growth

If teams aren’t learning, they’re repeating old patterns. KPI: # of team trainings, audits, or accessibility retrospectives per quarter

How to Integrate Accessibility KPIs into Agile Workflows

Let’s make it practical:

• Sprint Planning: Include KPIs as part of definition of done
• Daily Standups: Surface blockers related to accessibility criteria
• Testing: Use inclusive personas and assistive tech scenarios
• Sprint Reviews: Report on accessibility metrics alongside velocity
• Retrospectives: Reflect on what improved, what stalled, and who was impacted

Metrics with Meaning

Tracking accessibility isn’t just about compliance, it’s about accountability to real users. KPIs empower teams to shift from good intentions to great outcomes.

So ask your team: Are we measuring accessibility with the same rigor we measure delivery, and if not, what’s holding us back?

Next up in the series: Facilitating Inclusive Agile Ceremonies We’ll explore how daily standups, sprint planning, and retrospectives can invite more voices and reduce participation barriers.

Welcome back to our ongoing series that explores how Agile practices and Accessibility principles converge to create products and systems that serve everyone. So far, we’ve explored foundational definitions, inclusive story writing, and accessibility testing in CI.

Today’s focus? A tool Agile teams often rely on, but rarely challenge: personas.

What Are Personas in Agile?

In Agile and user-centered design, personas are fictional but research-informed representations of your users. They help teams visualize needs, constraints, and goals in a relatable way.

Typical personas might include:

• A tech-savvy millennial using mobile apps
• A small business owner tracking inventory
• A busy parent shopping on-the-go

These personas help humanize development priorities, but they often miss access needs, systemic barriers, and overlooked perspectives.

Why Inclusive Personas Matter

When personas don’t reflect users with disabilities, teams risk designing products that exclude by default.

Inclusive personas go beyond demographics:

• They reflect differences in how users interact with products
• They highlight barriers caused by design choices
• They promote empathy, not just efficiency
• They elevate equity as a design outcome

Instead of assuming typical use, inclusive personas ask: “What if this user interacts differently?”

How to Create Inclusive Personas

Here’s a framework Agile teams can follow:

1. Include Diverse Abilities

Go beyond visual or auditory disabilities, include cognitive, motor, and situational constraints.

Example: Anna, 27, graphic designer with ADHD Needs: Clear navigation, focus-friendly interface, consistent structure

Example: Jenny, 52, warehouse manager who lost vision Needs: Screen reader compatibility, alt-text on images, keyboard navigation

2. Contextualize Use Cases

Design personas based on scenarios users encounter:

• Noisy environments (caption reliance)
• Glare on screens outdoors (contrast needs)
• Time-sensitive actions (simplified flows)
• High emotion moments (clear feedback)

3. Co-create with Real Users

Whenever possible, build personas with input from individuals with lived experience. This avoids tokenism and strengthens usability insights.

Invite feedback, use interviews, leverage advocacy networks.

4. Integrate Personas into Agile Rituals

• Use inclusive personas during backlog refinement
• Reference them in story writing and testing scenarios
• Include accessibility criteria that reflect persona needs
• Track which personas are supported, and which are underserved

Persona-Driven Empathy Leads to Equitable Design

Personas aren’t just planning tools, they’re storytelling tools. And stories shape outcomes.

Inclusive personas invite teams to imagine beyond default users. They help you design features that remove friction and empower everyone, not just the majority.

So ask your team today: Whose story are we not telling yet, and how can we make space for it?

Next up in the series: Measuring Accessibility as a Team KPI We’ll discuss how Agile teams can hold themselves accountable using metrics that track impact, not just compliance.

See you in the next episode Want help building inclusive persona templates or workshop kits? I’d be glad to create some!

Welcome back to our series exploring the fusion of Agile principles and Accessibility practices to create products that serve everyone.

In the last post, we talked about writing inclusive user stories and acceptance criteria, how the right narratives shape more equitable outcomes. Today, we move from writing stories to testing them at scale, exploring how Accessibility Testing in Continuous Integration (CI) ensures inclusion is not just promised but delivered.

What Is Continuous Integration?

Continuous Integration is a key practice in Agile and DevOps workflows. It involves:

• Frequently merging code changes into a shared repository
• Automatically running tests with every new commit
• Detecting issues early, before they reach production

CI helps teams move fast and deploy confidently. But if accessibility isn’t part of this process, exclusion can be deployed just as quickly.

 Why Include Accessibility in CI?

Accessibility testing is often misunderstood as slow, manual, or post-launch work. But with the right tools and mindset, it becomes a speed-friendly quality layer in your pipeline.

Benefits of accessibility testing in CI:

• Catch common issues before they multiply (e.g., missing alt text, low contrast)
• Reduce cost by identifying barriers early
• Build accountability across developers and testers
• Foster inclusive culture as part of “done,” not “extra”

In short: shift left. Test accessibility early, often, and automatically.

Tools for Automated Accessibility Testing

While no tool replaces human judgment, these are powerful CI allies:

Run tests during each pull request or merge to stop accessibility regressions in their tracks.

Manual Testing Still Matters

Automated tools catch technical failures, but manual testing catches experiential ones.

Include these practices in CI-adjacent workflows:

• Screen reader navigation checks (e.g., NVDA, VoiceOver)
• Keyboard-only interactions
• Cognitive usability tests (plain language, clear flows)
• Mobile contrast and tap-target validation

Combine automation and human insights for true coverage.

Best Practices for Integrating Accessibility into CI

• Set accessibility goals as KPIs—track how many violations are fixed per sprint
• Treat accessibility errors like any other bug—log them, track them, and fix them
• Involve QA testers and designers—build shared responsibility
• Include accessibility in your Definition of Done—and review it regularly
• Use CI dashboards to visualize accessibility performance over time

Accessibility testing in CI isn’t about slowing down, it’s about building better faster. It ensures that your team’s intentions around inclusion translate into reality at the code level.

By embedding accessibility tools, practices, and KPIs into your development pipeline, you turn CI into a driver of universal usability, not just technical health.

Next in the series, Creating Inclusive Personas for Agile Teams We’ll explore how to build empathy through user representation—and how personas can shape more inclusive designs from sprint zero.

See you in the next episode Want help setting up an accessibility testing checklist or CI dashboard template next? I’ve got plenty we can tailor for your workflow.

Welcome back to our session on Agile and Accessibility, where we bring together two powerful forces in inclusive product development. This marks the beginning of a brand-new series. The Intersection of Agile and Accessibility is dedicated to exploring how teams can design, build, and deliver digital experiences that truly work for everyone.

Whether you’re a seasoned designer, a curious developer, or an advocate for social impact, this series will help you apply inclusive design principles through Agile practices—starting with the foundation: inclusive user stories and acceptance criteria.

 What Is Agile?

Agile is a product development methodology built on collaboration, speed, and flexibility. Originally created for software teams, it’s now embraced across industries.

Key principles of Agile include:

• Iterative development in short cycles (sprints)
• Regular feedback and team collaboration
• User-centered outcomes over rigid processes
• Embracing change to meet real-world needs

Agile helps teams move fast, but it also helps them build right when grounded in meaningful user stories.

 What Is Accessibility?

Accessibility means designing products and environments that are usable by everyone, including people with disabilities.

More than just a legal requirement, accessibility is a universal benefit, it improves usability, clarity, and engagement for all users.

Core goals of accessibility:

• Remove barriers to participation
• Enhance usability for diverse needs and contexts
• Integrate inclusive design from the start—not as an afterthought
• Support human diversity in ability, language, cognition, and interaction

Accessibility is not charity. It’s equity in action.

Why Agile and Accessibility Belong Together

The relationship between Agile and Accessibility is both practical and transformative. When Agile teams embed inclusive thinking from the start, they reduce the need for expensive retrofits, avoid biased assumptions, and create products with universal impact.

Together, Agile and Accessibility:

• Prioritize real user needs, including diverse abilities
• Catch barriers early through feedback and iteration
• Foster empathy across cross-functional teams
• Shift mindset from “minimum compliance” to maximum inclusion

And it all starts with how we write our user stories.

 Writing Inclusive User Stories

The classic Agile user story format is:

As a [user role], I want to [action] so that I can [goal].

But without inclusive language and context, stories may unintentionally assume able-bodied or neurotypical users. To create truly inclusive solutions, our stories must reflect diverse user perspectives.

Tips for writing inclusive stories:

• Use role descriptions like “screen reader user,” “user with low vision,” or “user with cognitive disabilities”
• Avoid assumptions about sensory, motor, or cognitive capabilities
• Incorporate environmental factors (e.g., noisy settings, limited bandwidth)
• Consult accessibility personas to guide user empathy

As a user who relies on keyboard navigation, I want to access the site’s main navigation using the Tab key so that I can browse efficiently without a mouse.

 Creating Inclusive Acceptance Criteria

Acceptance criteria define when a story is considered “done.” That’s your opportunity to enforce accessibility.

Inclusive acceptance criteria should:

• Reference WCAG 2.2 AA standards
• Include accessibility testing across assistive technologies
• Require keyboard access, proper semantic HTML, and screen reader compatibility
• Use real-world tasks that represent diverse user needs

• Focus is visible and moves logically via Tab key
• Navigation landmarks are announced via screen reader
• No component requires hover to access critical functionality

These criteria ensure that accessibility is baked into functionality, not bolted on as a post-check.

Inclusive user stories and acceptance criteria are not extras, they’re essential Agile practices that reflect the real-world diversity of human experience. They’re how we build equity into everyday development.

In this series, we’ll explore:

• Designing accessible components from the start
• Conducting inclusive user research and testing
• Integrating accessibility in sprint planning and retrospectives
• Turning accessibility from a checkbox into a culture

Stay tuned for next Episode and until then, ask yourself: Who are we designing for, and who might we be missing?

Let’s make Agile work for everyone.

As a Drupal developer with over four years of experience, I’ve worked on numerous projects where accessibility was a priority. Ensuring websites are accessible to people with disabilities is not only a best practice but also often a legal requirement. The Web Content Accessibility Guidelines (WCAG) provide a framework for achieving this, and tools like UserWay can streamline the process. In this post, I’ll explain WCAG compliance in clear terms, its importance for Drupal sites, and how UserWay can assist, based on my professional experience.

Understanding WCAG

WCAG, or Web Content Accessibility Guidelines, is a set of standards designed to make websites accessible to individuals with disabilities, including those with visual or motor impairments. Most organizations target WCAG 2.1 Level AA, which strikes a balance between practicality and meaningful accessibility improvements. Compliance ensures that users can navigate and interact with your site using tools such as screen readers or keyboards.

WCAG compliance is essential for legal compliance, such as adhering to the Americans with Disabilities Act (ADA) in the US or European accessibility regulations. In my work, I’ve seen clients prioritize WCAG to avoid legal risks, especially for public-facing sites like those for nonprofits or government organizations.

Core Principles of WCAG

WCAG is built on four principles, often referred to as POUR:

• Perceivable: Content must be accessible through sight or sound. For example, images need text descriptions for screen readers, and text must have sufficient contrast.
• Operable: Users should be able to navigate the site using a keyboard or other assistive devices, not just a mouse.
• Understandable: The site’s interface and content should be clear, with intuitive navigation and straightforward error messages.
• Robust: The site must function across various assistive technologies and devices, including older browsers.

These principles guide all accessibility efforts on Drupal projects.

Importance of WCAG for Drupal Sites

Drupal is a powerful platform for building flexible websites, but accessibility requires deliberate effort. WCAG compliance offers several benefits:

• Inclusivity: Ensures all users, regardless of ability, can access your content.
• Legal Protection: Reduces the risk of lawsuits, a concern I’ve encountered with clients in regulated industries.
• SEO Benefits: Accessible sites often rank better in search engines due to cleaner structure and content.
• Future-Readiness: Compliant sites are more compatible with emerging technologies.

In one project, a client’s Drupal site had an event calendar that was visually appealing but inaccessible to screen readers. Addressing WCAG requirements improved usability for all users, not just those with disabilities.

Practical Steps for WCAG Compliance

Here are the key steps I follow to achieve WCAG compliance on Drupal sites:

• Image Descriptions: Add alt text to images to describe them for screen readers. Drupal’s CKEditor prompts editors to include alt text during image uploads.
• Color Contrast: Ensure text is readable against its background. I use tools like WebAIM’s Contrast Checker to verify a 4.5:1 contrast ratio, as required by WCAG.
• Keyboard Navigation: Test the site using the Tab key to confirm that all links, buttons, and forms are accessible without the use of a mouse. Drupal’s Olivero theme supports this well.
• Clear Form Labels: Ensure every form field has a descriptive label, such as “Email Address.” Drupal’s Form API handles this effectively, but custom forms need review.
• Accessibility Testing: Use tools like WAVE or Lighthouse to identify issues, such as missing labels or low contrast, before launching the site.

These steps address WCAG’s core principles and are manageable within most Drupal workflows.

Using UserWay to Support Compliance

UserWay is a tool I use to simplify WCAG compliance. It’s a JavaScript widget that enhances accessibility by adjusting contrast, enabling screen reader support, and allowing users to increase text size. To integrate UserWay, I sign up at userway.org, obtain the provided JavaScript code, and add it to the Drupal theme’s settings (Appearance > Settings > Your Theme > Custom JavaScript). The process takes about 15 minutes, and the widget immediately improves accessibility.

UserWay also includes a scanning tool that identifies WCAG-related issues, such as missing alt text, and provides a report for manual fixes. In a recent project, UserWay’s scanner helped us address accessibility gaps on a content-heavy site, saving significant development time. Pricing starts at approximately $49/month per site, which is reasonable for many projects.

Considerations

While UserWay automates many accessibility features, it’s not a complete solution. Manual tasks, like writing accurate alt text or testing custom functionality, are still necessary. Additionally, the cost may add up for developers managing multiple sites. In my experience, combining UserWay with manual checks ensures robust compliance with WCAG.

Conclusion

Achieving WCAG compliance on Drupal sites is crucial for ensuring inclusivity, meeting legal requirements, and enhancing user experience. By following straightforward steps, including adding alt text, ensuring keyboard navigation, and thoroughly testing, you can effectively meet WCAG standards. UserWay supports this process by automating key adjustments and providing actionable insights. Based on my work, these efforts create better, more accessible Drupal sites.

Welcome to the first entry in our new series exploring the synergy between Agile methodologies and Accessibility practices, and how their union can lead to more inclusive, equitable, and universally usable outcomes.

In today’s post, we’ll lay the groundwork by asking: What are Agile and Accessibility? And more importantly, why does their intersection matter?

What Is Agile?

Agile is a development philosophy centered on flexibility, collaboration, and continuous improvement. Originally crafted for software development, its principles now guide diverse industries seeking to respond quickly to change and deliver value incrementally.

Key features of Agile:

• Iterative work cycles (called sprints)
• Cross-functional teamwork
• Regular stakeholder feedback
• Focus on delivering functional solutions early and often

Agile thrives on solving real problems in real time. And when those problems include barriers to access, it’s the perfect vehicle for progress.

 What Is Accessibility?

Accessibility is about creating environments, products, and services usable by everyone, regardless of their abilities or disabilities. It recognizes human diversity in how we interact with the world, through vision, hearing, mobility, cognition, and more.

Core principles of accessibility:

• Removing barriers to participation
• Designing for a spectrum of needs
• Following established guidelines (like WCAG and Section 508)
• Prioritizing inclusive usability over minimum compliance

When accessibility is built into the foundation, not retrofitted later, it benefits all users, not just those with disabilities.

Where Agile Meets Accessibility-  The Power of Inclusion at Speed

Agile development is often seen as “move fast and build things.” But when accessibility joins the conversation, it becomes “move thoughtfully and build for everyone.”

Here’s why their connection is transformative:

• Empathy-driven design: Agile encourages constant user feedback. When that feedback includes people with disabilities, design becomes naturally more inclusive.
• Fail fast, learn fast: Accessibility mistakes are caught early in iterative sprints, reducing cost, time, and user frustration.
• Shared responsibility: Agile’s team-based approach distributes accessibility ownership across roles, breaking silos and boosting accountability.
• Inclusive user stories: When product requirements include accessible personas, teams build with a broader perspective from day one.

What’s Next in the Series?

This series will explore the practical intersections between Agile and Accessibility. Upcoming posts include:

• Writing Inclusive User Stories and Acceptance Criteria
• Accessibility Testing in Continuous Integration
• Creating Inclusive Personas for Agile Teams
• Measuring Accessibility as a Team KPI

Each entry will offer actionable insights grounded in Universal Design principles—because building for inclusion should be fast, flexible, and foundational.

Agile and Accessibility aren’t just compatible, they’re complementary forces in creating inclusive, future-ready design. Whether you’re building software, services, or systems, integrating accessibility from sprint one transforms Agile from a framework into a tool for equity.

This series will continue to explore how teams can align their workflows with Universal Design principles, champion accessibility as a KPI, and craft user stories that reflect diverse experiences and needs.

Thank you for reading, and see you on the next episode, where we’ll dive into Writing Inclusive User Stories and Acceptance Criteria and show how small narrative shifts can lead to big usability wins.