rajathtirumangalam

Category: Breakdowns

  • When success messages don’t confirm success

    I submit a form.

    The button is activated.
    Something happens.

    But I don’t know if it worked.

    There’s no confirmation.
    Or worse, there is—but I never hear it.

    Maybe a message appeared visually.
    Maybe it was placed somewhere I’m not focused on.
    Maybe it disappeared too quickly.

    So I’m left wondering:

    Did it go through?
    Should I try again?
    Did I just submit this twice?

    Technically, the system is fine.
    The form works.
    The message exists.

    But accessibility isn’t about whether feedback exists.
    It’s about whether feedback is perceived.

    A success message should do one thing clearly:

    Remove uncertainty.

    If the user is still unsure, the system hasn’t finished its job.

    So users adapt.

    They refresh the page.
    They check emails.
    They resubmit forms just to be sure.

    Not because they want to.
    Because they have to.

    This is the gap.

    The system responds.
    But the user is left uncertain.

    And uncertainty is friction.

  • State changed. Nobody told the user.

    State changed. Nobody told the user.

    I activate something.

    Nothing happens.

    Or at least, nothing that I can perceive.

    Maybe the page updated.
    Maybe a panel opened.
    Maybe something important changed somewhere on the screen.

    But I don’t know that.

    Because nothing told me.

    Technically, the system did everything right.
    The state changed.
    The UI updated.

    But accessibility isn’t just about what changes.
    It’s about whether the user knows it changed.

    If a filter is applied, the user should know.
    If content updates, the user should know.
    If something expands, collapses, loads, or completes—the user should know.

    Without that, interaction becomes guesswork.

    So users adapt.

    They start re-reading the page.
    They move focus around.
    They try to find what changed.

    Not because they want to.
    Because they have to.

    This is the gap.

    The system responds.
    The state changes.

    But the change is silent.

    And silence, in accessibility, is failure.

  • 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.