When building modern SharePoint Framework (SPFx) solutions, reusable UI components play a crucial role in keeping your code clean, scalable, and maintainable. In particular, interactive components help improve the user experience without cluttering the interface.

import * as React from 'react';
import styles from './Accordion.module.scss';
import classNames from 'classnames';
import { IAccordionItemProps } from './subcomponents/AccordionItem';

import { ReactElement } from 'react';

export interface IAccordionProps {
  children?:
    | ReactElement<IAccordionItemProps>
    | ReactElement<IAccordionItemProps>[];
  className?: string;
}


const Accordion: React.FunctionComponent<
  React.PropsWithChildren<IAccordionProps>
> = (props) => {
  const { children, className } = props;
  return (
    <div className={classNames(styles.accordionSubcomponent, className)}>
      {children}
    </div>
  );
};

export default Accordion;

.accordionSubcomponent {
    margin-bottom: 12px;
    .accordionTitleRow {
        display: flex;
        flex-direction: row;
        align-items: center;
        padding: 5px;
        font-size: 18px;
        font-weight: 600;
        cursor: pointer;
        -webkit-touch-callout: none;
        -webkit-user-select: none;
        -khtml-user-select: none;
        -moz-user-select: none;
        -ms-user-select: none;
        user-select: none;
        border-bottom: 1px solid;
        border-color: "[theme: neutralQuaternaryAlt]";
        background: "[theme: neutralLighter]";
    }
    .accordionTitleRow:hover {
        opacity: .8;
    }
    .accordionIconCol {
        padding: 0px 5px;
    }
    .accordionHeaderCol {
        display: inline-block;
        width: 100%;
    }
    .iconExpandCollapse {
        margin-top: -4px;
        font-weight: 600;
        vertical-align: middle;
    }
    .accordionContent {
        margin-left: 12px;
        display: grid;
        grid-template-rows: 0fr;
        overflow: hidden;
        transition: grid-template-rows 200ms;
        &.expanded {
          grid-template-rows: 1fr;
        }
        .expandableContent {
          min-height: 0;
        }
    }
}

import * as React from 'react';
import styles from '../Accordion.module.scss';
import classNames from 'classnames';
import { Icon } from '@fluentui/react';
import { useState } from 'react';


export interface IAccordionItemProps {
  iconCollapsed?: string;
  iconExpanded?: string;
  headerText?: string;
  headerClassName?: string;
  bodyClassName?: string;
  isExpandedByDefault?: boolean;
}
const AccordionItem: React.FunctionComponent<React.PropsWithChildren<IAccordionItemProps>> = (props: React.PropsWithChildren<IAccordionItemProps>) => {
  const {
    iconCollapsed,
    iconExpanded,
    headerText,
    headerClassName,
    bodyClassName,
    isExpandedByDefault,
    children
  } = props;
  const [isExpanded, setIsExpanded] = useState<boolean>(!!isExpandedByDefault);
  const _toggleAccordion = (): void => {
    setIsExpanded((prevIsExpanded) => !prevIsExpanded);
  }
  return (
    <Stack>
    <div className={styles.accordionTitleRow} onClick={_toggleAccordion}>
        <div className={styles.accordionIconCol}>
            <Icon
                iconName={isExpanded ? iconExpanded : iconCollapsed}
                className={styles.iconExpandCollapse}
            />
        </div>
        <div className={classNames(styles.accordionHeaderCol, headerClassName)}>
            {headerText}
        </div>
    </div>
    <div className={classNames(styles.accordionContent, bodyClassName, {[styles.expanded]: isExpanded})}>
      <div className={styles.expandableContent}>
        {children}
      </div>
    </div>
    </Stack>
  )
}
AccordionItem.defaultProps = {
  iconExpanded: 'ChevronDown',
  iconCollapsed: 'ChevronUp'
};
export default AccordionItem;

<Accordion>
  <AccordionItem headerText="What is SPFx?">
    <p>SPFx is a development model for SharePoint customizations.</p>

  </AccordionItem>

  <AccordionItem
    headerText="Why use custom controls?"
    isExpandedByDefault={true}
  >
    <p>Custom controls improve reusability and UI consistency.</p>
  </AccordionItem>
