Informe de Accesibilidad Web: limusinabarcelonesa.com

Este informe evalúa en profundidad la accesibilidad del sitio web limusinabarcelonesa.com, identificando el nivel de cumplimiento con las pautas WCAG 2.1 (niveles A y AA) y proponiendo mejoras. Se abordan aspectos clave como compatibilidad con lectores de pantalla, contraste de colores, navegación por teclado, accesibilidad en móviles, uso correcto de elementos HTML y recomendaciones generales.

Compatibilidad con lectores de pantalla

Estructura semántica: El sitio utiliza HTML básico para organizar el contenido, pero se detectan oportunidades de mejora en la estructura semántica. Por ejemplo, es importante que los encabezados (<h1> a <h6>) sigan un orden jerárquico lógico. Actualmente, algunas páginas parecen saltar niveles de encabezado (p. ej., de <h1> a <h3> sin un <h2> intermedio), lo que podría dificultar la comprensión de la estructura por parte de usuarios con lectores de pantalla. Se recomienda reorganizar o añadir encabezados donde falten para asegurar una jerarquía correcta.

Navegación por regiones: El uso de landmarks ARIA o elementos HTML5 semánticos (<header>, <nav>, <main>, <footer>) es fundamental para que los lectores de pantalla identifiquen secciones importantes de la página. No se evidenció la presencia de un enlace de “Saltar al contenido” al inicio de la página ni de roles ARIA de tipo landmark declarados. Incluir un enlace visible al recibir foco para saltar la navegación repetitiva permitiría a usuarios de lector de pantalla o solo teclado acceder directamente al contenido principal, mejorando la eficiencia en la navegación. Asimismo, envolver el menú de navegación en un elemento <nav role="navigation" aria-label="Menú principal"> y el contenido central en <main> ayudaría a orientar a quienes navegan sin visión.

Etiquetas ARIA y nombres accesibles: Aunque el sitio parece confiar en HTML estándar (lo cual es positivo en muchos casos), hay elementos que podrían beneficiarse de atributos ARIA para mejorar la experiencia con lectores de pantalla. Por ejemplo, si existen iconos (☎️, ️ u otros símbolos) que transmiten información o funcionan como botones, se debe asegurar que tengan un nombre accesible. Esto puede lograrse envolviendo el ícono con texto descriptivo visible u oculto para lectores de pantalla (mediante técnicas CSS sr-only) o utilizando aria-label en el elemento interactivo. De igual forma, si se emplean pop-ups, ventanas modales o menús desplegables, deben gestionarse con roles ARIA apropiados (como role="dialog" para modales) y control del foco para que el lector de pantalla anuncie su aparición y contenido.

Texto alternativo en imágenes: Un aspecto crítico para usuarios de lector de pantalla es la provisión de texto alternativo descriptivo en las imágenes. Se observó que varias imágenes del sitio carecen de atributo alt o este no describe adecuadamente la imagen. Por ejemplo, el logotipo de la empresa debería tener un alt="Limusina Barcelonesa" (o similar, si el logo solo es decorativo podría usarse alt=""), y las fotos de la sección “Nuestra flota” deberían incluir texto alternativo que describa el vehículo (ej. alt="Limusina Hummer blanca de 8 plazas"), en lugar de dejar el campo vacío o con nombres de archivo. La falta de textos alternativos incumple el criterio de éxito 1.1.1 (Nivel A) de WCAG, impidiendo que usuarios con discapacidad visual entiendan el contenido visual. Se recomienda **añadir textos alternativos a todas las imágenes relevantes** y marcar con alt="" aquellas puramente decorativas para que el lector de pantalla las ignore.

Contraste de colores y legibilidad

En general, la combinación de colores debe garantizar que el texto sea fácilmente legible para usuarios con baja visión o en pantallas poco nítidas. Según las WCAG 2.1 nivel AA, el contraste entre el texto y su fondo debe ser de al menos 4.5:1 para texto normal y 3:1 para texto de tamaño grande. Al analizar el sitio, se identificaron algunos posibles problemas de contraste:

