Informe de Accesibilidad Web

Compatibilidad con Lectores de Pantalla (Semántica HTML y ARIA)

El sitio embalajesmc.es presenta una estructura HTML mayormente semántica, lo cual beneficia a los usuarios de lectores de pantalla. Se observa la presencia de un enlace de “Saltar al contenido”, una práctica recomendable que permite a quienes navegan con teclado o lectores de pantalla ir directamente al contenido principal sin repetición de menús . Asimismo, se utilizan encabezados HTML (como <h1> para el título principal y <h2> para secciones) de forma adecuada en la mayoría de los casos, ayudando a estructurar la información de manera lógica y jerárquica . Esto facilita que un usuario con lector de pantalla entienda la organización de la página y navegue por secciones fácilmente.

No obstante, la compatibilidad con lectores de pantalla podría mejorarse en ciertos aspectos técnicos. Por ejemplo, no se evidencian atributos ARIA (Accessible Rich Internet Applications) en elementos interactivos como el menú de navegación desplegable. El botón de menú “hamburguesa” (identificado como “Menú/Cerrar”) debería tener atributos ARIA apropiados (p. ej. aria-label="Abrir menú" / aria-expanded) para informar su función y estado a las tecnologías de asistencia. Actualmente, la página parece confiar solo en texto y comportamiento por defecto, sin roles explícitos para elementos dinámicos. Aunque HTML5 ofrece elementos semánticos (como <nav>, <header>, <main> etc.) con roles implícitos, la ausencia de roles ARIA explícitos no es en sí un error si se usa HTML semántico correctamente . De hecho, la primera regla de ARIA es usar HTML nativo siempre que sea posible en lugar de añadir ARIA innecesario . Sin embargo, en componentes como el menú móvil, añadir un atributo aria-label o usar un elemento <button> con etiqueta visible “Menú” podría brindar una mejor experiencia a usuarios de lector de pantalla, asegurando que el propósito del control esté claro. En resumen, el sitio funciona con lectores de pantalla en lo básico, gracias a su estructura semántica y texto descriptivo, pero carece de mejoras ARIA que podrían hacerlo más intuitivo en elementos interactivos (por ejemplo, indicar expansiones de menú o estados dinámicos).

Contraste de Colores y Legibilidad Visual

En términos de diseño visual, la página utiliza textos predominantemente negros o oscuros sobre fondos blancos o claros, lo que en principio proporciona buena legibilidad. Los tamaños de fuente parecen adecuados y la tipografía es legible. No obstante, es fundamental verificar que todas las combinaciones de colores cumplan con el contraste mínimo requerido por las pautas de accesibilidad. La norma WCAG 2.1 (nivel AA) exige un contraste mínimo de 4.5:1 entre el texto y su fondo para texto normal (y al menos 3:1 para texto grande, como títulos) . Sería recomendable analizar elementos como texto sobre imágenes o botones con color de fondo para confirmar que mantienen ese nivel de contraste.

Por ejemplo, si el encabezado principal “Suministro de Palets y Embalajes” estuviera sobrepuesto a una imagen de fondo, habría que asegurar que el color del texto destaque suficientemente sobre la imagen. Si actualmente algún texto (especialmente enlaces o botones sobre fondos de color) presenta contraste bajo, se sugiere ajustar los colores – ya sea oscureciendo el texto o aclarando el fondo – hasta alcanzar o exceder la proporción 4.5:1. Un buen contraste beneficia a todos los usuarios, especialmente a personas con visión reducida o daltonismo, garantizando que el contenido sea fácilmente distinguible y legible en diversas condiciones . En resumen, el sitio parece generalmente legible, pero conviene auditar el contraste de color en todos los componentes clave (textos, iconos, fondos) para confirmar el cumplimiento con WCAG 2.1 nivel AA.

Navegación Accesible por Teclado

Un principio básico de la accesibilidad es que toda la funcionalidad de la página debe ser operable usando únicamente un teclado . En embalajesmc.es la navegación principal y los enlaces del sitio son accesibles mediante tabulación: los elementos del menú (Soluciones, Productos, Contacto, etc.) son enlaces HTML tradicionales que se pueden enfocar y activar con teclado (tecla Tab para moverse y Enter para activar). La presencia del enlace “Saltar al contenido” al inicio de la página es un punto positivo, pues permite a un usuario de teclado saltar directamente a la sección principal, evitando tener que tabular por todo el menú en cada página .

