Accessibility is often framed as a checklist done at the end, but that leads to expensive rework. In Chakra UI projects, I prefer to bake accessibility into component choices from the start. Semantic elements, sensible heading hierarchy, sufficient color contrast, and keyboard-friendly controls should be default decisions, not post-launch fixes. This approach reduces bugs and creates better experiences for every user, not only users with assistive technology.
The first pattern is semantic scaffolding. Use clear landmark sections and meaningful headings so users can scan quickly. A page should have one primary h1, then h2 sections that represent major blocks like projects, experience, and contact. Within cards, use h3 titles. This hierarchy helps screen readers create an understandable document outline and helps visual users parse structure at a glance.
The second pattern is responsive spacing with readability limits. Chakra makes it easy to set responsive values, but readability still needs intent. For long-form text, keep line length reasonable and avoid giant wall-of-text paragraphs on desktop. On mobile, increase vertical rhythm and avoid crowded control groups. Good spacing is not only aesthetics; it is comprehension support.
Interactive controls require careful labeling. Icon-only buttons must include clear aria-label values, and toggle components should map to understandable states. If users cannot identify what a control does without visual context, assistive users are likely blocked. I also avoid placing critical functionality behind hover-only interactions, because touch and keyboard users will miss those paths.
Contrast and theme support are common trouble spots in dark mode capable apps. Token-driven color variables help, but verify text contrast in both themes and across states like hover, disabled, and focus. A muted text color that looks elegant on one monitor can become unreadable on another. Real device checks catch issues synthetic contrast tools sometimes miss.
Error and fallback states deserve the same attention as primary states. If an iframe preview fails or an external source is blocked, users still need context and a next action. A short explanation plus a direct 'open project' link preserves usability and trust. Silent failure, by contrast, feels broken and can hurt credibility during manual site review.
Accessible UI is iterative, not binary. Build with semantic defaults, test navigation by keyboard, verify readability on mobile, and treat fallback states as first-class UX. These habits produce cleaner code and fewer surprises during review cycles. The result is a site that feels intentionally engineered rather than cosmetically polished.