Stevie Cline on Why Accessibility Should Be Considered from the Start of Every Project
Stevie Cline has watched again and again as a development team spends months building a polished, feature-rich web application, reaches the final stages of the project, and then somebody raises accessibility. What follows is a painful scramble to retrofit screen reader compatibility onto components never designed for it, color contrast adjustments that ripple through an entire design system, and keyboard navigation logic bolted onto interactive elements that were built exclusively with mouse users in mind.
The work is harder than it would have been at the start, the timeline stretches, and the result is rarely as clean as it would have been had accessibility been part of the conversation from day one. The pattern plays out across teams of every size and experience level, and it is almost entirely avoidable.
Accessibility Is a Foundation
The most persistent misconception surrounding web accessibility is that it functions like a feature: something discrete that can be scoped, scheduled, and added to a product at a convenient point in the development cycle. That framing is not just inaccurate — it is expensive. Accessibility is not a layer applied on top of a finished product. It is a quality woven into the fabric of how a product is designed and built, and like most qualities of that kind, it is far easier to build in than to add later.
When developers treat accessibility as foundational as opposed to supplemental, the decisions that support it become part of the natural flow of development. Semantic HTML elements get chosen for the right reasons from the beginning. Color palettes are evaluated against contrast requirements during the design phase.
Interactive components are built with keyboard operability in mind because the developer writing them is thinking about all users. None of these decisions require dramatically more time when made at the outset. All of them require significantly more time when made as corrections. Stevie Cline draws a clear line between teams that understand this and teams that do not.
“When accessibility is treated as a retrofit, you end up compromising everywhere,” she says. “You’re making fixes that work around the original architecture instead of working with it. The final product is always better when inclusion is part of the design thinking, not an afterthought that shows up at the end.”
The Real Scope of Who Accessibility Serves
Conversations about web accessibility often center on users who are blind or have significant visual impairments. The scope of who accessibility serves, however, is considerably broader than that framing suggests. Approximately one billion people worldwide live with some form of disability, and the range of conditions that web accessibility practices address spans visual, auditory, motor, and cognitive dimensions.
A user navigates with a switch device because fine motor control is limited. A person with low vision using browser zoom at 200 percent. Someone with a cognitive disability who relies on consistent navigation patterns and plain language to move through a site without confusion. An individual with temporary wrist injury who cannot use a mouse for several weeks.
That last category points to something accessibility advocates have long pointed to, that disability is not always permanent. Situational and temporary limitations affect users who would not typically identify as disabled, expanding the population that benefits from accessible design surpassing what initial assumptions might suggest. Cline holds this broader view of the accessibility audience as a core part of her development philosophy.
“Accessible design is good design for everyone,” she notes. “When you build for the edges, the middle takes care of itself. The improvements you make for users with disabilities almost always make the experience better for users without them.”
Where Accessibility Lives in the Development Process
Integrating accessibility from the start means understanding where it intersects with each phase of development, because it intersects with all of them. During planning, it means ensuring that user stories account for diverse user needs and that acceptance criteria include accessibility requirements alongside functional ones.
During design, it means selecting typography, color, spacing, and interactive patterns with accessibility guidelines in mind, referencing the Web Content Accessibility Guidelines as a living standard instead of an occasional checklist. During development, it means writing semantic markup, providing text alternatives for non-text content, ensuring focus management works correctly for keyboard users, and testing with assistive technologies.
Automated accessibility testing tools can identify a meaningful percentage of common issues and belong in every team’s continuous integration pipeline. They are not sufficient on their own as automated tools cannot replicate the experience of a screen reader user navigating a complex interface, nor can they evaluate if the language used in error messages is clear enough to be actionable.
Manual testing, including testing with actual assistive technologies and, where possible, with users who have disabilities, produces the kind of insight that no automated scan can replace.
“Passing an automated scan doesn’t mean you’ve built something accessible,” says Cline. “It means you’ve cleared a minimum bar. The real standard is whether a real person with a disability can use what you built without running into walls.”
The Business and Ethical Case for Getting It Right
Accessibility carries real legal weight, and in the United States, the Americans with Disabilities Act has been applied to digital properties with increasing frequency, and federal agencies must meet standards under Section 508 of the Rehabilitation Act. The European Accessibility Act extends similar requirements across digital products and services.
Organizations that treat accessibility as optional assume legal risk that grows as enforcement matures. The ethical dimension deserves equal weight. Excluding users with disabilities is a choice, rarely considered, but a choice nonetheless.
For Stevie Cline, good engineering means building things that work for everyone instead of focusing only on the majority. Accessibility pursued with genuine intention from day one produces fewer remediation cycles, less technical debt, broader reach, and the kind of user trust that reflects thoughtful, inclusive development.
Stevie Cline is a software developer and recent University of Maryland graduate with a B.S. in Computer Science. Passionate about building meaningful software and helping others grow in the field, she brings both technical range and a collaborative spirit to everything she creates.
The views and opinions expressed in this article are those of the individual featured and do not represent the views of this publication or its affiliates. This content is intended for informational purposes only.