Sin embargo, hay áreas a mejorar para una mejor experiencia “sin ratón”. El menú desplegable móvil (el ícono o botón de “Menú”) debe ser accesible y operable vía teclado. Actualmente, si es un elemento <a> o similar con control JavaScript, habría que garantizar que al recibir foco pueda activarse con Enter o Espacio, y que al abrirse el menú, los enlaces internos sean navegables con Tab. No se observan indicadores de foco personalizados; es importante que los elementos enfocables (links, botones, campos de formulario) tengan un estilo visible al recibir foco – por ejemplo un borde o resaltado – para que el usuario teclado sepa qué elemento está activo . Si este estilo no está definido, confiar en el indicador por defecto del navegador (que suele ser un contorno azul) podría ser suficiente, pero es mejor asegurarlo vía CSS. Por último, conviene probar que no existan “trampas de teclado”: es decir, que ningún componente (como un video emergente o formulario) atrape el foco impidiendo salir. En general, el sitio permite la navegación por teclado en su contenido estático sin problemas severos, pero se recomienda probar exhaustivamente todos los controles interactivos (menú móvil, formulario de contacto, enlaces de idioma) solo con teclado, garantizando que el orden de tabulación sea lógico y que todas las funciones sean accesibles de esta forma .

Cumplimiento de WCAG 2.1 (Niveles A y AA)

De manera general, embalajesmc.es cumple parcialmente con varios de los criterios de éxito de WCAG 2.1 nivel A y AA, pero no alcanza todavía una conformidad plena en todos ellos. A continuación, se resumen los hallazgos en relación con los principales requisitos:

Texto Alternativo (WCAG 1.1.1 – Nivel A): El sitio contiene múltiples imágenes informativas (fotografías de palets, iconografía de servicios, etc.) que no cuentan con descripciones alternativas adecuadas. Todas las imágenes deberían tener un atributo alt que describa brevemente su contenido o función . En este caso, algunas imágenes parecen llevar texto alternativo genérico (e.g. “Embalajes MC”) o podrían carecer de alt descriptivo, lo cual no satisface el criterio 1.1.1. Esto impide que usuarios ciegos obtengan la información transmitida visualmente por esas imágenes.
Estructura y Relaciones (WCAG 1.3.1 – Nivel A): Como mencionado, la página utiliza encabezados y listas correctamente para estructurar la información, cumpliendo en buena medida con este criterio. Un detalle a verificar es la jerarquía de encabezados: existe un caso de un subtítulo <h3> (“Si quieres más información… contáctanos”) inmediatamente después de un <h2> sin una clara sección padre, pero en general la estructura es coherente y transmite relaciones correctamente. Asimismo, listas de enlaces (p. ej. el menú principal) parecen implementadas con elementos de lista reales, lo cual es correcto semánticamente.
Navegación por Teclado (WCAG 2.1.1 – Nivel A): Como se analizó, la funcionalidad básica es operable por teclado, pero debe mejorarse la accesibilidad del menú desplegable y asegurarse de que ningún elemento requiera obligatoriamente mouse (por ejemplo, efectos hover que no tengan alternativa al foco por teclado). Este criterio se cumple parcialmente; no hay secciones inaccesibles por teclado, pero la usabilidad podría ser más óptima.
Contraste (WCAG 1.4.3 – Nivel AA): A falta de mediciones concretas de color, presumiblemente la mayoría del texto cumple el contraste mínimo (negro sobre blanco). Debe confirmarse cada combinación (como textos superpuestos en imágenes, botones con fondo de color, texto sobre banners) para garantizar la relación de contraste de 4.5:1 . Si algún elemento no la cumple, estaría en incumplimiento del nivel AA.
Identificación de Errores y Etiquetas (WCAG 3.3.1 y 3.3.2 – Niveles A/AA): El formulario de contacto tiene campos obligatorios marcados con “*” y un aviso legal a aceptar. Sin embargo, para cumplir estos criterios:
- Cada campo debe tener una etiqueta claramente asociada (mediante <label> explícito o texto asociado programáticamente) . Los textos “Nombre”, “Email”, etc., parecen actuar como etiquetas visibles, pero habría que confirmar si están correctamente vinculados a sus campos de entrada (p. ej. usando for en <label>).
- En caso de error (por ejemplo, si “Email” no tiene el formato correcto), el sitio debería proporcionar un mensaje de error claro y asociado al campo correspondiente. No pudimos comprobar la validación ya que el formulario requiere JavaScript activo, pero es importante que cualquier mensaje de error sea accesible (legible por lectores de pantalla y con un texto descriptivo).
- El sitio informa al usuario sin JS que debe activarlo para enviar el formulario, lo cual es problemático. Aunque WCAG no prohíbe usar JavaScript, sí exige que la ayuda y las instrucciones estén disponibles (criterio 3.3.2). Sería preferible proveer una vía de contacto alternativa (como un correo directo) para usuarios que no puedan usar el formulario por la razón que sea.
Accesibilidad Móvil (varios criterios de nivel A/AA): Muchas de las mejoras introducidas en WCAG 2.1 se enfocan en accesibilidad desde dispositivos móviles y para usuarios con baja visión o discapacidades cognitivas . El sitio es responsive y puede adaptarse a pantallas pequeñas, pero se deben considerar aspectos como: que el contenido se pueda hacer zoom y refluya sin pérdida de funcionalidad (1.4.10 – Reajuste de texto, nivel AA), que los botones o enlaces tengan tamaño táctil adecuado, y que no haya gestos complejos obligatorios (2.5.1 – Gestos del puntero, nivel A). En las pruebas básicas, embalajesmc.es se visualiza correctamente en móvil y la navegación principal cambia a un menú de tipo hamburguesa (lo cual es común). Para cumplir plenamente con WCAG 2.1 en móvil, debe verificarse que ese menú y todos los controles (p. ej. el selector de idioma) sean operables con toques sencillos y tengan áreas táctiles suficientemente grandes.

