Icon Button: Marmo UI vs MUI

An icon-only button looks simple until you have to get the accessibility right: it needs a label a screen reader can announce, a focus ring, and a hit target that meets 44px on touch devices even if the icon itself is 16px. Here is how Marmo UI’s Icon Button compares to MUI's.

API shape

MUI's IconButton wraps any child icon element and exposes size (small/medium/large), color, and edge props inherited from its broader Button family. It is flexible but the accessible label is opt-in — you pass aria-label yourself, and it is easy to ship an icon button with no accessible name if you forget.

Marmo UI's IconButton takes a required label prop that doubles as both the tooltip text and the aria-label, so there is no accessible-icon-button footgun by default. Icon is passed as a component reference, sizing follows Marmo's token scale (sm/md/lg) rather than free-form pixel values.

Accessibility defaults

• MUI: accessible name is opt-in via aria-label; nothing stops you from shipping unlabeled icon buttons.
• Marmo UI: label is required at the type level, so an unlabeled icon button is a compile error, not a runtime accessibility bug.
• Both meet 44px minimum hit target at default sizing; MUI requires you to verify this yourself at "small" size, Marmo enforces a minimum touch target regardless of visual icon size.

Why this matters more when an AI agent writes the code

A required label prop is a small API decision with an outsized effect once you are prompting an agent to "add a delete icon button" instead of writing it by hand. With MUI, an agent can generate a perfectly compiling, silently inaccessible button. With Marmo, the type system forces the label into existence before the code will build — one of the reasons Marmo’s MCP-connected component library exists at all: constraints that catch mistakes at generation time, not in a later audit.

See the full prop reference on the Icon Button docs page, or browse the rest of the component library.