Accessibility belongs with the “-itties”
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.
In one line
Accessibility belongs in this same category of core quality attributes.
WCAG gives you the requirement set
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:
- Measurable
- Repeatable
- 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.
To integrate accessibility, teams can:
- 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’s a second evolution: treating it as a Customer Experience Requirement.
We’ve 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. 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.