En síntesis, el sitio embalajesmc.es demuestra conciencia parcial de la accesibilidad (incluyendo elementos como la estructura semántica y la opción de saltar contenido), pero aún no alcanza una conformidad completa nivel AA debido a detalles pendientes en alternativas textuales, optimización para lector de pantalla/teclado y potencialmente contraste y formularios. Se recomienda abordar estos puntos para avanzar hacia el cumplimiento pleno de WCAG 2.1 A/AA, lo cual además de favorecer a usuarios con discapacidad, mejorará la usabilidad general.

Accesibilidad en Móviles y Dispositivos Táctiles

Hoy en día, la accesibilidad móvil es un componente integral de la accesibilidad web. El sitio embalajesmc.es parece contar con un diseño adaptable (responsive), presentando su contenido de forma adecuada en pantallas pequeñas. El menú de navegación se transforma en un ícono de menú (hamburguesa) en móvil, y la estructura de la página se reorganiza en una sola columna, lo cual es correcto. Para los usuarios que navegan mediante pantallas táctiles, es importante que todos los elementos interactivos tengan un tamaño y separación suficientes para pulsarlos con facilidad. En este sentido, los botones y enlaces del sitio (ej. “Enviar” del formulario, o los links de idioma “Español | Català | English…”) deben ser lo bastante grandes y estar bien espaciados. Aunque WCAG 2.1 no fija un tamaño mínimo obligatorio en nivel AA, se suele recomendar una dimensión táctil de alrededor de 44×44 píxeles para objetivos táctiles, a fin de minimizar errores de selección.

Otro aspecto a considerar es la orientación y zoom. El contenido debe poder visualizarse tanto en orientación vertical como apaisada sin perder información o funcionalidad (criterio 1.3.4 de WCAG 2.1, nivel AA). De igual forma, usuarios deben poder ampliar el texto (zoom del navegador hasta 200%) sin que el contenido se rompa o quede inaccesible (criterio 1.4.10, nivel AA). Sería prudente probar la página en distintos dispositivos móviles y tablets, asegurando que no aparezcan barras de desplazamiento horizontal inesperadas ni elementos superpuestos. Por ejemplo, comprobar que el formulario de contacto y la tabla de productos (si existe) se ajustan bien a pantallas pequeñas. Además, todas las funciones disponibles en escritorio deberían ser operables en móvil: esto incluye desplegar el menú, cambiar de idioma, reproducir cualquier vídeo o carrusel, etc., sin depender de efectos de “hover” (pasar el ratón) ya que en pantallas táctiles no existe dicha interacción. En general, embalajesmc.es parece haber sido diseñado pensando en la compatibilidad móvil, pero una revisión específica con respecto a criterios móviles de WCAG 2.1 (como gestos, orientación, reflujo de contenido, uso de sensores, etc.) garantizará que la experiencia móvil sea completamente accesible .