</Accordion>

Introduction

The modernization of legacy applications has always been a costly process: understanding old code, uncovering hidden dependencies, translating communication models (for example, from SOAP to REST), and ensuring that nothing breaks in production. This is where artificial intelligence changes the game.

AI does not replace the architect or the developer, but it speeds up the heaviest steps in a migration: it helps read and summarize large codebases, proposes equivalent designs in the new technology, generates drafts of controllers, DTOs, and tests, and even suggests architectural improvements that take advantage of the change. Instead of spending hours on mechanical tasks, the team can focus on what really matters: the business rules and the quality of the new solution.

In this post, we’ll look at that impact applied to a concrete case: migrating a WCF service written in C# to an ASP.NET Core Web API, using a real public repository as a starting point and relying on AI throughout the entire process.

Sample project: a real WCF service to be migrated

For this article, we’ll use the public project jecamayo/t-facturo.net as a real-world example: a .NET application that exposes SOAP services based on WCF to manage advisors and branches, using NHibernate for data access. This kind of solution perfectly represents the scenario of many legacy applications currently running in production, and it will serve as our basis to show how artificial intelligence can speed up and improve their migration to a modern architecture with ASP.NET Core Web API.

Key Steps to Migrate from Legacy WCF to a Modern Web API

Migrating a legacy application is not just about “moving code” from one technology to another: it involves understanding the business context, the existing architecture, and designing a modern solution that will be sustainable over time. To structure that process—and to clearly show where artificial intelligence brings the most value—it’s useful to break the migration down into a few key steps like the ones we’ll look at next.

1. Define the goals and scope of the migration
   Clarify what you want to achieve with the modernization (for example, moving to .NET 8, exposing REST, improving performance or security) and which parts of the system are in or out of the project, in order to avoid surprises and rework.
2. Analyze the current architecture and design the target architecture
   Understand how the solution is built today (layers, projects, WCF, NHibernate, database) and, with that snapshot, define the target architecture in ASP.NET Core Web API (layers, patterns, technologies) that will replace the legacy system.
3. Identify dependencies, models, DTOs, and business rules
   Locate external libraries, frameworks, and critical components; inventory domain entities and DTOs; and extract the business rules present in the code to ensure they are properly preserved in the new implementation.
4. Design the testing strategy and migration plan
   Decide how you will verify that the new API behaves the same (unit tests, integration tests, comparison of WCF vs Web API responses) and define whether the migration will be gradual or a “big bang”, including phases and milestones.
5. Implement the new Web API, validate it, and retire the legacy WCF
   Build the Web API following the target architecture, migrate the logic and data access, run the test plan to validate behavior, deploy the new solution and, once its stability has been confirmed, deactivate the inherited WCF service.

How to Use AI Prompts During a Migration

The adoption of microservice‑based architectures has grown exponentially over the past decade, often driven more by industry trends than by a careful evaluation of system requirements. This phenomenon has generated unnecessarily complex implementations—like using a bazooka to kill an ant. Distributed architectures without solid foundations in domain capabilities, workloads, operational independence, or real scalability needs have become a common pattern in the software industry. In many cases, organizations migrate without having a mature discipline in observability, traceability, automation, domain‑driven design, or an operational model capable of supporting highly distributed systems; as a consequence, they end up with distributed monoliths that require coordinated deployments and suffer cascading failures, losing the benefits originally promised by microservices (Iyer, 2025; Fröller, 2025).

Tailwind CSS has revolutionized modern front-end development by offering a utility-first approach. It’s fast, flexible, and makes styling a breeze. But if you’ve ever seen some of your classes disappear after production builds, especially when they’re dynamically generated, then you’re not alone. That’s where Tailwind’s safelist feature comes in!

In this post, we’ll break down what the Safelist is, why it’s important, and how to use it correctly with real-world examples.

Why Do My Tailwind Classes Disappear?

