If you built an app with an AI coding tool, there's a good chance you've never checked whether someone using a screen reader, a keyboard instead of a mouse, or a phone in bright sunlight can actually use it. That's not a character flaw. AI tools produce interfaces that look finished, and "looks finished" hides a lot.
Here's the reassuring part: the accessibility problems that matter most for a small app are not a mysterious engineering project. They come down to a short list of things you can check yourself in about fifteen minutes, and most of them can be fixed by asking your AI tool the right question. This post walks through the highest-impact fixes, gives you a self-check for each one, and shows you how to request the changes without breaking the layout you already have.
A quick boundary before we start. This is educational, not legal advice. Whether your app has a legal accessibility obligation depends on where you operate, who your users are, and what your app does, and that's a question for a qualified professional, not a blog post. What follows makes your app more usable for real people. That's worth doing on its own, and it's the same work that reduces legal risk.
In Plain English: accessibility means more people can actually use your app
Accessibility means your app works for people who don't interact with it the way you do. Someone with low vision. Someone who is colorblind. Someone who can't use a mouse and navigates entirely by keyboard. Someone using a screen reader that speaks the page out loud. Someone with a tremor, or a temporary broken wrist, or just an old phone in a moving train.
None of these people are edge cases. They're a normal slice of anyone's audience. When your app skips accessibility, it doesn't fail loudly. It just quietly turns some people away, and you never see them in your analytics because they left.
That's the frame to hold: this is usability for people who exist, not optional polish you add later if you have time.
Quick wins 1 and 2: color contrast and readable text
The two easiest things to check are how your text looks against its background, and whether it's big enough to read.
Color contrast is the difference between your text color and the color behind it. Light gray text on a white background looks elegant in a design mockup and becomes invisible to a lot of people in practice. AI tools lean toward low-contrast, "clean" palettes because they look modern, not because they read well.
Self-check: Copy a text color and its background color out of your app (your AI tool can tell you the hex codes if you ask) and paste them into any free online contrast checker. It'll give you a ratio and a pass or fail. As a rough target, normal body text generally wants a contrast ratio of at least 4.5 to 1, and larger text can be a bit lower. You don't need to memorize the number. You need to know that "pale gray on white" almost always fails and "dark text on a light background" almost always passes.
Readable text is the companion fix. Look at your app on an actual phone, not just your laptop. Is the body text comfortable to read without zooming? Tiny captions, thin fonts, and text crammed into small boxes are common in AI-generated layouts because the tool optimizes for fitting things on screen, not for reading comfort.
Self-check: Hand your phone to someone over 40 without your glasses prescription and ask them to read a paragraph. If they squint or bring it closer, your text is too small or too faint.
Quick win 3: labels and alt text AI tools love to skip
This is the big one, and it's the one AI tools miss most reliably.
A label is the text that tells a screen reader what a form field or button is for. When you look at a login form, you see a box with the word "Email" floating next to it and you understand. A screen reader doesn't see the visual arrangement. It needs the field to be explicitly connected to its label in the code. If that connection is missing, a blind user hears "edit text, blank" and has no idea what to type.
Alt text is the same idea for images. It's a short written description that a screen reader can read aloud, so someone who can't see the image still knows what it shows. A product photo with no alt text is just silence.
Why do AI tools skip these so often? Because labels and alt text are invisible. They don't change how the page looks. When an AI generates a UI, it's matching a visual pattern it has seen thousands of times, and the visible parts (the box, the placeholder text, the picture) are what it reproduces. The connective tissue underneath, the part only a screen reader uses, gets left out because leaving it out costs nothing visually. The page looks identical with or without it. That's exactly why it's easy to miss and easy to fix.
Self-check for labels: You usually can't see missing labels by looking, so this is one to hand off. Ask your AI tool directly: "For every form field and every button that shows only an icon, does it have an accessible label a screen reader can announce? List any that don't." Missing labels most often hit icon-only buttons (a bare trash-can or hamburger icon), search boxes, and fields that use placeholder text instead of a real label.
Self-check for alt text: Ask your tool to "list every image in the app and whether it has alt text." Decorative images that carry no information can have empty alt text on purpose, so don't panic if a background flourish is blank. Images that convey something (a chart, a product, a diagram) need a real description.
If you want to build a habit of catching this earlier, reviewing a diff as a non-engineer covers how to spot missing labels and alt text when your AI tool makes a change, before it ships.
Quick wins 4 and 5: keyboard navigation and visible focus
Some people never touch a mouse. They move through an app entirely with the keyboard, pressing Tab to jump from one control to the next and Enter or Space to activate things. This includes many screen reader users and people with motor conditions that make a mouse hard to use.
Keyboard navigation means every interactive thing (links, buttons, form fields, menus) can be reached and operated with the keyboard alone. Visible focus is the outline or highlight that shows which element the keyboard is currently on. Without it, a keyboard user is pressing Tab blind, guessing where they are.
AI-generated UIs often break this in two ways. They build custom buttons and menus out of generic elements that the keyboard can't reach, and they strip out the default focus outline because a designer somewhere decided it looked "ugly," so the tool learned to remove it.
Self-check (this one is genuinely fun and takes two minutes): Click once at the very top of your app, then put your mouse away. Press Tab repeatedly and watch. You should see a clear highlight move from one control to the next in a sensible order. Try to do a core task, like logging in or adding an item, using only Tab, Enter, and the arrow keys. Watch for three failures:
- The highlight disappears and you can't tell where you are. That's a missing focus state.
- Tab skips right past a button or menu you need. That control isn't keyboard-reachable.
- The focus jumps around in a weird order, like top to bottom then suddenly back up. That's a broken tab order.
If you can complete your app's main task with the keyboard and always see where you are, you've cleared a bar that a surprising number of shipped apps fail.
How to ask your AI tool to fix these without breaking the layout
You don't need to write any of the underlying code, and you shouldn't try to paste in raw markup you can't evaluate. Your job is to describe the problem clearly and scope the request tightly so the fix doesn't ripple out and rearrange your whole page.
The trap with a vague request like "make my app accessible" is that the AI may redesign components, swap out elements, or restructure your layout, and now you have new problems to review. The safer path is one specific fix at a time, with an explicit instruction to leave the visible design alone. If you want the full method, giving the AI a change request that does not break things goes deeper, but here's the shape for accessibility work.
A good scoped request names the exact problem, says what "done" looks like, and fences off the visual design:
"Add accessible labels to the icon-only buttons in the top navigation (the menu, search, and profile icons) so a screen reader announces what each one does. Do not change how the buttons look, their size, position, or the icons. Only add the accessible labels. List what you changed."
Notice the pattern: one problem, a clear success condition, an explicit "don't touch the visuals," and a request to report back so you can check the warning signs in AI-generated code before you accept it. Do the same for each fix:
| Fix | Ask for | Guardrail to include |
|---|---|---|
| Contrast | Darken the text (or lighten the background) enough to pass a 4.5:1 contrast check | Keep the same layout and font sizes |
| Labels | Add accessible labels to all fields and icon-only buttons | Don't change how anything looks |
| Alt text | Add alt text to informational images; empty alt on decorative ones | Don't resize or move images |
| Keyboard | Make all custom buttons and menus reachable and operable by keyboard | Keep existing appearance and behavior |
| Focus | Restore a clearly visible focus outline on all interactive elements | Match the app's colors; don't remove it |
After each change, run the matching self-check again. Contrast fix? Re-check the ratio. Label fix? Ask the tool to list labels again, or tab to the button and confirm. Fix one thing, verify it, then move to the next. That rhythm keeps any single change small enough to review and easy to undo if it goes sideways.
When to bring in an accessibility professional
The self-checks here catch common, high-impact problems. They do not establish conformance with WCAG 2.2 or any law. Real accessibility is broader than five checks; use the applicable standard and qualified testing for a production claim.
Bring in an accessibility professional when:
- Your app is complex: custom interactive widgets, drag-and-drop, data tables, charts, multi-step flows, or anything a user builds or manipulates on screen.
- You have real legal exposure: you serve a large or public audience, operate in a regulated sector, sell to organizations that require an accessibility conformance report, or work in a jurisdiction with accessibility requirements that apply to you. Whether any of this applies to your situation is a legal question, and this post is educational, not legal advice.
- You've done the quick wins and want to confirm the app actually works for people using assistive technology. A professional audit, ideally including testing with real assistive-technology users, tells you what an automated check can't.
Think of the self-checks as the smoke detector and the professional as the inspector. The smoke detector is worth having on day one. It doesn't replace the inspection when the stakes are high.
In Plain English
What this means: The accessibility fixes that matter most for a small AI-built app are a short, checkable list: readable contrast, readable text size, real labels, alt text, keyboard access, and a visible focus outline. You can verify all of them yourself, and you can request them without writing code.
Who it helps: Non-technical builders who suspected their app might be hard to use for people with disabilities and assumed fixing it was a giant project. It isn't. It's a handful of scoped requests.
When to use it: Before you launch, and again any time your AI tool rebuilds a screen or adds a form. AI-generated UIs regress on these quietly, so it's a check to repeat, not a one-time task.
What to do next: Run the five self-checks on your app today. Write down what fails. Turn each failure into one scoped change request, verify it, then move to the next.
Your next step
Take the failures you found and turn them into precise AI requests using the change-request templates, fixing one item at a time and re-checking as you go. Accessibility is one line on a longer list, so once you've cleared it, work back up the ship-responsibly pre-launch checklist from the Ship Responsibly hub to see what else stands between your app and a calm launch. If you're not sure where you are in the process, start here.
Kodbe is an independent commercial publication about maintaining and owning software built with AI or no-code tools. It is not affiliated with Kodbe Inc, Kodobe, Kodable, or Kodu.