Pruebas de accesibilidad

En la aplicación Jutro, probamos la accesibilidad (a11y) con la biblioteca jest-axe que está encapsulada en una función llamada checkA11yViolations. En ese sentido, tratamos las pruebas de a11y como una forma de prueba unitaria.

¿Qué abarca jest-axe?

La biblioteca jest-axe no abarca todos los requisitos de las Pautas de accesibilidad al contenido web (WCAG), sino que comprueba posibles infracciones que se pueden verificar con automatización. Por lo tanto, abarca un subconjunto de requisitos de WCAG.

Como indica la biblioteca jest-axe, estas pruebas no garantizan que su aplicación sea totalmente accesible. Esta biblioteca solo analiza el marcado y encuentra problemas en ese contexto.

¿Para qué se ejecutan pruebas en páginas?

Ejecutamos la prueba en una página completamente renderizada. Esto logra un equilibrio entre la cobertura y la carga de trabajo. La ejecución de la prueba en un componente individual podría pasar por alto algunos problemas que solo aparecen en contexto.

Por ejemplo, el contenido de un componente con un fondo transparente puede volverse ilegible cuando aparece encima de un componente con un fondo de color.

Por otro lado, escribir pruebas de a11y para cada estado posible de cada componente implicaría mucho trabajo adicional que probablemente no sea necesario.

¿Eso garantiza que mi aplicación sea totalmente accesible?

Las pruebas automatizadas no garantizan que su aplicación sea accesible. Le recomendamos encarecidamente que realice pruebas manuales de teclado con y sin lector de pantalla. Esta es la única manera de aumentar la confianza en la calidad accesible de la página completamente renderizada.

Además, si implementa muchas animaciones personalizadas u otro comportamiento impredecible, considere escribir pruebas para cubrir algunos casos adicionales.

Cómo se debe escribir pruebas de accesibilidad

Note: Cuando prueba componentes de página en la aplicación Jutro, los componentes deben estar encapsulados en una etiqueta main, de lo contrario se infringe esta regla. En una aplicación Jutro típica, las páginas se renderizan en un AppFloorPlan que las encapsula en main, para no infringir la regla. En el siguiente ejemplo, se muestra cómo hacerlo manualmente.

import { checkA11yViolations } from '@jutro/test';

it('has no a11y violations', async () => {
  checkA11yViolations(
    <main>
      <CodelessForm />
    </main>
  );
});

Si la prueba detecta alguna infracción, la imprime en la consola, junto con un enlace para obtener más explicaciones. Por ejemplo:

Personalización de pruebas jest-axe

jest-axe es personalizable, por ello, puede deshabilitar algunas verificaciones (global o localmente) y agregar otras personalizadas. Para ello, importe y utilice las utilidades directamente desde jest-axe.

Encontrará más información en la documentación de jest-axe.

Pruebas a un botón deshabilitado

Desde la perspectiva de la accesibilidad, el usuario tiene que poder llegar a un botón a través de la tabulación, incluso si está deshabilitado. Esto ayuda al usuario a ver que hay un botón para hacer clic una vez que se cumplan todas las condiciones, por ejemplo, una vez que se complete el formulario.

Tenga en cuenta que un botón de Jutro deshabilitado no le indica al usuario cuáles son las condiciones para habilitarlo. Todo lo que el usuario sabe es que el botón está “atenuado” (en el sistema operativo Mac), o algo similar a ese efecto. Sugerimos aquí que el usuario puede inferir que se deben cumplir algunas condiciones.

Por ejemplo, supongamos que tiene el siguiente componente que contiene tres botones:

export default function ActionBar() {
  return (
    <>
      <Button>First button</Button>
      <Button>Second button</Button>
      <Button disabled>Third button (disabled)</Button>
    </>
  );
}

Para probar esto, debe simular la configuración que permite el desplazamiento con el tabulador a los botones deshabilitados.

Agregue el siguiente archivo como src/__mocks__/@jutro/config.js. Esto le permite usar botones deshabilitados en las pruebas de Jest.

src/__mocks__/@jutro/config.js

const actual = jest.requireActual('@jutro/config');

module.exports = {
  ...actual,
  getConfigValue: (path, defaultValue) => {
    if (
      path === 'accessibleDisabled.all' ||
      path === 'accessibleDisabled.button'
    ) {
      return true;
    }

    return actual.getConfigValue(path, defaultValue);
  },
};

A continuación, escriba la siguiente prueba:

import { render, screen } from '@jutro/test';
import userEvent from '@testing-library/user-event';
import ActionBar from 'components/ActionBar/ActionBar';

describe('Action Bar', () => {
  it('disabled button is not skipped when tabbing', async () => {
    render(<ActionBar />);
    const [firstButton, secondButton, disabledButton] =
      screen.getAllByRole('button');
    firstButton.focus();
    await userEvent.tab();
    expect(secondButton).toHaveFocus();
    await userEvent.tab();
    //after focusing on first button and pressing tab two times,
    // the last button (the disabled one) receives the focus
    expect(disabledButton).toHaveFocus();
  });
});