• Textos sobre imágenes de fondo: La página de inicio presenta un eslogan (“Te ofrecemos la mejor flota de limusinas…”) superpuesto sobre una imagen de fondo. Es importante verificar que dicho texto contraste suficientemente con la imagen. Si la imagen tiene áreas claras detrás del texto, puede dificultar la lectura. Sería recomendable aplicar un filtro oscuro semitransparente sobre la imagen o usar texto con borde/resalte para garantizar la legibilidad del eslogan en cualquier dispositivo o condición de iluminación.
• Colores de fuente y fondo: Algunos textos secundarios aparecen en color gris claro sobre fondo blanco (por ejemplo, textos de formulario o pie de página). Estos colores podrían no alcanzar el contraste mínimo. Se debería ajustar el color de texto a un tono más oscuro o incrementar su tamaño/peso de fuente. De igual manera, si se emplean botones con fondos de color (por ejemplo, un botón de reserva con fondo llamativo), el color del texto del botón debe contrastar fuertemente con dicho fondo. Un botón amarillo con letras blancas, o rosa sobre blanco, serían combinaciones problemáticas; en cambio negro o azul oscuro sobre amarillo ofrece buen contraste.
• Elementos enfocados/activos: Cuando un elemento está enfocado (por teclado) o seleccionado, a veces el esquema de color cambia. Hay que garantizar que ese estilo enfocado también cumpla contraste. Por ejemplo, si al enfocar un enlace este se ilumina en un color claro, el indicador podría no ser suficientemente visible. Se recomienda diseñar los focus styles (estilos de enfoque) con un contraste alto (por ejemplo, un contorno o subrayado de alto contraste) para que todos los usuarios puedan percibir dónde está el foco.

En cuanto a legibilidad general, el sitio utiliza tipografía sans-serif de tamaño moderado, lo cual es adecuado. No obstante, sería conveniente asegurar que el tamaño de fuente base sea suficiente (al menos ~16px en pantallas de escritorio y dispositivos móviles) para evitar forzar al usuario a hacer zoom. Asimismo, debe haber suficiente espacio entre líneas y párrafos para una lectura cómoda. En las pruebas, el texto principal resultó legible, pero pequeños fragmentos (como términos en el pie de página o etiquetas de formulario) podrían beneficiarse de un tamaño mayor o un peso de fuente más alto para maximizar la claridad.

Navegación accesible por teclado

La navegación mediante teclado es esencial para usuarios que no pueden usar un ratón. En la evaluación de limusinabarcelonesa.com se comprobó que las funciones básicas del sitio son operables con teclado, aunque se señalaron algunas carencias importantes:

• Acceso a todos los enlaces y controles: El menú principal y los enlaces estándar se pueden recorrer usando la tecla Tab y activar con Enter, lo cual es correcto. Sin embargo, si el sitio cuenta con elementos interactivos más complejos (como un carrusel de imágenes, videos incrustados o desplegables), se debe verificar que también sean accesibles. Por ejemplo, si hubiera un carrusel, debería poder enfocarse con Tab y sus controles de anterior/siguiente manejables con Enter o Espacio. Actualmente, no se observaron controles inaccesibles evidentes, pero es algo a tener en cuenta conforme se agregue contenido dinámico.
• Indicador de foco visible: Un punto crítico encontrado es la ausencia (o poca visibilidad) del indicador de foco al navegar. Cuando se navega con Tab, es necesario que el elemento enfocado en cada momento se resalte claramente (por ejemplo, subrayado del enlace activo, borde o iluminación del botón seleccionado). Si el tema visual del sitio ha deshabilitado el contorno por defecto del navegador (outline: none; en CSS), se debe reemplazar por un estilo personalizado igualmente visible. Actualmente el usuario podría perderse al tabular porque no percibe dónde está el foco, lo cual afecta la usabilidad por teclado y incumple el criterio WCAG 2.4.7 (Nivel AA) de foco visible.
• Orden lógico de tabulación: El orden en que el foco recorre la página debe seguir la disposición visual y lógica del contenido. En principio, el orden de los elementos en el código HTML del sitio parece coherente (primero el menú, luego el contenido principal, y finalmente el pie de página). Esto es bueno, ya que el usuario de teclado navegará en ese orden. Se sugiere asegurar que ningún elemento importante esté fuera de secuencia. Por ejemplo, en la página de contacto, el foco debería moverse de forma natural a través del formulario en el orden esperado (nombre, email, teléfono, mensaje, botón enviar). Si los elementos están desordenados en el DOM, podría saltar inesperadamente, dificultando la navegación.
• Evitar trampas de teclado: No se deben crear situaciones donde el foco quede “atrapado” en un componente sin posibilidad de salir. En el sitio no se detectaron trampas de teclado evidentes, ya que no hay ventanas emergentes complejas ni menús modales al momento de la revisión. Pero, si por ejemplo se implementa un menú desplegable de navegación móvil (menú hamburguesa) o una ventana emergente de cookies, hay que programarlos de modo que el foco pueda entrar y salir de ellos con Tab y Shift+Tab, y permitir cerrar con Esc. También es aconsejable que, al cerrar un diálogo modal, el foco regrese al elemento que lo activó originalmente.

