Lista de comprobación de accesibilidad para webs corporativas: empleo, PDF, inversores y formularios

Accesibilidad en webs corporativas: navegación, empleo y candidaturas, PDF e informes anuales, vídeo, formularios, banners de cookies y declaraciones.

Equipo editorial de FixReports9 min de lectura

Una web corporativa rara vez vende algo directamente, así que es fácil pasar por alto sus problemas de accesibilidad. Pero es donde la gente se presenta a ofertas de empleo, los inversores leen los informes anuales, los periodistas encuentran las notas de prensa y los clientes buscan los datos de contacto, y cada una de esas tareas puede quedar bloqueada por una barrera: una candidatura que no se puede completar con el teclado, un informe anual publicado como un PDF sin etiquetar, un vídeo sin subtítulos o un banner de cookies que atrapa el foco. Esta lista de comprobación recorre el nivel AA de WCAG 2.2 según las secciones que tienen la mayoría de las webs corporativas, con lo que hay que comprobar en cada una.

Puntos clave

  • WebAIM encontró fallos de WCAG detectables en el 95,9 % del millón de páginas de inicio más visitadas en 2026; el texto con poco contraste (83,9 %) y la falta de texto alternativo (53,1 %) fueron los más comunes (WebAIM (se abre en una pestaña nueva)).
  • WCAG se aplica tanto a las páginas web como a los documentos publicados en una web, como los PDF; el W3C publica técnicas para hacer accesibles los PDF (W3C (se abre en una pestaña nueva)).
  • El vídeo pregrabado necesita subtítulos (1.2.2, nivel A) y audiodescripción cuando las imágenes transmiten información que no está en el audio (1.2.5, AA) (W3C (se abre en una pestaña nueva)).
  • En unas orientaciones de 2022, el Departamento de Justicia de Estados Unidos afirmó que la ADA se aplica a la oferta web de las empresas abiertas al público, sin fijar una norma técnica concreta (ADA.gov (se abre en una pestaña nueva)).
  • El W3C ofrece orientaciones y un generador gratuito para redactar una declaración de accesibilidad (W3C (se abre en una pestaña nueva)).

¿Por qué importa la accesibilidad en una web corporativa?

Porque las personas que dependen de ella suelen ser precisamente las que más te interesa alcanzar: candidatos, clientes, socios e inversores. La Organización Mundial de la Salud calcula que 1300 millones de personas, aproximadamente una de cada seis, tienen una discapacidad importante (OMS (se abre en una pestaña nueva)). Muchas más usan el teclado en lugar del ratón, amplían el texto o leen en el móvil con mucha luz.

También hay una cuestión de cumplimiento normativo, que varía según el país y según a quién se dirige la web. Los organismos del sector público de la UE deben cumplir la Directiva sobre accesibilidad web; las empresas que venden a consumidores de la UE pueden estar sujetas a la Ley Europea de Accesibilidad; en Estados Unidos, el Departamento de Justicia ha afirmado que la ADA se aplica a la oferta web de las empresas abiertas al público (ADA.gov (se abre en una pestaña nueva)). Una web dirigida exclusivamente a otras empresas puede quedar fuera de algunas de estas leyes, pero los clientes grandes preguntan cada vez más a sus proveedores por la accesibilidad. Nuestras guías sobre la Ley Europea de Accesibilidad y las cartas de reclamación ADA explican el contexto; esto no es asesoramiento jurídico.

¿Qué hay que comprobar en todas las páginas?

Estos problemas proceden de las plantillas compartidas, así que corregirlos una vez corrige toda la web:

  • Contraste: el texto del cuerpo, al menos 4.5:1 frente a su fondo, y el texto grande, 3:1 (1.4.3). El texto gris claro y el texto blanco sobre los colores de la marca son los fallos habituales. El validador de contraste de color prueba cualquier par de colores.
  • Teclado: todos los enlaces, menús y botones deben poder alcanzarse con Tab y usarse con Intro o con la barra espaciadora, con un indicador de foco visible (2.1.1, 2.4.7). Los megamenús y los carruseles son problemas frecuentes.
  • Enlace para saltar al contenido y regiones de referencia: una forma de saltar el encabezado e ir al contenido principal (2.4.1), y las regiones header, nav, main y footer.
  • Encabezados: un H1 por página y una estructura de encabezados lógica (1.3.1), para que las personas que usan lectores de pantalla puedan recorrer la página.
  • Texto de los enlaces: enlaces que se entiendan fuera de contexto, no «Leer más» repetido diez veces (2.4.4).
  • Idioma: el atributo lang en todas las páginas, y en los fragmentos en otro idioma (3.1.1, 3.1.2), para que los lectores de pantalla los pronuncien correctamente.
  • Zoom y reajuste del contenido: contenido utilizable con un zoom del 200 % y con 320 píxeles de ancho sin desplazamiento horizontal (1.4.4, 1.4.10).

