Accessibility audits at the end of a release cycle find problems that should never have shipped. In product design work — especially B2B platforms with complex tables, forms, and modals — I treat WCAG contrast, focus order, and keyboard support as part of the component definition from day one.
That means documenting focus traps in dialogs, specifying error states for form validation, and pairing with engineers on semantic HTML before pixel polish. React makes it tempting to rebuild native behaviour; the design system's job is to encode the accessible path so teams do not have to remember it every sprint.
At ComplyAdvantage and Ocado, this approach reduced rework and made QA conversations clearer: we were testing against criteria we had already designed for. Users with screen readers or keyboard-only navigation got a better experience; everyone else benefited from clearer focus states and error messaging.
If you are building a design system, start with the components that touch user input and data density. That is where accessibility and UX/UI quality intersect most visibly.