Your Vibe-Coded App Probably Doesn't Need That Custom Control

Your Vibe-Coded App Probably Doesn’t Need That Custom Control

I see so many apps now that people want me to test, especially apps being built with AI, and a lot of them are not accessible.

But here is the frustrating part.

A lot of them absolutely have the potential to be.

I will open an app and think, this is actually cool. I like what they are trying to do here. The app looks like it has been thought through, the idea is good, and then I start going through it with VoiceOver and something that should be really simple just does not work.

And one thing I keep seeing is custom controls.

Developers are obsessed with custom controls.

I understand why.

I am a SwiftUI developer. I like making things look good too. Sometimes you don’t want the default thing. Maybe you want a different-looking toggle. Maybe you want your own picker. Maybe you have some really nice cards where one of them is selected. Maybe you want a button to animate differently or you want something that fits the design of your app better.

That is fine.

I am not saying do not make custom controls.

But I think we need to talk about what you are actually doing when you decide to replace the control Apple already gave you.

What are you actually replacing?

Let’s take SwiftUI.

SwiftUI already gives us Button.

It gives us Toggle.

It gives us Picker.

It gives us Slider, TextField, TabView, and all of these other controls.

And those controls are not just what you see on the screen.

That is the part I think gets missed.

SwiftUI has accessibility support built into the framework. Apple specifically documents accessibility modifiers and representation APIs so developers can preserve or refine what assistive technology gets from an interface.

So when I use a real SwiftUI Button, I am not just getting something I can tap.

I am getting a control the system already understands as a button.

VoiceOver understands it.

The operating system understands it.

Apple has already done a bunch of work for me.

Same thing with something like a Toggle. It already has the concept that this thing can be on or off. A Picker already has a selection.

Then we come along and go:

Well, I don’t like how that looks.

And now instead of a Button, maybe we have an HStack with an onTapGesture.

Or instead of a Toggle, we make our own thing with a circle that slides across the screen.

And that might look fantastic.

But now you have to ask:

What did I just throw away?

This is what I keep finding

I will find something where there are three choices on the screen.

Let’s say:

Basic.

Pro.

Business.

You select Pro and visually it changes color.

Great.

Then I come along with VoiceOver and swipe through it.

Basic, button.

Pro, button.

Business, button.

Okay.

Which one is selected?

I have no idea.

The developer built the visual selected state. The AI built the visual selected state. Everybody looking at the screen knows exactly what is happening.

But nobody told VoiceOver.

Or I get a custom switch.

I activate it.

The little thing moves from the left to the right.

Is it on?

Is it off?

VoiceOver does not know.

Or somebody has made a really nice custom control where tapping a card does something.

Maybe VoiceOver does not even tell me it is a button.

Maybe I hear a bunch of text and have no idea that I am supposed to interact with the thing.

This is the kind of stuff I am seeing in apps people are giving me to test.

And I keep thinking, why?

Because these apps are not that far away from being accessible.

Some of them are really close.

I think vibe coding makes this easier to do

This is one of the things I worry about with vibe coding.

You tell the AI:

Make this look better.

Make me a custom toggle.

Make these options look like cards.

Make this whole row clickable.

Make this picker more modern.

And it does it.

That is what you asked for.

And I use AI to code too, so I am not saying AI coding is bad. I use it all the time.

But if what you asked for was a visual design, that is what it is going to focus on.

And if the custom thing looks right and you can tap on it, it is really easy to go:

Great. That works.

Until somebody like me comes along and actually tries to use it with VoiceOver.

The AI does not get lost.

It does not hear three buttons and wonder which one is selected.

It does not sit there trying to figure out whether your switch is on or off.

It does not get frustrated because it cannot find the control you spent all afternoon making look really good.

That is why somebody still has to test this stuff.

But I want a custom control

Okay.

Make one.

Seriously.

If the custom control makes your app better, build it.

Apple gives developers accessibility APIs for custom interfaces for exactly this reason.

But now you own more of the work.

That is the point.

You have to think about what this thing is.

What should VoiceOver call it?

What state is it in?

Can I operate it?

If the state changes, can I tell?

If something opens, where does my focus go?

If it has some special gesture, is there another way for me to perform that action?

What happens with Voice Control?

What happens with Switch Control?

And then you have to actually test those things.

Here is something else I think is really interesting in SwiftUI.

Sometimes you can still have the custom design without throwing the underlying accessibility away.

Apple’s accessibilityRepresentation API is specifically designed for cases where a custom interface can be represented to accessibility using another SwiftUI view. Apple also notes that custom styles can preserve the accessibility features of the underlying control.

That is exactly what I am talking about.

You do not always have to choose between:

boring app

and

accessible app.

Sometimes the answer is to customize the native thing instead of rebuilding the entire thing from scratch.

Do you really want to rebuild all of this?

