El desarrollador Marco Campos analiza en su blog por qué resulta tan costoso —y poco recomendable— implementar un botón desde cero en la web cuando existen elementos HTML nativos. El artículo parte de dos consejos clásicos de accesibilidad: la primera regla de ARIA es no usar ARIA y, si existe un elemento nativo, conviene usarlo en lugar de reinventarlo.
Campos desgrana la larga lista de requisitos que un botón debe cumplir según las especificaciones WCAG 2.2, MDN y la Authoring Practices Guide del W3C: tener rol de botón, etiqueta accesible, ser enfocable con el teclado, activarse con ratón, táctil y puntero, responder a las teclas Espacio y Enter, participar en formularios con sus atributos name, value y type, soportar estados como disabled e integrarse con APIs modernas como Popover, Invoker Commands o Interest Invokers.
A partir de ahí, el post muestra paso a paso la construcción de un elemento personalizado bautizado : añadir role="button", label accesible mediante aria-label, marcar como presentacional un emoji usado como icono, hacerlo enfocable con tabindex="0" y gestionar eventos mouseup, touchend y pointerup para cubrir todas las modalidades de interacción. Con cada paso, Campos ilustra los problemas que surgen —desde emojis leídos literalmente por los lectores de pantalla hasta la complejidad de mapear correctamente los eventos de teclado— y concluye que reproducir a mano el comportamiento nativo es una tarea sisífea, por lo que recomienda partir siempre del elemento del estándar HTML.