Accessibility, Integration, and Failure Boundaries

Material UI’s accessibility and integration story is strongest when it is read as a set of boundaries rather than as a blanket guarantee. This chapter uses the Button conformance evidence to separate mechanical support from partial support, manual review, and author responsibility. It then traces common failures back to the layer that owns them, so a team can choose a useful follow-up test instead of adding another unsupported override.

What the Button Evidence Actually Establishes

The Button report is valuable because it does not reduce accessibility to a single pass or fail label. It evaluates a specific component, in a documented v9.x environment, against WCAG 2.2 criteria. Some results describe behavior supplied by the component itself. Other results are shared with the surrounding application or remain author decisions. The report also states that automated checks do not replace assistive-technology review. Its conclusions should therefore be read as scoped evidence about Button, not as a certificate for every Material UI component or every application that uses Button.

That scope changes how its labels should be interpreted. A supported criterion may mean that the component supplies the relevant mechanical behavior under its documented API. A partial result may identify a known combination that needs an author decision or an additional wrapper. A flagged manual item may be something that automated tooling cannot determine from markup alone. A criterion marked as an author or shared responsibility is not evidence that the component is defective; it identifies a condition controlled outside the component. Reading the categories this way prevents both overclaiming and an unhelpful reaction in which a team treats every caveat as a reason to replace the library.

The mechanically supported layer is substantial. Button renders an appropriate native or non-native role for the root it resolves, supports keyboard activation in the documented cases, removes disabled controls from normal interaction, and gives the loading indicator an accessible relationship to the Button. The component’s DOM order places the start icon, label, loading content, and end icon in a predictable sequence. Its focus-visible path distinguishes keyboard focus from ordinary pointer interaction. These are meaningful foundations because they reduce the amount of interaction machinery an application has to build itself.

But mechanical support is not the same as a complete user experience. A component can expose a role while an author gives it a vague name. It can render a loading progress indicator while the application fails to announce a background status change. It can preserve natural focus order while a surrounding layout visually reorders controls or places a focused element under a sticky header. The report treats these differences explicitly instead of assigning every responsibility to the component.

The report identifies concrete partial-support conditions. The default info and warning Button combinations have known contrast shortfalls. The report also warns that disabling ripple or focus ripple can remove the text and outlined focus indicator, while disabling elevation can remove the contained indicator in relevant combinations. These are not abstract possibilities. They are examples of a customization changing the conditions under which the component communicates state.

Loading exposes a different kind of gap. Button can render a progress indicator and disable interaction while loading, but the component does not add a live region for the change. If loading begins while focus is elsewhere, a screen-reader user may not hear that the operation has started.