Was gibt dir semantisches HTML, das ein div mit ARIA-Attributen nicht gibt?

Native Elemente bringen Verhalten mit, nicht nur Semantik: ein button ist fokussierbar, feuert bei Enter und Space, nimmt an Formularen teil und exponiert Rolle und Zustand gratis korrekt. Ein div mit role button bekommt das Label, aber nichts vom Verhalten, du baust also tabindex, Tastaturbehandlung und disabled-Zustand selbst, und jedes davon kann schiefgehen. Die erste ARIA-Regel lautet, ARIA nicht zu benutzen, wenn HTML den Job schon erledigt.

ARIA ändert nur, was im Accessibility-Tree exponiert wird. Es macht nichts fokussierbar, es fügt keine Tastaturbehandlung hinzu, und es verwaltet keinen Fokus. In dem Moment, in dem ich ein div mit role button schreibe, habe ich mich also für tabindex null verpflichtet, für einen Handler für Enter und Space, für einen aria-disabled-Zustand, den ich zusätzlich im Handler durchsetzen muss, und ich bekomme trotzdem kein Formular-Submit. Ein echter button gibt mir all das, und es bleibt korrekt, wenn sich der Browser ändert. Meine Voreinstellung ist deshalb nativ zuerst: button, a mit echtem href, input mit passendem Label, dialog für Modals, details für einfaches Auf- und Zuklappen. Zu ARIA greife ich, wenn es wirklich kein natives Äquivalent gibt, etwa bei einem Tab-Set oder einer Combobox, und dann folge ich dem Muster aus den Authoring Practices, statt Rollen zu improvisieren. Der Bug, den ich am häufigsten sehe, ist ein klickbares div in einer Tabellenzeile, das ein Tastaturnutzer schlicht nicht erreicht, und es besteht jeden automatischen Check, weil am Markup technisch nichts falsch ist.