Estructura: Encabezados, Enlaces, Formularios e Imágenes (Texto Alternativo)

La estructura del contenido de embalajesmc.es es clara y relativamente bien organizada. Se utiliza un único encabezado <h1> en la página de inicio (“Suministro de Palets y Embalajes”), que establece el tema principal. Los subsecciones están marcadas con encabezados <h2> descriptivos (por ejemplo, “Nuestros Servicios”, “Introducción”, “Recogida y Compra de palets Usados”, etc.), lo cual es apropiado para delinear secciones de contenido. Incluso se encuentra un encabezado <h3> para introducir la sección de contacto (“Si quieres más información… contáctanos”), que aunque podría ser un <h2> nuevo, sigue proporcionando una jerarquía accesible. Mantener una jerarquía lógica de encabezados es importante para que los usuarios (y las tecnologías de asistencia) puedan entender la relación entre secciones . En este aspecto, sugerimos asegurar que no se salten niveles de encabezado injustificadamente y que cada sección tenga un título adecuado que la describa.

En cuanto a enlaces, la mayoría son claramente identificables por su texto. Los elementos del menú (“Soluciones”, “Productos”, etc.) y otros enlaces como “políticas de privacidad” poseen textos autoexplicativos. No se aprecian enlaces con texto genérico como “clic aquí”, lo cual es positivo. También es bueno que los enlaces cambien de estilo al pasar el foco o el puntero (p. ej., subrayado o color) para indicar interactividad, aunque habría que confirmar este estilo. Un punto de mejora es verificar que los enlaces que abren contenido externo (como el de diseño web actual.cat) tengan indicación apropiada o se manejen de forma consistente para no confundir al usuario; si bien esto es más una recomendación de usabilidad que un requisito WCAG estricto.

Los formularios requieren atención especial. En la página de inicio se incluye un pequeño formulario de contacto con campos de entrada (Nombre, Teléfono, Email, Asunto, Comentarios) y un botón Enviar, además de la casilla de aceptación de políticas. Para ser accesible:

Cada campo de entrada debe tener una etiqueta asociada visible (o no visible pero legible por screen reader) que indique qué dato se espera . En el código, esto suele lograrse con <label for="campo">Texto de la etiqueta</label> y un id correspondiente en el <input>. Si actualmente solo se muestra el texto cerca del campo sin una asociación explícita, habría que corregirlo.
Marcar los campos obligatorios claramente. El asterisco (*) se emplea para denotar obligatoriedad, pero convendría añadir, por ejemplo, aria-required="true" o usar la propiedad HTML required en esos campos para que los lectores de pantalla anuncien que son obligatorios.
Asegurar que al presentarse mensajes de error o confirmación, estos sean anunciados a usuarios con lector de pantalla. Por ejemplo, si el formulario se envía sin rellenar, debería aparecer un aviso (y ojalá el foco se lleve a él) indicando qué falta. Estos avisos deben insertarse en el código de manera que tengan foco o un role="alert" para ser detectados por tecnologías de asistencia.
El mensaje actual “Por favor, activa JavaScript en tu navegador para completar este formulario” sugiere que sin JS el formulario no funciona. Esto es problemático: siempre que sea posible, el formulario debería poder enviarse con un método alternativo no dependiente de JavaScript (por ejemplo, mediante un envío estándar HTML). Si la dependencia de JS es por un motivo concreto (validación en cliente o protección antispam), al menos proporcionar un contacto alternativo (email o teléfono, los cuales afortunadamente están listados en la sección de contacto) mitiga la barrera.