¿Cómo se hacen accesibles las páginas de empleo y las candidaturas?

La sección de empleo es donde las barreras tienen las consecuencias más claras: un candidato que no puede completar una candidatura no puede ser tenido en cuenta.

  • Ofertas de empleo: los filtros y la búsqueda deben funcionar con el teclado y anunciar a los lectores de pantalla el número de resultados (4.1.3).
  • Formularios de candidatura: cada campo necesita una etiqueta visible (3.3.2), los errores deben describirse con texto (3.3.1) y los botones para subir archivos deben tener nombres accesibles.
  • Límites de tiempo: si el formulario caduca, avisa a la persona y permítele ampliar el tiempo (2.2.1).
  • Sistemas de seguimiento de candidatos de terceros: muchas empresas usan un sistema externo para las candidaturas. Pide al proveedor su informe de conformidad de accesibilidad (ACR), prueba tú mismo el proceso de candidatura con el teclado y ofrece una forma alternativa de presentarse, como el correo electrónico, indicada en la página de empleo.
  • Pruebas de evaluación y entrevistas en vídeo: comprueba que cualquier prueba online o herramienta de entrevistas en vídeo sea compatible con lectores de pantalla, ofrezca subtítulos y permita más tiempo cuando se solicite.

¿Cómo se publican PDF e informes anuales accesibles?

Los informes anuales, los informes de sostenibilidad, los folletos y los documentos de políticas a menudo se publican solo en PDF, y muchos están sin etiquetar: un lector de pantalla los lee como un único bloque de texto, o no los lee en absoluto.

  • Da preferencia al HTML para el contenido importante. Una página web es más fácil de hacer accesible, funciona mejor en el móvil y es más fácil de buscar.
  • Si publicas un PDF, etiquétalo. Expórtalo desde el documento de origen (Word, InDesign) con las etiquetas activadas, para que se conserven los encabezados, las listas, las tablas y el orden de lectura. La norma PDF/UA (ISO 14289) define los PDF accesibles.
  • Comprueba lo esencial: un título del documento, el idioma del documento, texto alternativo para gráficos e imágenes, encabezados de tabla reales y un orden de lectura lógico. Adobe Acrobat Pro incluye un comprobador de accesibilidad; PAC es un comprobador gratuito para Windows.
  • Los documentos escaneados son imágenes de texto y necesitan OCR y etiquetado, o una versión en HTML.
  • Tablas financieras: marca las filas y columnas de encabezado; en HTML, usa <th> con scope.

¿Y los vídeos, los webcasts y los pódcasts?

  • Subtítulos para todo el vídeo pregrabado con voz (1.2.2, A) y para los webcasts en directo (1.2.4, AA). Los subtítulos automáticos hay que revisarlos: los nombres, las cifras y los términos técnicos suelen salir mal.
  • Audiodescripción cuando hay información importante que solo es visual, como el texto de las diapositivas que el ponente no lee en voz alta (1.2.5, AA). A menudo la solución más sencilla es que el ponente describa la diapositiva.
  • Transcripciones para los pódcasts y el contenido solo de audio (1.2.1, A).
  • Controles del reproductor: un reproductor incrustado debe poder manejarse con el teclado, y el sonido que se reproduce automáticamente durante más de tres segundos necesita una forma de pausarlo o detenerlo (1.4.2).

La guía del W3C para hacer accesibles el audio y el vídeo cubre la planificación, los subtítulos y la descripción (W3C (se abre en una pestaña nueva)).