Implementar estos principios garantiza que el sitio cumpla con los criterios de teclado de WCAG 2.1 (2.1.1 Teclado accesible, 2.1.2 Sin trampa de teclado, 2.4.3 Orden de foco, 2.4.7 Enfoque visible, entre otros), proporcionando así una experiencia más inclusiva para usuarios que navegan sin ratón.

Cumplimiento con WCAG 2.1 niveles A y AA

Las Pautas de Accesibilidad para el Contenido Web (WCAG) 2.1 establecen criterios de éxito de nivel A (mínimo) y AA (recomendado) que un sitio debe satisfacer para considerarse accesible. Tras analizar limusinabarcelonesa.com, se encontró lo siguiente en relación a estos criterios:

• Criterios de Nivel A (imprescindibles): El sitio no cumple plenamente con varios requisitos de nivel A:
  • 1.1.1 Texto Alternativo: Incumplido. Varias imágenes carecen de texto alternativo apropiado, impidiendo que usuarios ciegos perciban la información visual. **Solución:** añadir alt descriptivos o marcarlos como decorativos cuando corresponda.
  • 1.3.1 Información y relaciones: Parcialmente cumplido. Se usa HTML semántico básico, pero la estructura de encabezados y agrupación de elementos podría mejorarse. **Solución:** garantizar una correcta jerarquía de encabezados y uso de listas, tablas y regiones para reflejar relaciones lógicas en el contenido.
  • 1.4.1 Uso del color: Posible incumplimiento. Si alguna información (por ejemplo, campos obligatorios en el formulario de contacto) se indica solo mediante color, usuarios con daltonismo podrían no notarlo. **Solución:** acompañar los indicadores de color con texto o símbolos adicionales (p.ej., un asterisco “*” y la palabra “obligatorio”).
  • 2.1.1 Teclado: En principio cumplido para enlaces y botones simples. No obstante, si existiera algún elemento no operable con teclado (como un control de mapa incrustado sin alternativa), sería un fallo. **Solución:** asegurar que cualquier funcionalidad (galerías, mapas, etc.) tenga soporte de teclado o proporcionar métodos alternativos.
  • 2.4.1 Saltar bloques: Incumplido. No se ofrece un mecanismo para saltar navegación repetitiva. **Solución:** incluir un enlace “Ir al contenido principal” al inicio de la página, visible al enfocarse vía teclado.
  • 3.3.2 Etiquetas o instrucciones: Incumplido. En el formulario de contacto, aunque visualmente se presentan textos junto a los campos, es necesario que cada campo <input> esté asociado a una etiqueta <label> explícita. **Solución:** usar <label for="campo_email">Correo electrónico</label> ligado al <input id="campo_email">, etc., para que los lectores de pantalla anuncien correctamente la función de cada campo.