Tailwind CSS uses a feature called “PurgeCSS” (now called Content Scanning) to remove unused CSS during the production build. This drastically reduces your CSS file size. However, any class names not explicitly written in your code (e.g., those generated at runtime or passed from APIs) will be purged, gone from the final stylesheet.

For Example

<!-- This will stay -->
<div class="text-red-500">Hello</div>
<!-- This might get purged -->
<div class={`text-${color}-500`}>Hi</div>

Since text-${color}-500 is dynamically created, Tailwind doesn’t “see” it during build time, so it assumes it’s unused and removes it.

What is the Tailwind Safelist?

The Safelist (formerly purge. Safelist) is a way to manually tell Tailwind CSS to always include specific classes, even if it doesn’t find them in your files.

It ensures your dynamic classes or edge cases are not purged from the final CSS output.

How to Use Safelist in tailwind.config.js

Simple Array Format

// tailwind.config.js
module.exports = {
  content: ['./src/**/*.{html,js}'],
  safelist: ['text-red-500', 'bg-blue-200', 'hover:underline']
};

Tailwind will always include these classes, even if they don’t appear in your source code.

Pattern-Based Safelisting with Regex

For dynamic utilities (e.g., text-red-100 to text-red-900), use patterns:

module.exports = {
  safelist: [
    {
      pattern: /text-(red|blue|green)-(100|200|300|400|500)/,
    },
    {
      pattern: /bg-(gray|yellow)-(50|100|200|300)/,
      variants: ['hover', 'focus'],
    },
  ]
};

This tells Tailwind to include all matching combinations like text-red-100, bg-yellow-200:hover, etc.

Real-World Use Cases

Dynamic Theme Switcher

In any jsx file:

<div className={`bg-${theme}-500 text-white`}>
  Welcome!
</div>

Classes like bg-blue-500, bg-green-500, etc., won’t be detected at build time.

In the tailwind config file, add:

safelist: [
  {
    pattern: /bg-(blue|green|red)-(500)/,
  }
]

Button Variants from CMS or API

If buttons come from a CMS:

In JSON:

{ "btnColor": "yellow", "textColor": "gray" }

Your component HTML:

<button class={`bg-${btnColor}-400 text-${textColor}-900`}>Click Me</button>

Tailwind won’t see these classes. Safelist them like:

safelist: [
  {
    pattern: /bg-(yellow|blue|green)-400/,
  },
  {
    pattern: /text-(gray|black|white)-900/,
  }
]

Dark Mode Variants

In HTML:

<div class="dark:bg-gray-800 dark:text-white">Night Mode</div>

In config.js:

safelist: [
  'dark:bg-gray-800',
  'dark:text-white'
]

Advanced Tips

• You can use variants with patterns to include states like hover, focus, sm, md, etc.
• Combine multiple patterns for color, size, and responsiveness.

In config.js:

{
  pattern: /(bg|text)-(red|blue|green)-(100|200|300)/,
  variants: ['sm', 'md', 'hover']
}

Clean Code Strategy: When to Safelist vs Refactor

Use Safelist when

• You can’t avoid dynamic class generation (e.g., from CMS, user settings)
• Classes are predictable

Avoid Safelist if

• You can rewrite the logic to use static class names
• You can use conditional class tools like clsx, classnames, or Tailwind’s own recommended patterns

Common Mistakes

• Correct: Safelist: [‘text-red-500’]
• Wrong: Safelist: ‘text-red-500’ (must be an array)
• Expecting dynamic regex to catch invalid formats like text-${color} if color is from unknown sources

Tailwind : Final Best Practices

Useful Tools

• Tailwind Play – Test safelisting live
• PurgeCSS Analyzer – See what gets purged
• NODE_ENV=production npx tailwindcss -o build.css – Test your build locally

Conclusion

The Tailwind CSS safelist is a powerful tool that ensures your dynamic class names survive the purge process. Whether you’re building a theme engine, integrating CMS content, or just using creative component logic, Safelist saves you from frustrating styling bugs in production.

By mastering safelisting, you gain better control over your final CSS bundle while still enjoying the dynamic flexibility Tailwind offers.

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!

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.