¿Cómo se hacen accesibles los formularios de contacto, los mapas y las ubicaciones?

  • Formularios: etiquetas, mensajes de error claros y ningún CAPTCHA que dependa solo de leer texto distorsionado o de resolver rompecabezas; ofrece una alternativa (W3C (se abre en una pestaña nueva)).
  • Datos de contacto en texto: los números de teléfono, las direcciones de correo electrónico y las direcciones de las oficinas escritos en la página, no solo en una imagen o en un mapa.
  • Mapas: un mapa incrustado es difícil de usar con un lector de pantalla; la dirección y las indicaciones en texto son la alternativa accesible.
  • Widgets de chat: comprueba que se pueden abrir, usar y cerrar con el teclado, y que no tapan el contenido que tiene el foco (2.4.11).

¿Los banners de cookies causan problemas de accesibilidad?

A menudo, porque aparecen los primeros y se sitúan encima de todo lo demás.

  • El banner debe poder alcanzarse y usarse con el teclado, y Tab debe poder salir de él (2.1.2, Sin trampas para el foco del teclado) (W3C (se abre en una pestaña nueva)).
  • Sus botones necesitan nombres claros y un contraste suficiente; «Rechazar» debe ser tan fácil de encontrar como «Aceptar».
  • No debe ocultar tras él el elemento de la página que tiene el foco (2.4.11).

Nuestros análisis empiezan en tu página de inicio con el banner de cookies todavía visible, porque es lo primero que encuentra un usuario de teclado, e informan de una trampa de foco si Tab no consigue salir de él.

¿Necesitas una declaración de accesibilidad?

Los organismos del sector público de la UE deben publicar una. Para las empresas suele ser voluntaria, aunque la Ley Europea de Accesibilidad exige que los servicios incluidos en su ámbito informen de cómo cumplen sus requisitos. Una buena declaración indica a qué norma aspiras, las limitaciones conocidas, cómo puede la gente informar de un problema o pedir el contenido en otro formato, y cuándo se revisó por última vez. El W3C publica orientaciones y un generador gratuito (W3C (se abre en una pestaña nueva)).

Redáctala con honestidad: afirmar un cumplimiento total después de un análisis automatizado es un riesgo en sí mismo, porque las pruebas automatizadas no pueden comprobarlo todo.

¿Cómo se prueba una web corporativa?

  1. Haz un análisis automatizado de la página de inicio, una página de empleo, una noticia, la página de contacto y cualquier formulario. Nuestro validador de accesibilidad gratuito prueba las páginas clave en un navegador real según WCAG 2.2 A y AA, y el analizador de texto alternativo enumera todas las imágenes de una página.
  2. Prueba con el teclado: recorre el menú, preséntate a una oferta de empleo y envía el formulario de contacto usando solo el teclado.
  3. Revisa los documentos: abre tus PDF más importantes con un lector de pantalla o con un comprobador de accesibilidad de PDF.
  4. Mira tus vídeos con los subtítulos activados y el sonido apagado.
  5. Pide a personas con discapacidad que prueben las tareas clave; así aparecen problemas que ninguna lista de comprobación prevé.

Preguntas frecuentes

¿WCAG se aplica a los PDF?

Sí. WCAG se aplica al contenido web, incluidos los documentos publicados en una web. El W3C publica técnicas específicas para cumplir WCAG en archivos PDF.

Nuestra web de empleo la gestiona un tercero. ¿Es responsabilidad nuestra?

Desde el punto de vista del candidato, es tu proceso de selección. Pide al proveedor un informe de conformidad de accesibilidad, prueba el proceso y ofrece una forma alternativa de presentarse. Que tengas o no una responsabilidad legal depende de tu jurisdicción.

¿Los subtítulos automáticos cumplen WCAG?

Solo si son exactos. Los subtítulos automáticos suelen equivocarse con los nombres, las cifras y los términos; revísalos y corrígelos antes de confiar en ellos.

¿Basta con un overlay de accesibilidad en una web corporativa?

No. Los overlays no corrigen el código subyacente, los documentos ni los vídeos. Consulta nuestra guía sobre los overlays de accesibilidad y la orden de la FTC.

¿A qué norma debería aspirar una web corporativa?

WCAG 2.2 nivel AA es la versión vigente y el objetivo habitual; muchas leyes y políticas siguen remitiéndose a WCAG 2.1 AA, que una web que cumple 2.2 AA también cumple.

Fuentes

Todas las guías