There is a version of a website that looks polished in a portfolio screenshot, passes a visual review, and still fails a meaningful portion of the people who try to use it. No keyboard access. Text that disappears against its background in sunlight. Buttons that are impossible to identify without a mouse hover. It functions for some people under ideal conditions, and that has always been the problem with how our industry tends to define "done."
I came to accessibility not through a compliance mandate but through noticing gaps in my own work. A color pairing I loved failed its contrast check. A navigation pattern I had designed with care fell apart the moment someone tried to tab through it. Those moments shifted how I think about the design process, and they are why accessibility criteria now come in at the start of a project rather than the end.
When someone visits your website and something does not work for them, they do not file a bug report. They leave, and they form an impression of the organization behind that site. Inaccessible design is not a neutral experience. It communicates, clearly and immediately, that certain users were not considered during the build.
That is a trust problem before it is a compliance problem. And it is one that no amount of good copy or strong visual design can fully offset. The work of building trust happens at the level of color choices, interactive states, and page structure. It is quiet, technical, and invisible to users when it is done well. That invisibility is the point.
Compliance sets the floor. Trust is built by everything you choose to do above it.
Color contrast is one of the first decisions made in any project, and one of the most consequential. WCAG 2.1 sets a minimum ratio of 4.5:1 for normal body text and 3:1 for large text and UI components. Those thresholds reflect real research into readability across different visual abilities, screen types, and lighting environments.
In my Figma workflow, I check contrast ratios at the variable level before a single component is touched. If a color pairing does not pass at the token stage, it does not move into the semantic layer. This is a small process change with a large downstream effect. Finding a contrast failure after a full component library exists is a much harder fix than catching it in the color palette. The earlier the check, the cheaper the correction.
I also check contrast across states, not just the default. A button that passes at rest might fail in its hover or disabled state. Interactive components have multiple moments where contrast needs to hold, and each one deserves the same scrutiny as the first.
Contrast checks I run before building components
Most keyboard accessibility issues start in the design file. Tab order that skips important actions. Modals with no clear way to close them via keyboard. Dropdowns that only open on hover. These are not implementation mistakes. They are design decisions made without keyboard users in mind, and by the time a developer encounters them, the pattern is already set.
When I design interactive components in Figma, I document the expected keyboard behavior alongside the visual variants. Which elements receive focus and in what order. What the focus indicator looks like. Which keys trigger which actions. That documentation gives developers something specific to build against and makes the handoff into Webflow significantly cleaner. There is no guesswork on either side.
Focus indicators deserve particular attention. Browser defaults are often too subtle to be useful and vary wildly across environments. I treat focus styles as a design element with the same care as any other interactive state: visible, consistent, and on-brand without sacrificing clarity.
Meeting WCAG 2.1 AA is a meaningful baseline. It represents a well-researched, peer-reviewed standard developed with real input from people with disabilities, and it carries legal weight in a growing number of jurisdictions. Hitting that standard matters, and I build toward it deliberately on every project.
That said, automated compliance tools catch somewhere between 30 and 40 percent of accessibility issues. The rest require human judgment, actual user testing, and a willingness to treat accessibility as a continuous practice rather than a one-time audit. A site can pass every automated check and still present real barriers to real people. Compliance is where the work starts, not where it ends.
The goal I work toward is not a passing score. It is a site that a wider range of people can use with less friction, in more conditions, across more devices. That goal is always in progress, and that is exactly how it should be.
Every website makes a statement about who it was designed for. That statement is not in the copy or the color palette. It is in whether someone using a keyboard can complete a task without getting stuck, whether the contrast holds up on a phone screen in daylight, whether the interactive elements behave in ways that are predictable and consistent.
More than a URL means more than a destination on the web. It means a space that was genuinely built for the people who arrive at it. That is the standard worth working toward, one project at a time.