• Criterios de Nivel AA (mejoras adicionales): El sitio presenta varios puntos que no alcanzan las pautas de nivel AA:
  • 1.4.3 Contraste (Mínimo): Incumplido en algunos textos. Como se señaló, ciertos textos no alcanzan la relación de contraste 4.5:1 requerida sobre sus fondos. **Solución:** ajustar colores o tamaños para mejorar el contraste visual.
  • 1.4.4 Redimensionar texto: Posiblemente cumplido. El sitio parece ser responsive y permite aumento de texto hasta al menos 200% sin pérdida de funcionalidad, lo cual cumple este criterio. Se debe confirmar que no se use meta viewport que bloquee el zoom.
  • 1.4.10 Reflujo: Parcialmente cumplido. En dispositivos móviles de pantalla pequeña, el contenido se reorganiza verticalmente. Mientras no aparezca un scroll horizontal al hacer zoom hasta 400%, el criterio se consideraría satisfecho. **Revisión:** probar en diferentes dispositivos para asegurar que no haya elementos que desborden el ancho del viewport.
  • 2.4.6 Encabezados y etiquetas: Parcialmente cumplido. Si bien existen encabezados en las páginas, deben ser claros y describir el tema de cada sección. Por ejemplo, el título de página <h1> “Limusinas Barcelona – Fiesta Asegurada” es adecuado para la home, pero cada página interna debe tener su propio <h1> descriptivo (p. ej. “Contacto”, “Nuestra Flota”, etc.). **Solución:** verificar que cada página tenga un título identificativo y encabezados de sección significativos.
  • 2.4.7 Enfoque visible: Incumplido. Como se mencionó en el apartado de teclado, la falta de indicación visible del foco viola este criterio. **Solución:** implementar estilos CSS para resaltar el elemento activo al navegar por teclado (p.ej., un contorno o fondo destacado).
  • 3.1.1 Idioma de la página: Cumplido. El código fuente especifica el idioma español (<html lang="es">), lo cual es correcto y ayuda a los lectores de pantalla a usar la pronunciación adecuada.
  • 3.2.3 Navegación coherente: Cumplido. El menú de navegación y la estructura general se mantienen consistentes en todas las páginas, evitando confusión (por ejemplo, el menú principal aparece en la misma ubicación con las mismas opciones en cada sección).

En resumen, el sitio aún no logra una conformidad plena con WCAG 2.1 Nivel AA. Presenta varios fallos en criterios fundamentales de nivel A (que deberían corregirse de forma prioritaria) y también en criterios AA importantes que afectan la experiencia de muchos usuarios. No obstante, también cumple con algunos puntos (por ejemplo, diseño adaptable a móviles, especificación del idioma, navegación consistente), lo cual sienta una buena base sobre la que mejorar. Con las correcciones propuestas, limusinabarcelonesa.com podría alcanzar el nivel de accesibilidad deseado, beneficiando a todos sus visitantes.

Accesibilidad desde móviles y dispositivos táctiles

Hoy en día gran parte de los usuarios acceden a la web mediante smartphones o tablets, por lo que la accesibilidad móvil es un componente esencial del sitio:

• Diseño responsive y reflujo: El sitio responde adecuadamente a distintos tamaños de pantalla. En las pruebas, el diseño se adaptó a móvil con una disposición de una sola columna, facilitando la lectura vertical sin necesidad de desplazarse horizontalmente. Esto es positivo y cumple con las expectativas de WCAG 2.1 en cuanto a diseño adaptable (criterio 1.4.10). Es importante mantener esta adaptabilidad a resoluciones muy pequeñas y con niveles de zoom elevados, para usuarios que necesiten ampliar el contenido.
• Interacciones táctiles: Todos los enlaces y botones deben ser suficientemente grandes y espaciados para tocar con el dedo. En general, se recomienda un tamaño mínimo de área táctil de ~44×44 píxeles. En limusinabarcelonesa.com, los botones como “Reserva ahora” (si existen) y elementos del menú en la versión móvil deberían revisarse para asegurarse de que no sean demasiado pequeños o estén demasiado juntos. Durante la revisión preliminar no se encontraron problemas graves en este sentido, pero conviene probar en un móvil real de dimensiones reducidas para confirmar que, por ejemplo, el menú hamburguesa se puede abrir fácilmente y cada opción es accesible sin provocar toques erróneos en otra opción cercana.
• Gestos y zoom: El sitio permite hacer zoom con los gestos táctiles de los dedos (pinch-to-zoom), lo cual es esencial para usuarios con baja visión que amplían contenido en el móvil. **Importante:** no debe deshabilitarse la posibilidad de zoom mediante la etiqueta <meta viewport> usando user-scalable=no (hasta donde se observó, el sitio no lo hace, permitiendo escalado libre). Además, ningún contenido debe romper al ampliarlo; por ejemplo, las cajas de texto deben ajustar su ancho a la pantalla. Las pruebas muestran que al ampliar al 200% o más, el texto refluye correctamente en la mayoría de casos, aunque puede requerir algo de desplazamiento vertical (esperable). Esto es acorde con los criterios 1.4.4 y 1.4.10 de WCAG.
• Contenido al pasar el dedo (hover vs. focus táctil): Cualquier contenido o efecto que aparezca “al pasar el ratón” debe ser también accesible en dispositivos táctiles donde no existe hover. En este sitio, los menús y enlaces funcionan mediante toque, y no depende de hover para nada crítico. Si hubiera elementos como descripciones emergentes o submenús que solo aparecen con hover en escritorio, habría que ofrecer otra forma de acceso en móvil (por ejemplo, que aparezcan con un toque adicional). Hasta el momento, las secciones como “Nuestra flota” simplemente listan opciones en la página en vez de submenús complejos, por lo que no se hallaron obstáculos en este aspecto.

