Button. Button. Button. That’s not accessibility.

I open an app and start navigating.

“Button.”
“Button.”
“Button.”

That’s all I hear.

No context.
No purpose.
No indication of what each one does.

Just… button.

Technically, everything is there.
The elements are accessible.
The screen reader is reading them.

It would probably pass an audit.

But in real use, this isn’t usable.

Because accessibility isn’t just about whether something is exposed to a screen reader.
It’s about whether a user understands what’s happening.

Every button should answer a simple question:

**What will happen if I activate this?**

If it doesn’t, the user is left guessing.

And guessing is expensive:

  • it slows people down
  • it creates hesitation
  • it breaks trust

So users adapt.

They start exploring blindly.
They activate things just to see what happens.
They backtrack.
They try again.

Not because they want to.
Because they have to.

This is the gap.

The interface responds.
The system is technically accessible.
But the interaction still fails.

Because the system speaks…
but it doesn’t communicate.

That’s not accessibility.

That’s noise.

Comments

One response to “Button. Button. Button. That’s not accessibility.”

  1. a11yDetector Avatar
    a11yDetector

    If a button only tells you it’s a button, it hasn’t told you anything useful.

    Accessibility isn’t about announcing elements.
    It’s about communicating intent.

Leave a Reply to a11yDetector Cancel reply

Your email address will not be published. Required fields are marked *