Longer-form thinking on accessibility leadership, project execution, communication, and treating accessibility as a core requirement.
The same piece featured on the home page: accessibility as a non-functional requirement, and what that does to your planning, risk framing, and trust with customers.
~8–10 min read · Planning · Risk · Trust
Jump to full article ↓A short video on why your vision and mission are the true beginning of the most important company—You. I talk about treating yourself with the same clarity and discipline you would bring to any serious business.
Watch on LinkedIn ↗Before you jump into that next thing, take a moment to plan and think through what is going to happen. Sometimes it is better to slow down before you speed up.
Each week, I share one short idea like this that comes directly from real programs, not textbooks. Think of these as conversation starters for your own teams.
Every long-form insight is written with four kinds of learners in mind. You’ll see callouts in each article that map directly to these styles.
Get structure and context.
Get explanation and narrative.
Get interaction and practice.
Get examples and demonstration.
How smaller organizations can take meaningful steps toward accessibility without enterprise budgets or dedicated teams.
The behaviors leaders model, reinforce, and protect when they want accessibility to become real culture.
How AI supports accessibility—and the moments where real human judgment still has to lead.
When accessibility moves from “nice to have” to “non-functional requirement,” everything changes: how you plan, how you manage risk, and how customers experience the product.
Starting something new is always daunting—especially when you’re building a discipline like accessibility. The first challenge isn’t the work itself; it’s understanding how accessibility fits into the processes your organization already relies on.
My approach is simple: look for structures your teams already understand. In IT, that’s non-functional requirements (NFRs).
NFRs describe how a system must behave and the qualities it must demonstrate. They’re often the “-itties”: Security, Stability, Scalability, Manageability, Maintainability, Serviceability, Recoverability, Capacity, Availability, Reliability, Data Integrity, and Usability.
When these qualities are healthy, customers don’t notice. When they fail, everything is visible: security breaches, outages, systems collapsing under load. Those are failures of planning, risk management, and trust.
Accessibility belongs in this same category of core quality attributes.
Accessibility isn’t an undefined or abstract expectation. The Web Content Accessibility Guidelines (WCAG) provide a ready-made requirement set for websites, native mobile apps, and other digital experiences.
WCAG is intentionally technology-agnostic. It defines what must be true for accessibility, not how you must implement it. That lets organizations meet requirements using the tools and platforms they already use.
Automated tools can typically validate 50–60% of WCAG criteria. Trained testers or guided tools cover the remaining human-verified checks. Put together, you get accessibility that is:
Those are exactly the qualities you want in your planning and risk conversations.
Modern frameworks already tell us where NFRs belong. Dean Leffingwell (SAFe) and Mike Cohn (Scrum) both describe NFRs as constraints across every backlog.
To integrate accessibility, teams can:
When accessibility is present from the beginning, it stops being a late-stage compliance check and becomes a core part of product planning. That reduces rework, lowers risk, and improves trust across releases.
Once accessibility is established as a quality attribute, there’s a second evolution: treating it as a Customer Experience Requirement.
We’ve already seen this in practice:
Many innovations were originally designed for people with disabilities, then became beloved by everyone. Accessibility improvements almost always improve overall user experience.
Biometric login is a good example. It started as a security and accessibility requirement and evolved into everyday convenience. Your password became your face—something you always have with you.
Treating accessibility as a core requirement shapes planning, reduces risk, and builds lasting customer trust. Treating it as a CX requirement turns that trust into a competitive advantage.
How this insight supports different learners
R Readers
Clear structure: NFRs → WCAG → agile practices → CX requirement.
L Listeners
Narrative arc from “new discipline” anxiety to confident planning.
D Doers
Concrete next steps: definitions of done, story criteria, and backlog constraints.
O Observers
Real-world examples: Amazon, Apple, and biometric login as visible outcomes.
How a training mindset—and a simple cycle of Teach → Try → Show → Revise— makes communication clearer, repeatable, and more effective.
I’m a continuous learner. I believe that if you’re not learning, you’re stagnating—and that belief has shaped every stage of my career.
I started at State Farm in the systems department right out of college. My first job was loading tapes on second shift for data processing. From there I moved through multiple roles, eventually stepping into project leadership. After years of leading initiatives inside one organization, I left State Farm to see how other companies approached projects, communication, and change.
That journey led me to Deque. Working with a wide range of organizations gave me something I couldn’t see from the inside: communication succeeds or fails based on how well people understand what they’re being asked to do.
Moving into Deque’s training team taught me a critical lesson: training isn’t about presenting; it’s about instructional design.
Instructional design techniques do something project communication often doesn’t—they make the message clear, repeatable, and effective. They recognize that people learn differently. Some absorb information by reading. Others by listening. Others by doing. Others by watching.
Most project communication fails for a simple reason: we communicate the way we prefer—not the way others understand.
Instructional designers think differently. They never assume information alone creates clarity. They design communication so it’s absorbed, remembered, and applied.
When project leaders borrow these principles, communication stops being a stream of words and becomes a learning experience—one that people actually act on.
At the heart of this approach is a simple, effective cycle:
Teaching is about grounding people in the “what” and the “why.” This is where readers and listeners get what they need.
You answer questions like:
This establishes a shared baseline and eliminates early confusion. It’s where readers get structure and context, and listeners get explanation and narrative.
Understanding deepens when people can interact with information. This is where doers come alive.
In project communication, “Try” can look like:
Trying turns communication into collaboration. People don’t just hear the message—they use it, and in the process, they help you refine it.
Some people learn best by watching. For observers, seeing is understanding.
“Show” might be:
Showing removes guesswork. It turns abstract ideas into something teams can point to and say: “That’s what we’re doing.”
Communication is rarely one-and-done. Revision is where alignment becomes commitment, and where each learner type gets a final pass to confirm their understanding.
Revision ensures:
This is where the message moves from “I sent it” to “We’re aligned.”
When you communicate using Teach → Try → Show → Revise, you naturally support different learning preferences:
Readers
Get structured explanations and written context they can revisit.
Listeners
Get spoken narratives, stories, and walkthroughs that make the change feel human.
Doers
Get working sessions, pilots, and exercises where they can apply the message.
Observers
Get demos, diagrams, and before/after views that make the work tangible.
The result is communication that people understand, remember, and repeat accurately—while reducing meeting churn, clarification messages, and rework.
When project communication incorporates instructional design techniques, it becomes:
This is the bridge between “I sent the email” and “The work moved forward.” Instructional design gives project leaders a practical, humane way to communicate change in environments where stakes are high and attention is limited.
How this insight supports different learners
R Readers
Strong headings, clear sequence, and written breakdown of each stage.
L Listeners
Career narrative and real-world scenarios that can be retold in meetings.
D Doers
The Teach → Try → Show → Revise cycle as a repeatable framework to apply.
O Observers
Concrete examples of what each stage looks like in project life.
Estimation looks scientific from the outside. Inside, it’s still a structured guess. This insight shows how PERT, Agile practices, and real accessibility issues work together to turn “we’ve never done this before” into grounded, repeatable estimates.
Estimation sounds scientific. We wrap it in spreadsheets, formulas, and confidence intervals. Underneath all of that, an estimate is still a guess. The moment you swap the word estimate with guess, our language gets uncomfortable:
We reach for the word estimate because guess feels unprofessional. The truth is simpler: an estimate is an informed guess based on what we know at a specific point in time. The only number we know for certain is the one we see when the project is over.
Project work is “progressively elaborated.” The more we do, the more we see. The more we see, the better our judgment. The better our judgment, the more informed our estimates.
Imagine the lifecycle as a funnel. At the top, your knowledge is thin and your estimate range is wide. As you move towards completion, experience narrows that funnel. You’ve seen real issues, real fixes, and real constraints. Accessibility work follows the same pattern as security, performance, or architecture.
In 1957, the United States Navy faced a familiar problem. They were developing the Polaris missile—the first solid-fueled, nuclear-armed, submarine-launched ballistic missile. They had never built anything like it and still needed a timeline and a budget.
Waiting until the end to “find out” wasn’t an option. So they created the Project Evaluation and Review Technique (PERT) to estimate work with limited history and high uncertainty. Today, PERT still solves the same problem we face when we look at accessibility findings for the first time.
PERT in one glance
For each activity, you imagine three outcomes:
PERT combines them like this:
Estimate = (bc + 4 × ml + wc) / 6
It doesn’t make the estimate “correct.” It makes it structured, explainable, and repeatable.
A good accessibility assessment tells you what was found, how often it appears, where it lives in your code, and how to fix it. That means you’re not estimating “accessibility magic.” You’re estimating familiar work: code changes, design decisions, and QA checks.
Suppose your report highlights three issue types:
Each behaves differently when you estimate effort. Name, Role, Value issues often look like straightforward code fixes. Information and Relationships might need design and UX input. Color Contrast can show up as a long list of findings but come from a small number of underlying tokens or variables.
Take a Name, Role, Value issue from your audit where you have a code snippet and a recommended fix. That means the work is already halfway known. Your developer and QA analyst sit down to estimate one representative case:
bc = 2, ml = 6, wc = 40
Estimate = (2 + 4×6 + 40) / 6 = 66 / 6 = 11 hours
You get an 11-hour estimate per Name, Role, Value issue. Multiply by the number of issues of that type and you have a defensible starting point. As the team fixes the first few, you refine the estimate based on experience rather than theory.
Many Agile teams use Planning Poker or Story Points instead of hour-based estimates. It looks different from PERT on the surface, but the purpose is the same: take something unknown and make it comparable.
Planning Poker was never about precision. It was designed to surface uncertainty, expose risk, and force conversation. That maps cleanly to accessibility work—especially when a team believes they’ve “never done this before.”
With a Name, Role, Value issue from your audit, the unknown becomes known quickly: you have the code snippet, the recommended fix, and a pattern that looks like other markup or component refactors the team has already done.
Using PERT thinking inside Planning Poker
You don’t need to show the PERT formula in an Agile ceremony. You’re borrowing the same mental model: acknowledge uncertainty, compare it to known work, and align as a team.
For predictable, pattern-based issues—like many Name, Role, Value changes or component-level fixes—this approach stabilizes quickly. By the second or third sprint, accessibility stops feeling like a foreign category of work and becomes another familiar stream in the backlog.
For more complex issues—such as Information and Relationships, Color Contrast that touches your design system, or component restructuring—Planning Poker becomes an alignment tool. Design, development, and QA have to be in the conversation so the Story Points reflect scope and impact, not just effort.
PERT gives you a formula. Planning Poker gives you a conversation. Both exist to make uncertain work discussable, comparable, and plannable. Accessibility estimation belongs there as a first-class citizen.
Fixing accessibility issues is necessary, but it is not a strategy. Many organizations treat accessibility as a one-time remediation event: run an audit, fix the issues, move on.
The real leverage comes when you shift from remediation to prevention:
The later you find a problem in the lifecycle, the more expensive it is to fix. By the time an accessibility issue surfaces in production, you are paying in rework, backlog churn, and customer trust. Prevention is not just good practice; it is good economics.
How this insight supports different learners
R Readers
Get a clear mental model for turning accessibility estimates from guesswork into informed, explainable numbers.
L Listeners
Hear how Polaris, PERT, and Agile ceremonies all tackle the same problem: making the unknown plannable.
D Doers
Walk away with a repeatable way to estimate Name, Role, Value and other issues—whether you use hours or Story Points.
O Observers
See how shifting from remediation to prevention changes the conversation with leadership about accessibility and risk.
A forthcoming insight on how program leaders connect architecture, operations, accessibility, customer experience, and finance to make better decisions under pressure.
This piece will connect back to the themes you see across all of these insights: accessibility as a core quality attribute, communication that actually lands, and estimation that treats uncertainty honestly.
It will focus on how program leaders:
As this article is drafted, it will also tie into the modernization and accessibility leadership talks on the Speaking page.
More writing · Change management · Practice
These articles extend the themes on this page—treating accessibility as a change in how work gets done, not just a checklist. The Lewin and ADKAR pieces are written by my colleague Heidi Kelly-Gibson as part of the same change management series we co-developed.
Sets up why accessibility requires intentional change management—framing accessibility work as a shift in culture, habits, and delivery, not just new tasks on a project plan.
R/L: big-picture framing and shared language for leaders.
Uses Lewin’s Unfreeze → Change → Refreeze model to show how accessibility practices take root over time instead of being a one-off initiative.
L/O: narrative on how teams move from old habits to new ones.
Plan Do Check Act (PDCA) Model focuses on the monitoring or adjusting that is important in change management due to the culture or identity of an organization.
L/O: focus on measuring the change so you can make the right one.
Walks through Awareness, Desire, Knowledge, Ability, and Reinforcement for accessibility, making it easier to diagnose why change is stuck.
D/O: practical levers leaders can pull when adoption stalls.
Connects strategy, portfolios, and delivery so accessibility work is visible, funded, and tracked—not lost in “nice to have” territory.
R/D: links directly to how you plan, sequence, and measure.
Shows how simple, systematic keyboard testing reveals real-world blockers—linking theory to concrete test steps anyone on the team can use.
D/O: specific interactions to try, observe, and improve.