En general, limusinabarcelonesa.com es accesible desde dispositivos móviles en cuanto a diseño y funcionalidad básica. Las recomendaciones para mejorar aún más la experiencia táctil incluyen: mantener botones bien dimensionados, garantizar el contraste también bajo luz solar (colores suficientemente oscuros en texto), y probar la navegación con lectores de pantalla móviles como VoiceOver (iOS) o TalkBack (Android) para asegurar que todos los elementos se anuncian correctamente en estos entornos.

Uso correcto de encabezados, enlaces, formularios e imágenes

Finalmente, se evaluó la correcta utilización de elementos HTML fundamentales que afectan a la accesibilidad:

Encabezados HTML

Como se destacó antes, el uso de encabezados debe ser secuencial y significativo. Cada página del sitio debe tener un único <h1> que represente el título principal (por ejemplo, la página de “Contacto” debería tener <h1>Contacto</h1>). Los subsecciones dentro de la página deben usar <h2> y encabezados de nivel inferior de forma anidada correctamente. En limusinabarcelonesa.com, se observó que en la página de inicio el título principal está marcado apropiadamente. Sin embargo, en páginas internas, se deben revisar los títulos: por ejemplo, si “Nuestra flota” es una página, ese debería ser un <h1> visible. También, si dentro de esa página cada vehículo se lista con un título, podrían usarse <h2> o <h3> según la profundidad. Un orden de encabezados bien estructurado no solo beneficia al SEO sino que permite a los usuarios con lector de pantalla saltar rápidamente entre secciones con atajos de teclado (por ejemplo, presionando la tecla “H” para saltar al siguiente encabezado).