This is the question I want vibe coders especially to ask.

Do you really want to replicate the mountain of work Apple already did?

Because Apple has been working on VoiceOver and accessibility across its platforms for years.

You get a lot of that work when you use the platform the way it was designed.

Then we sometimes throw that away because the AI can recreate the visible part of a control in thirty seconds.

Now we have to recreate the rest of it.

And maintain it.

And test it.

And make sure the next AI refactor does not break it.

And make sure when we add another state later, accessibility gets that state too.

That sounds like more work to me.

And this is not just an Apple idea.

On the web, W3C literally has what it calls the first rule of ARIA: if a native HTML element already gives you the semantics and behavior you need, use it instead of recreating the control with ARIA.

There is a reason people keep giving this advice.

Native controls have a bunch of behavior that somebody else has already built and tested.

Why take all of that work back onto yourself unless there is a good reason?

And yes, accessibility can become a legal problem too

I do want to talk about this because I think developers need to know it, but I also don’t want to scare people with bad legal information.

I am not a lawyer and this is not legal advice.

Depending on what you are building, who you are building it for, and where you are doing business, accessibility can create legal and compliance risk.

In the United States, the Department of Justice has specific accessibility requirements for web content and mobile apps from state and local governments under Title II of the ADA, using WCAG 2.1 Level AA as the technical standard.

For private businesses, the legal situation can depend on the business, the service and the jurisdiction, but the ADA does impose accessibility obligations on businesses open to the public, and DOJ publishes guidance about accessibility of businesses’ digital offerings.

And if you are offering certain covered products or services in the EU, the European Accessibility Act covers areas including e-commerce, banking services, smartphones, computers and other covered products and services.

So yes, potentially this can get bigger than one blind person being annoyed by your custom picker.

But honestly, that is not even the main argument I want to make.

I want to use your app

That is what I wish more developers understood.

When I test one of these apps and complain that I cannot use a control, it is usually because I was actually trying to use the app.

I wanted to see what it did.

I wanted to sign up.

I wanted to try the feature.

Sometimes I really like the idea.

And then I get to something that the developer probably thought was a tiny piece of the interface and I cannot continue.

That is what is frustrating.

You did all of this work.

You had the idea.

You used AI and got something built that maybe would have taken you months before.

You shipped it.

And then I cannot use it because the custom control that replaced a Toggle never tells VoiceOver whether it is on.

Come on.

We can do better than that.

Especially because SwiftUI gives us such a good place to start.

Before you tell the AI to make another custom control

Just ask yourself:

Does SwiftUI already have something that does this?

Can I style that instead?

Can I use a custom ButtonStyle or ToggleStyle and keep the underlying control?

If I really do need to build this myself, what did the native control used to do for accessibility that I now have to do?

And after you build it, turn on VoiceOver.

Actually use it.

Don’t just ask your AI:

Is this accessible?

Don’t just look through the code and see an accessibility label and assume everything is good.

Use the thing.

Try to select something.

Try to turn your switch on.

Open your custom picker.

Close it.

See where VoiceOver goes.

Do your actual app flow.

Because that is what I am going to do when you give the app to me.

And that is really why I started Taylor’s Teardowns.

I keep seeing apps with potential that are not accessible.

I don’t want to tell somebody their whole app is terrible and they need to start over.

A lot of the time they don’t.

I want to be able to say:

This is good.

This part works.

Here is where I got stuck.

Here is the custom control that is causing the problem.

Here is what I would fix first.

That is a lot more useful.

So please, make your app look great.

Make cool SwiftUI interfaces.

Use AI.

I do.

Build the custom control when you actually need the custom control.

But before you replace something Apple already gives you, remember how much work is hiding underneath that boring control.

You might be replacing a lot more than you think.

Sources and further reading

• Apple Developer Documentation: Accessibility modifiers in SwiftUI

• Apple Developer Documentation: accessibilityRepresentation(representation:)

• W3C: Using ARIA - First Rule of ARIA Use

• U.S. Department of Justice: Title II web and mobile app accessibility rule

• U.S. Department of Justice: Guidance on Web Accessibility and the ADA

• European Commission: European Accessibility Act

Want me to test yours?

This is exactly why I do Taylor’s Teardowns.

Give me your app, website, web app, AI chatbot, or whatever you built. I use it the way a blind customer actually would, with a screen reader and keyboard where that applies, and I tell you where I get stuck, what happened, and what I would fix first.

A written teardown is $75 during launch pricing. The teardown with a recorded screen-reader walkthrough is $175 during launch pricing. The launch pricing is limited to the first 20 teardowns.

If you built something with AI and you are not sure what VoiceOver actually gets from all those custom controls, send it to me. I would rather help you fix the app while it has all that potential than watch a blind customer hit one control and leave.

Buy Taylor’s Teardowns: Get your teardown on Gumroad