MasterClassAccesibilidad — Tag button o role=”button” esa es la cuestión.

A veces me encuentro casos donde dudamos si usar el tag<button> o usar mejor el role=”button”, nos suele dar igual tirar por cualquiera de los dos pero en la mayoría de los casos no tenemos en cuenta todos los criterios importantes si usamos uno u otro.

Desde mi punto de vista, en el mundo ui-dev y de la accesibilidad Web, prefiero usar siempre el tag <button> antes que el role=”button” ya que el propio nativo del <button> contiene toda la accesibilidad y javascript disponible y el role=”button” no, hay que picarselo a mano.

No soy el único que recomiendo siempre usar el tag <button>, muchas Webs prefieren aconsejar a los lectores tanto juniors como senior en usar siempre que se pueda el nativo que adentrarse en el mundo de los role de WAI-ARIA.

developer.mozilla.org

Muchos de estos widgets se incorporaron posteriormente a HTML5, y los desarrolladores deberían preferir utilizar el elemento HTML semántico correcto en lugar de utilizar ARIA , si tal elemento existe. Por ejemplo, los elementos nativos tienen funciones, estados y accesibilidad de teclado integrados . Sin embargo, si elige utilizar ARIA, es responsable de imitar el comportamiento del navegador (el equivalente) en el script.

ARIA es un conjunto de atributos que definen formas de hacer que el contenido web y las aplicaciones web sean más accesibles para las personas con discapacidad, nos ayuda a hacer que ciertos elementos nuevos (que en nativo no se pueden hacer) puedan ser accesibles gracias a todo lo que nos da WAI-ARIA.

ARIA lo utilizaremos cuando sea necesario, cuando los propios elementos nativos de html no cubren nuestras necesidades. Como por ejemplo un componente expandable:

El componente expandable necesita WAI-ARIA para hacerlo accesible

Un componente expandable no existe tag html que lleve su propia semántica para hacer que sea accesible para los lectores de pantalla y por ello hay que aplicar ciertos atributos para que un lector de pantalla pueda leerlo correctamente.

Te incluyo un ejemplo de expandable accesible donde podrás ver el código que se emplea: https://www.w3.org/TR/wai-aria-practices-1.2/examples/accordion/accordion.html

Un primer vistazo en el código, tenemos el botón que realiza la acción de expandir o contraer:

Encontramos lo siguiente:

• aria-expanded: que puede recibir dos valores; true o false, e indicará si el contenido esta expandido o no al lector de pantalla.
• aria-controls: hace referencia a la capa que controla el button, en este caso será la capa que haga expandir o contraer. aria-controls no es muy soportado para los lectores de pantalla, pero si que se recomienda añadirlo.

Por otro lado tenemos el contenido:

Donde aplicaremos los siguientes atributos ARIA:

• role: para indicar que es una región.
• aria-labelledby: para indicar que esta región hace referencia al botón superior.

Gracias al WAI-ARIA aplicado en este componente, el lector de pantalla podrá leerlo como un componente desplegable y si se navega por landmark se podrá localizar fácilmente las regiones de la página, incluyendo el contenido desplegado.

OJO: En caso de que tengamos que mejorar la accesibilidad de una web antigua, puede que nos sirva mas usar WAI-ARIA que usar la semántica html nativa para dejarla accesible ya sea por el código antiguo, maraña de código, maraña de CSS…

Diferencias entre <button> y role=”button”

En el caso de crear un botón, tenemos dos formas de hacerlo:

• tag <button>
• role=”button”

A continuación comentaré cuales son las ventajas y desventajas de usar el tag button y el role=”button”

Ventajas del tag button

• Contiene tabulado propio: Si usamos el botón TAB para navegar por una Web, este elemento será focable para que pueda ser accionado a través de teclado.
• Contiene su propia semántica: El lector de pantalla cuando pase por encima, indicará el nombre y después su semántica: “botón”
• Contiene funcionalidad nativa de javascript: puede ser pulsable a través de la tecla “Enter” y la tecla “Barra espaciadora”
• Contiene sus propios estilos de botón: Creo que es el menos importante, las webs de hoy en día pisan estos estilos propios que da el navegador y se añaden unos nuevos. Pero, hay que recordar que a veces hay personas que cambian los estilos de la web con unos estilos mas accesibles y si es un button, se aplicaran correctamente los colores.

Desventajas del tag button

• Desde mi punto de vista, casi ninguno, excepto cuando se quiere añadir dentro del button elementos de bloque, esto hará que el validador de HTML falle.
• A veces, dependiendo del navegador, si aplicas tus propios estilos sobre el tag, vas a tener que pisar ciertos estilos que se aplican con -webkit… Te dejo un link de ejemplo de lo que hice con el input date: “Estilar un input date sin morir en el intento” hay que pisar ciertos estilos para que en todos los navegadores se vea el componente igual.

Ahora vamos con el role=”button”…

Ventajas del role button

• Soluciones amplias dependiendo de las necesidades de la aplicación. Imagina que tenemos un componente que visualmente puede actuar como un botón o cómo un elemento informativo (Dependiendo de la pantalla). Sería fácil quitar el atributo role=”button” y demás atributos si queremos que el componente sea informativo, y si queremos que sea un botón toda la caja volvemos a añadir los atributos. Así evitamos tener que hacer en el desarrollo del componente un cristo dependiendo del framework si usamos el tag button.
• Puedes aplicar el role=”button” a un div y tratarlo como elemento de bloque que pueda albergar mas elementos de bloque dentro.
• Para desarrollos antiguos donde se este aplicando malamente el CSS y no romper el layout, aplicar el role=”button” sobre los elementos necesarios.

Desventajas del role button

• Se tiene que aplicar todo lo necesario para que sea un botón frente a los lectores de pantalla.
• Hay que aplicar el tabulado, tabindex=”0”, si no se aplica, una persona con diversidad funcional que solamente pueda usar el teclado y navegue por teclado, este botón nunca será focable por el TAB. Hay que recordar que este error es muy común en el mundo front y el primer fallo de accesibilidad.
• Hay que asignar la funcionalidad correspondiente con los eventos de “Enter” y “Barra espaciadora” event.keyCode === 32 y event.keyCode === 13. Una persona que solo use el teclado para navegar por internet, si quiere pulsar un botón que lleve role=”button”, hay que darle la posibilidad de accionarlo con “Enter” y con la “Barra espaciadora”.
• Hay que tener cuidado donde aplicar el role=”button” ya que puede romper con la semántica. Ejemplo:

<ul>
    <li role="button" tabindex="0">Más información sobre la hipoteca
    </li>
</ul>

Este también es uno de los errores típicos, el atributo role rompe la semántica sobre el elemento que lo usamos para aplicar el role necesario. En el ejemplo anterior, no se debería de hacer esto ya que el <ul> solo permite elementos <li> y aquí rompemos con el marcado y la accesibilidad. Este sería el ejemplo correcto:

<ul>
    <li>
        <div role="button" tabindex="0">Más información sobre la  hipoteca
        </div>
    </li>
</ul>

Te incluyo mas información de role=”button” con ejemplos incluidos: Más información sobre role=”button”

También mas información sobre el button: Más información sobre el tag button

Espero que te haya gustado el articulo. Te incluyo mis redes sociales donde suelo compartir información sobre accesibilidad web, html, css… y si tienes alguna duda puedes contactar conmigo sin problema.

Twitter de Francisco Márquez Duro

Linkedin de Francisco Márquez Duro

¡Muchas gracias por llegar hasta aquí!