Los elementos nativos traen comportamiento además de semántica: un button es enfocable, se dispara con Enter y espacio, participa en formularios y expone el rol y el estado correctos gratis. Un div con role button obtiene la etiqueta pero nada del comportamiento, así que tienes que añadir tú tabindex, gestión de teclado y estado deshabilitado, y cada uno puede salir mal. La primera regla de ARIA es no usar ARIA cuando el HTML ya hace el trabajo.
Por qué lo preguntan los entrevistadores
Las preguntas de accesibilidad separan a quien pasó una auditoría automática una vez de quien construye de verdad componentes usables. El entrevistador quiere oír que ARIA cambia lo que se anuncia pero nunca añade comportamiento de teclado ni gestión de foco. Nombrar un caso real, como un botón falso al que no se puede llegar con el teclado, demuestra que has probado con teclado o con lector de pantalla en vez de fiarte de un Lighthouse en verde.
Cómo estructurar tu respuesta
- Enuncia la separación: lo nativo da semántica más comportamiento, ARIA solo reetiqueta.
- Enumera lo que tienes que reimplementar cuando usas un div.
- Cita la regla de no usar ARIA cuando existe HTML.
- Da un ejemplo donde un elemento nativo te ahorró trabajo real.
Ejemplo de respuesta
ARIA solo cambia lo que se expone al árbol de accesibilidad. No hace nada enfocable, no añade gestión de teclado y no gestiona el foco. Así que en cuanto escribo un div con role button me he apuntado a un tabindex cero, un manejador de Enter y espacio, un estado aria disabled que además tengo que hacer cumplir en el manejador, y aun así no obtengo el envío del formulario. Un button de verdad me da todo eso y sigue siendo correcto cuando el navegador cambia. Así que mi opción por defecto es lo nativo primero: button, a con un href real, input con su label correspondiente, dialog para modales, details para un desplegable simple. Recurro a ARIA cuando de verdad no hay equivalente nativo, como un conjunto de pestañas o un combobox, y entonces sigo el patrón de las prácticas de autoría en vez de improvisar roles. El bug que más veo es un div clicable dentro de una fila de tabla al que un usuario de teclado simplemente no puede llegar, y pasa todas las comprobaciones automáticas porque técnicamente nada del marcado está mal.
¿Tienes esta entrevista a la vuelta de la esquina? GhostPilot escucha tu llamada en vivo, detecta la pregunta en cuanto la hacen y pone una respuesta estructurada en tu pantalla en tiempo real. Pruébalo en tu próxima entrevista de práctica, o coge un Session Pass de $29, sin suscripción, para la de verdad.
Mira cómo funcionaPreguntas de seguimiento que puedes esperar
- ¿Cómo harías accesible por teclado un componente de pestañas propio?
- ¿Qué hace aria hidden y cuándo causa daño?
- ¿Cómo pruebas esto más allá de pasar un escáner automático?
Más preguntas para Desarrollador frontend
Tu entrevistador hará su propia versión de esta. Pega la descripción real del puesto en el Question Predictor gratuito y obtén las 20 preguntas que ese puesto tiene más probabilidades de hacerte, con lo que cada una busca en realidad.
Predecir mis preguntas