Finalmente, respecto a las imágenes y texto alternativo: El sitio hace uso abundante de imágenes ilustrativas (fotografías de palets, iconos de servicios, logotipos, etc.). Según las pautas, toda imagen informativa debe tener un texto alternativo equivalente que transmita su significado . Si una imagen es meramente decorativa, entonces debe llevar alt="" (alt vacío) para que el lector de pantalla la ignore . En nuestra revisión, encontramos que varias imágenes podrían no tener alt adecuado. Por ejemplo, si la imagen de “Recogida de palets” solo tiene alt=»Embalajes MC» o está sin alt, un usuario con discapacidad visual no recibirá ninguna descripción útil (o escuchará algo genérico no relacionado). Recomendamos proporcionar descripciones concisas pero descriptivas en el atributo alt de cada imagen relevante, p. ej.: alt=»Palets usados apilados para su reciclaje» en la sección de recogida, alt=»Logotipo de Embalajes MC» en el header (o incluso alt=»» si el logo está junto al título textual). Cabe destacar que no se debe incluir las palabras “imagen de…” en el alt, sino ir directo a la descripción . Al corregir los textos alternativos, el sitio cumpliría con el criterio 1.1.1 y sería perceptible para todos los usuarios independientemente de la modalidad de navegación.

Observaciones Generales y Sugerencias de Mejora

En general, embalajesmc.es demuestra un buen punto de partida en cuanto a accesibilidad: su contenido es claro, el lenguaje es sencillo, y se han aplicado principios básicos (como una estructura lógica y navegación simple). No se detectan barreras críticas que impidan el acceso a usuarios, pero sí algunas áreas de mejora clave. A continuación, se presentan las recomendaciones prioritarias para elevar la accesibilidad del sitio al nivel esperado de conformidad AA:

Proveer textos alternativos descriptivos en todas las imágenes informativas (y marcar con alt=»» las puramente decorativas) . Esto asegurará que usuarios con lectores de pantalla puedan captar la información visual esencial.
Optimizar el menú de navegación para accesibilidad: implementar el botón de menú móvil como un elemento nativo (por ejemplo <button>) con etiqueta ARIA apropiada (e.g. aria-label="Menú principal") y gestionar su estado (aria-expanded) al abrir/cerrar . Garantizar que se pueda usar totalmente vía teclado y lector de pantalla, anunciando cuándo el menú está expandido o colapsado.
Verificar y mejorar el contraste de color allí donde sea necesario, cumpliendo con la relación 4.5:1 para texto normal . En particular, revisar textos sobre imágenes o botones con fondos de color corporativo para asegurar su legibilidad para personas con baja visión o en pantallas con brillo.
Asegurar la accesibilidad del formulario de contacto: incluir etiquetas <label> asociadas a cada campo , indicar campos obligatorios de forma accesible, y ofrecer feedback de errores claro. Si el formulario depende de JavaScript, considerar una solución de respaldo (por ejemplo, mostrar directamente el correo de contacto como alternativa) para usuarios que no puedan utilizarlo.
Mantener la estructura coherente de encabezados y navegación: continuar usando los encabezados en orden jerárquico sin saltos injustificados , y mantener elementos comunes (menú, pie de página) ubicados de forma consistente en todas las páginas (criterio 3.2.3 de navegación consistente). Esto ayudará a todos los usuarios a orientarse mejor en el sitio.
Realizar pruebas con usuarios o herramientas de accesibilidad: Se recomienda emplear validadores automáticos (como Wave, Lighthouse) y, más importante, pruebas manuales con un lector de pantalla (NVDA, JAWS o VoiceOver) y sólo teclado. Estas pruebas suelen revelar detalles adicionales — por ejemplo, verificar que el foco de teclado sea siempre visible , o que el orden de tabulación siga la secuencia lógica del contenido.

En conclusión, embalajesmc.es está cerca de cumplir muchos aspectos de accesibilidad web, pero con las mejoras sugeridas podrá alinearse plenamente con los criterios WCAG 2.1 nivel A/AA, ofreciendo así una experiencia más inclusiva, usable y profesional para todos los visitantes. Implementar estas recomendaciones no solo asegurará el cumplimiento normativo, sino que probablemente mejorará la satisfacción general de los usuarios y la eficiencia con que interactúan con el sitio.