I thought the dialog was done because it looked right with a mouse. Then I tried to use the product with only a keyboard and got trapped between two buttons. The bug was small, but the product was unusable for somebody who depended on that path.

Accessibility can sound like a giant compliance project. For an indie product, it can start with a few practical checks that make the interface clearer and more flexible for a lot of people.

Make the main flow work without a mouse

Use the keyboard to move through the page. Can you reach every action? Is the focus visible? Does the order make sense? Can you close a dialog and return to where you were? If focus disappears or jumps somewhere unexpected, fix that before adding more controls.

Buttons should do button things, and links should navigate. Use real labels for fields. A placeholder is not a lasting label because it disappears as soon as someone types. Clear errors should say what went wrong and how to fix it, not only turn a border red.

A founder tests a product flow using a keyboard and an accessible display

Check contrast and meaning

Text should be readable against its background, including in hover, disabled, and error states. Don't use color as the only way to communicate status. Add a label, icon with accessible text, or pattern as needed. A green dot and red dot may look distinct to some people and identical to others.

Images that carry meaning need a concise text alternative. Decorative images can be hidden from assistive technology. Charts should include a summary or accessible data table when people need the values, not only the shape. Do not write alt text like “image123-final-final”; describe the information the person would otherwise miss.

Give controls useful names

Icon-only buttons need an accessible name that explains the action. “Edit project” is clearer than “pencil.” If a control updates the page, communicate the change so a screen reader user knows it happened. When you add a custom widget, check whether a native HTML control already does the job.

Form validation should not depend on somebody guessing what an error icon means. Put the message near the field, connect it to the field, and make sure it is announced when the user needs it. Keep the wording direct: “Enter a valid email address” is more useful than “Invalid input.”

Use automated tools as a first pass

An accessibility checker can catch missing labels, some contrast issues, and other common problems. It cannot tell whether the reading order makes sense, whether your instructions are clear, or whether the product is understandable to a person doing a real task. Automated results are a starting list, not a certificate.

Test the core path with keyboard navigation and, when possible, a screen reader. Ask disabled users to participate and compensate them for their expertise. Do not expect a friend to represent every disability or assistive technology.

The W3C WCAG quick reference is a useful map when you need to look up a specific criterion. You don't need to memorize it to fix a keyboard trap or add a missing label today.

Include access in the definition of done

Add a few concrete checks to your own release checklist: keyboard access for the main flow, visible focus, labels and errors, contrast for key text, and meaningful alt text. New components should be checked as they arrive, not postponed for a mythical accessibility sprint at the end.

If you discover a barrier, prioritize it alongside other bugs. Tell users what changed and offer a way to contact you if they still get stuck. A small team's ability to fix feedback quickly can become a real strength.

A 10-minute pass on your next release

  1. Complete the main task with only a keyboard.
  2. Check focus order and visible focus.
  3. Inspect labels, instructions, and error messages.
  4. Check contrast and make sure meaning isn't color-only.
  5. Review alt text for images that carry information.

Accessibility is not decorative polish. It's part of whether people can use the product you built. A few regular checks won't solve every access need, but they can remove avoidable barriers and help you learn from a broader group of customers.

Make accessibility checks part of shipping

Put a few tasks into the same checklist as your release notes: tab through the main flow, check focus, zoom the page, inspect form errors, and test a screen reader on the most important interaction when you can. Fix the issue where it appears instead of opening a giant backlog called “accessibility later.” Small improvements are easier to understand when they sit next to the feature that introduced the barrier.

Automated checks can keep common problems from slipping back in, but someone should still use the product. Ask people with different access needs to test important workflows and compensate them for their time. Avoid asking one person to stand in for a whole community, and let testers decide what feedback they want to share publicly.

When you change a flow, review it again. A new dialog can break keyboard focus; a new chart can add information that is invisible to a screen reader. Accessible defaults are easier to maintain than a last-minute retrofit.