A lot of accessibility work feels like remediation. You build something, you scan it, you find the problems, you fix them, you repeat. That cycle is real and it’s necessary, but it’s expensive, time-consuming, and frankly exhausting.<\/p>\n\n\n\n
The alternative is designing with access in mind from the beginning. Not as a constraint, not as a checklist you apply at the end, but as a set of design values that shape your decisions before a single pixel is placed or a line of code is written.<\/p>\n\n\n\n
This post covers the fundamentals. <\/p>\n\n\n\n
Typography. Color. Structure. Content. <\/p>\n\n\n\n
These are the decisions that either build accessibility in or design it out\u2026 and most of them, once you know what you’re looking for, aren’t complicated at all.<\/p>\n\n\n\n
Type is where a lot of accessibility either begins or breaks down. A few principles worth internalizing:<\/p>\n\n\n\n
Size matters.<\/strong> Body text should be a minimum of 16px\u2026 and honestly, 18px is more comfortable for most readers. This isn’t just about users with low vision. Smaller type is harder for everyone to read, especially on mobile.<\/p>\n\n\n\n Weight and contrast work together.<\/strong> A thin or ultra-light font weight can fail contrast requirements even when your colors technically pass, because the strokes are so narrow that the effective contrast drops. Default body text should be set in a regular or medium weight, not light or thin.<\/p>\n\n\n\n Line height and spacing.<\/strong> WCAG recommends a line height of at least 1.5 times the font size for body text, with paragraph spacing of at least 2 times the font size. Letter spacing of at least 0.12 times the font size. These numbers sound technical but they translate to a simple principle: give your text room to breathe. Dense, tightly packed type is harder to read for everyone, and much harder for users with dyslexia or cognitive disabilities.<\/p>\n\n\n\n Avoid ALL CAPS for running text.<\/strong> All-caps treatment reduces reading speed and comprehension, particularly for users with dyslexia. It’s fine for a short label or a heading if used deliberately, but it’s not appropriate for paragraphs or long passages.<\/p>\n\n\n\n Don’t rely on italics alone to convey meaning.<\/strong> Italics are harder to read for some users and aren’t always conveyed by screen readers. If something is important, say so in the content. Don’t rely on visual styling to carry meaning.<\/p>\n\n\n\n Font choice.<\/strong> No specific typeface is required by WCAG, but highly decorative, hand-lettered, or novelty fonts present real readability challenges. Use expressive typography for display and branding purposes where appropriate, but default body text should be set in something legible.<\/p>\n\n\n\n Color is one of the most common places accessibility breaks down, and one of the most fixable.<\/p>\n\n\n\n The WCAG contrast requirements:<\/strong><\/p>\n\n\n\n These ratios are testable with the tools mentioned in the last post. Run everything through a contrast checker before you commit\u2026 not after.<\/p>\n\n\n\n Common failures that might surprise you:<\/strong><\/p>\n\n\n\n Never use color alone to convey information.<\/strong> If your form uses red text to indicate an error, that information is invisible to users who are colorblind and to screen readers. Color can be part of how you communicate, but it always needs a companion: an icon, a label, a pattern, a shape. Something that works without color.<\/p>\n\n\n\n Think about dark mode and forced colors.<\/strong> Many users with visual disabilities use high contrast or forced color modes on their operating systems. Designs that rely heavily on subtle color differences or low-contrast decorative elements can fall apart in these environments. Testing in high contrast mode (available in both Windows and macOS) is worth adding to your review process.<\/p>\n\n\n\n Visual design creates hierarchy through size, weight, color, and placement. Accessible design makes sure that hierarchy is also communicated in the underlying code\u2026 because screen readers, search engines, and assistive technologies read the code, not the visual presentation.<\/p>\n\n\n\n Headings are navigation tools.<\/strong> Every page should have exactly one H1, your main page title. Subsequent sections use H2. Subsections within those use H3. And so on. Don’t skip levels. Don’t use heading tags because you like the font size, use them to communicate document structure. A screen reader user navigating a page by headings is relying on this hierarchy to understand what’s on the page and jump to what they need.<\/p>\n\n\n\n Use real lists for lists.<\/strong> If you’re listing items (services, resources, steps in a process) use actual HTML list elements, not dashes, bullets created with special characters, or line breaks. Real lists are announced as lists by screen readers, giving users important context about the content structure.<\/p>\n\n\n\n Tables are for data, not layout.<\/strong> If you’re using a table to arrange visual elements on a page, that’s a layout table\u2026 and it creates significant confusion for screen readers. Tables should be used exclusively for tabular data, with proper header cells that identify what each column and row contains.<\/p>\n\n\n\n White space is an accessibility tool.<\/strong> Adequate spacing between elements, between lines, between sections\u2026 this benefits users with cognitive disabilities, users with low vision, and honestly, every single person reading your content. Cramped, dense layouts are harder for everyone.<\/p>\n\n\n\n Alt text is a writing task, not a technical task.<\/strong> Good alt text describes what the image communicates, not just what it depicts. A photo of your executive director at a ribbon cutting doesn’t need alt text that says “woman smiling.” It might need: “Executive Director Jane Smith at the ribbon cutting for the new community center, March 2026.” Context matters. Purpose matters. What would a sighted user understand from seeing this image that a non-sighted user needs to know?<\/p>\n\n\n\n Decorative images should be marked as such.<\/strong> If an image is purely decorative (a background texture, a divider graphic, a purely aesthetic illustration) it should have an empty alt attribute (alt=””) so screen readers skip it entirely. An absent alt attribute is an error. An empty one is intentional and correct.<\/p>\n\n\n\n Videos need real captions.<\/strong> Auto-generated captions are a starting point, not a solution. Review them, correct them, and make sure they accurately represent everything being said, including speaker identification when multiple people are speaking, and relevant non-speech audio like [applause] or [alarm sounds].<\/p>\n\n\n\n Don’t autoplay.<\/strong> Autoplaying video or audio is disorienting for screen reader users, whose experience of the page is immediately interrupted, and it’s a frustration for many other users as well. If autoplay is truly necessary, provide an immediate, easy way to pause or stop it.<\/p>\n\n\n\n Everything must work with a keyboard.<\/strong> No exceptions. Every link, button, form field, dropdown, modal, and interactive element must be reachable and operable using only the keyboard. Tab to navigate, Enter or Space to activate, Escape to close. If you can’t do it without a mouse, it’s not accessible.<\/p>\n\n\n\n Don’t remove focus indicators.<\/strong> That outline that appears around a focused element? It exists for keyboard users. It’s one of the first things designers remove because it looks untidy. Don’t. If you don’t like the default browser styling, replace it with something visible and intentional, but don’t remove it without a replacement.<\/p>\n\n\n\n Links and buttons need descriptive labels.<\/strong> As we covered in the testing post, “click here” and “read more” aren’t sufficient. The label of any interactive element should tell you what it does or where it goes, independent of the surrounding context.<\/p>\n\n\n\n Forms need visible, persistent labels.<\/strong> Placeholder text disappears when a user clicks into a field. It cannot serve as a label. Every input needs a visible label that stays visible regardless of the field’s state.<\/p>\n\n\n\n Here’s what ties all of this together: accessibility in design isn’t a separate discipline from good design. Clear type, sufficient contrast, logical structure, descriptive content… these make things better for everyone. They benefit people on mobile phones in bright sunlight. People who are tired. People who are aging. People who are distracted. People who are reading in a second language.<\/p>\n\n\n\n The “rules” of accessible design are really just design doing its job thoroughly… accounting for the full range of people who will encounter what you’ve made, not just the ones who look and function like you do.<\/p>\n\n\n\n That’s the shift. From designing for a default user and accommodating everyone else, to designing for the full range of human experience from the start.<\/p>\n\n\n\n It takes practice. It takes testing. It takes humility about what you don’t know yet. But it’s the work… and it’s worth doing.<\/p>\n\n\n\nColor and contrast<\/h2>\n\n\n\n
\n
\n
Structure and hierarchy<\/h2>\n\n\n\n
Images and media<\/h2>\n\n\n\n
Interactive elements<\/h2>\n\n\n\n
The bigger picture<\/h2>\n\n\n\n