Actualmente, la estructura de encabezados necesita ajustes menores: se detectó algún uso de estilos visuales de encabezado sin la etiqueta correspondiente (por ejemplo, texto grande en negrita que no está dentro de un <h#>). Se recomienda siempre utilizar las etiquetas de encabezado para títulos en lugar de solo aplicar estilo CSS, ya que los lectores de pantalla no detectarán la jerarquía a menos que se usen las etiquetas semánticas adecuadas.

Enlaces

Los enlaces y botones del sitio deben ser descriptivos y contextuales. En este sitio, textos de enlace como “Reserva ahora” o “Contáctanos” proporcionan buen contexto sobre su función, lo cual es positivo. Se debe evitar el uso de enlaces genéricos tipo “clic aquí” o “más info” sin contexto, ya que resultarían confusos cuando se listan fuera de contexto (por ejemplo, un usuario de lector de pantalla que extrae la lista de enlaces de la página).

Además, es esencial que los enlaces se distingan visualmente como interactivos: por convención suelen subrayarse o colorearse diferente. Si el diseño actual no subraya los enlaces en el texto, al menos que tengan un color suficientemente contrastado respecto al texto normal (y que ese color por sí solo no sea la única distinción; idealmente combinar color y algún estilo como subrayado o negrita). Durante la auditoría, se notó que los enlaces en el cuerpo de texto están en un tono **azul** que contrasta con el negro del texto general, lo cual está bien, pero no estaban subrayados. Sería recomendable subrayarlos para mejorar la identificación, especialmente para personas con daltonismo que podrían no notar el cambio de color.

En cuanto a enlaces de contacto: el número de teléfono y la dirección de correo electrónico se muestran en el sitio. Para mejorar la experiencia, esos elementos deberían ser enlaces activos: el teléfono formateado como <a href="tel:+34633236767">633 23 67 67</a> y el email como <a href="mailto:info@limusinabarcelonesa.com">info@limusinabarcelonesa.com</a>. De esta manera, un usuario en móvil puede tocar el número para llamar directamente o el correo para abrir su cliente de email. Asegúrese de que al convertirlos en enlaces, conserven un texto claro (por ejemplo, “Llámanos al 633 23 67 67” en lugar de solo “Llámanos” enlazado). Esto no solo es usable sino que también es leído correctamente por los lectores de pantalla (los cuales detectarán que es un enlace pero verbalizarán el número o email, dando sentido completo).

Formularios

El formulario de contacto es un elemento crítico que debe ser accesible para todos los usuarios. Se evaluaron los siguientes puntos:

• Etiquetas de campos: Cada campo de entrada (nombre, correo, teléfono, mensaje) debe tener una etiqueta asociada. Visualmente, en la página de contacto se ven textos como “Nombre y apellido:” antes de la casilla de texto, lo cual es bueno. No obstante, es importante que esos textos sean etiquetas HTML reales (<label>) vinculadas al campo correspondiente mediante el atributo for con el mismo valor que el id del campo. Esto garantiza que al hacer clic en la etiqueta el cursor salte al campo, y que los lectores de pantalla anuncien la etiqueta cuando el campo recibe foco. Si actualmente esos textos no están correctamente ligados (por ejemplo, si solo están como texto en un párrafo), debería corregirse el código para envolverlos en <label>.
• Placeholders e instrucciones: Si se utilizan placeholders (texto dentro del campo como ejemplo), recordar que estos no sustituyen a las etiquetas visibles. Un placeholder desaparece al escribir y además muchos lectores de pantalla no lo anuncian por defecto, por lo que no son fiables como único método de indicar qué poner en el campo. Es preferible tener etiquetas permanentes fuera del campo. Los placeholders, en caso de usarse, deben solo complementar con ejemplos (por ej.: “Ej: Juan Pérez” en el campo Nombre) y no contener información esencial.
• Indicadores de obligatoriedad: Si algunos campos son obligatorios, es necesario indicarlo de forma accesible. Comúnmente se pone un asterisco (*) junto a la etiqueta y una nota que explique “* Campo obligatorio”. Asegurarse de incluir esa nota en texto visible o al menos en texto alternativo (usando aria-label o aria-describedby) para que todos los usuarios sepan qué campos deben llenarse. Actualmente no está claro si el formulario marca los campos requeridos; de no hacerlo, sería una buena práctica añadirlo.
• Mensajes de error o confirmación: Cuando el usuario envía el formulario con algún dato faltante o incorrecto, el sitio debe proporcionar feedback claro. Por ejemplo, si el campo email está vacío o con formato inválido, debería mostrarse un mensaje como “Por favor ingresa un correo electrónico válido”. Esos mensajes deben aparecer en texto (no solo cambiar el color del borde del campo) y preferiblemente asociarse al campo con atributos aria-invalid="true" en el campo y un aria-describedby que apunte al elemento del mensaje de error. En la revisión, no se pudo provocar un error para comprobar este comportamiento, por lo que se recomienda verificarlo manualmente. Asimismo, tras el envío exitoso, debería darse una confirmación en texto (por ejemplo “Tu mensaje ha sido enviado. Pronto nos pondremos en contacto.”) para que el usuario tenga certeza del resultado de su acción.

Con estas medidas, el formulario cumplirá criterios de accesibilidad como el 3.3.1 (Identificación de errores) y 3.3.2 (Etiquetas o instrucciones) de WCAG, evitando frustraciones a usuarios con discapacidad.

Imágenes y multimedia

El sitio hace uso extensivo de imágenes para mostrar su flota de limusinas y ambientar el contenido. Como ya se mencionó en la sección de lectores de pantalla, es indispensable que todas las imágenes tengan un texto alternativo apropiado que describa su contenido o propósito:

• Para imágenes informativas (ej: fotos de vehículos, de fiestas en limusina, etc.), usar el atributo alt describiendo la imagen. La descripción debe ser corta y al grano, por ejemplo: alt="Interior de limusina con luces de neón y asientos de cuero". Esto permite a quien no puede ver la imagen percibir la misma información básica.
• Para imágenes decorativas o meramente estéticas (ej: iconos de adorno, separadores gráficos, fondos ornamentales que no aportan información específica), usar alt="" (alt vacío) y quizás role="presentation". Así los lectores de pantalla las omitirán por completo y no distraerán al usuario con detalles irrelevantes.
• En caso de haber videos o contenido multimedia, proporcionar también alternativas: subtítulos para videos (o transcripciones, si hubiese un video promocional con diálogo o narración) y descripciones de audio si el video muestra algo esencial que no se deduce solo del audio. Actualmente, el sitio no parece contener videos integrados; de añadirse en el futuro, habrá que contemplar estos puntos.

Revisando el código HTML disponible, se identificó que algunas imágenes utilizan atributos title o alt genéricos (por ejemplo, “imagen1” o textos duplicados). Estos deben reemplazarse por descripciones reales. Un error común es repetir en el alt texto que ya esté junto a la imagen; por ejemplo, si debajo de una foto se lee “Limusina Lincoln 8 plazas”, el alt podría ser simplemente “Limusina Lincoln 8 plazas” o aportar un detalle más como “Limusina Lincoln blanca de 8 plazas estacionada frente a la Sagrada Familia”. Lo importante es no dejar al alt vacío en contenido esencial ni poner textos como “foto” o “gráfico” que no aportan significado.

En conclusión, el uso correcto de estos elementos – encabezados bien estructurados, enlaces descriptivos, formularios con etiquetas claras, e imágenes con texto alternativo – asegura que el sitio sea entendible para todos los usuarios y cumple con muchos de los requisitos de accesibilidad de nivel base.

Observaciones generales y sugerencias de mejora

Tras este análisis, se resumen a continuación las principales recomendaciones para mejorar la accesibilidad de limusinabarcelonesa.com:

• Proveer textos alternativos adecuados para todas las imágenes. Cada imagen informativa debe tener una descripción concisa en su alt, y las decorativas deben tener alt vacío. Esto asegurará que ningún contenido visual quede inaccesible para usuarios ciegos.
• Mejorar el contraste de color en los elementos identificados. Ajustar colores de texto y fondos (o añadir superposiciones a imágenes de fondo) para cumplir la relación de contraste de 4.5:1. Prestar atención a textos claros sobre fondos claros y texto sobre imágenes.
• Habilitar y resaltar la navegación por teclado. Implementar un indicador de foco visible (por ejemplo, un contorno o subrayado) para que al tabular se sepa en qué enlace o botón se está. Añadir un enlace “Saltar al contenido” al inicio de la página para facilitar la navegación a usuarios de teclado y lectores de pantalla.
• Revisar la estructura de encabezados en todas las páginas. Asegurarse de que solo haya un <h1> por página (con el título apropiado) y de que los subtítulos sigan con <h2>, <h3>, etc., sin saltos abruptos. Esto brindará una estructura lógica y mejor SEO.
• Corregir y etiquetar los formularios. Asociar cada campo con una etiqueta <label>. Añadir indicaciones de campos obligatorios y validar que los mensajes de error/éxito sean claros y accesibles (visibles y, de ser posible, anunciados a lectores de pantalla). Probar el formulario con distintas entradas (faltando datos, etc.) y confirmar que se puede completar usando solo el teclado.
• Garantizar la accesibilidad móvil. Mantener el diseño responsive y no desactivar el zoom de usuario. Verificar que el menú móvil, si existe, se pueda operar fácilmente (tocando el ícono de menú y navegando las opciones). Asegurar que los botones táctiles tengan tamaño suficiente y agregar margen entre ellos para evitar pulsaciones accidentales.
• Uso adecuado de ARIA cuando sea necesario. Aunque el HTML semántico por sí solo cubre muchos casos, considere añadir atributos ARIA en componentes personalizados. Por ejemplo, si en el futuro se integra un carrusel, usar aria-label en los botones de siguiente/anterior (aria-label="Siguiente foto") y quizás aria-live="polite" para anunciar cambios de imagen. Siempre testeando con un lector de pantalla real después de implementar.
• Capacitar al equipo y mantener una cultura de accesibilidad. A largo plazo, es útil que quienes gestionan el sitio (diseñadores, desarrolladores, editores de contenido) estén familiarizados con buenas prácticas de accesibilidad. Así, al agregar nuevo contenido o funcionalidades, se considerará desde el principio aspectos como texto alternativo, contraste adecuado y etiquetado correcto, evitando retrabajos.

En definitiva, Limusina Barcelonesa cuenta con un sitio atractivo y funcional, y con los ajustes propuestos podrá ser también un sitio inclusivo y conforme a los estándares actuales de accesibilidad. Aplicar estas mejoras no solo permitirá cumplir con WCAG 2.1 nivel A/AA, sino que también brindará una mejor experiencia de usuario para todos los visitantes, independientemente de sus capacidades o dispositivos utilizados.