Accessibility belongs with the “-itties”
Imagine you are leading a project destined to change the world. A project that is key to your core business. There is a twist: 26% of Americans will miss it. 15% of the world will miss it. Not because of a market failure. Because it is inaccessible.
That is not a compliance problem. That is a planning problem. And the fix starts at the beginning of the project, not the end.
My approach is simple: look for structures your teams already understand. In IT, that is non-functional requirements (NFRs).
NFRs describe how a system must behave and the qualities it must demonstrate. They are often the “-itties”: Security, Stability, Scalability, Manageability, Maintainability, Serviceability, Recoverability, Capacity, Availability, Reliability, Data Integrity, and Usability.
When these qualities are healthy, customers do not 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.
In one line
Accessibility belongs in this same category of core quality attributes.
WCAG gives you the requirement set
Accessibility is not 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 measurable, repeatable, and predictable. Those are exactly the qualities you want in your planning and risk conversations.
Where accessibility fits in agile delivery
Modern frameworks already tell us where NFRs belong. Dean Leffingwell (SAFe) and Mike Cohn (Scrum) both describe NFRs as constraints across every backlog.
Integrating accessibility follows the same path. Embed WCAG success criteria into the Definition of Done. Add accessibility acceptance criteria to every user story. Treat accessibility as a non-negotiable quality constraint, not extra work.
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.
From obligation to Customer Experience Requirement
Once accessibility is established as a quality attribute, there is a second evolution: treating it as a Customer Experience Requirement.
We have already seen this in practice. Amazon used accessibility-first thinking to shape Alexa. Apple turned VoiceOver and biometric login into mainstream features. Many innovations were originally designed for people with disabilities, then became beloved by everyone.
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.
Questions this insight answers
- What is the difference between accessibility as compliance and accessibility as a requirement?
- When should accessibility be included in a project plan?
- How does treating accessibility as a non-functional requirement change delivery?
- Why does adding accessibility at the end cost more than building it in from the start?
- What does good accessibility look like as a measurable project outcome?