Antes de elegir un chatbot de WordPress, solicita pruebas de accesibilidad para la interfaz exacta del producto, la versión evaluada y el recorrido del visitante que necesitas. Compara después la declaración del proveedor con tu tema, ubicación y hallazgos locales registrados. Separa el alcance sin respaldo, las pruebas ausentes y los defectos confirmados. Una insignia por sí sola no responde a estas preguntas de compra.
Esta guía para evaluar proveedores de chatbots accesibles de WordPress ofrece una solicitud de pruebas, una matriz de afirmaciones frente a versiones y condiciones para decidir la compra. No evalúa la conformidad de un producto ni ofrece una conclusión jurídica. Todas las filas de ejemplo son hipotéticas, no resultados de clientes.
Autor: Achla AI, organización. Revisión: 14 de octubre de 2026. Elaborado con ayuda de IA utilizando normas oficiales, documentación de proveedores y fuentes del producto examinadas. La fecha de revisión no es una fecha de publicación.
Una afirmación de accesibilidad inicia una decisión de compra
Define expresamente el recorrido necesario antes de comparar proveedores. Para un widget de respuestas sobre un sitio público, podría incluir abrir la interfaz, preguntar por un servicio, seguir una página de apoyo y regresar al sitio. Un informe sobre el panel de agentes no responde, por sí solo, si la interfaz del visitante cumple tus requisitos.
La necesidad es concreta: una pregunta en el foro de WordPress de una persona del ámbito universitario consulta cómo realizar acciones esenciales del chatbot con teclado. Esta pregunta histórica es una señal del público, no un hallazgo sobre todos los plugins actuales.
La pregunta de compra es qué pruebas respaldan la experiencia necesaria en tu configuración prevista. Fija ese requisito antes de una demostración comercial. De lo contrario, una demostración convincente puede mostrar un tema, ubicación o interfaz del producto diferentes de los que piensas adquirir.
Identifica producto, versión y contexto del sitio tras la afirmación
Pide al proveedor que identifique el componente cubierto: widget web público, SDK móvil, interfaz administrativa u otra superficie. Registra su versión o compilación cuando esté disponible, fecha de evaluación, versión de la norma y nivel declarado. El título de un informe y un logotipo conocido son indicios útiles, pero necesitan un alcance.
Los requisitos de declaraciones de conformidad de WCAG especifican fecha, versión y URI de las pautas, nivel, páginas incluidas y tecnologías utilizadas. WCAG también aborda páginas completas y procesos completos. Una declaración sobre un componente no establece, por tanto, la conformidad de todo tu sitio WordPress.
Separa los metadatos del proveedor de tu registro de instalación. El proveedor puede evaluar una versión de un widget alojado; tú debes identificar además tema, editor, ubicación, identidad visual y páginas públicas. Estos campos adicionales forman la hoja de contratación aquí propuesta, no un nuevo requisito de certificación de W3C.
| Campo de alcance | Prueba del proveedor | Tu configuración prevista |
|---|---|---|
| Interfaz del producto | Componente exacto evaluado | Widget del visitante u otra interfaz necesaria |
| Versión y fecha | Versión o compilación evaluada y fecha del informe | Integración prevista y fecha de revisión |
| Normas | Versión, nivel y alcance del informe | Requisito de evaluación de la organización |
| Contexto anfitrión | Supuestos, requisitos previos y exclusiones | Tema, editor, ubicación y personalización |
| Recorrido | Páginas o tareas evaluadas | URL públicas y recorrido completo necesario |
Si el proveedor no identifica la versión de una declaración, registra «aplicabilidad a la versión desconocida». No vincules silenciosamente su informe a la versión más reciente.
Lee las declaraciones buscando fechas, excepciones e interfaces
Las páginas actuales de la categoría ilustran por qué importan estas distinciones. Los ejemplos siguientes describen declaraciones observadas el 14 de octubre de 2026; no son dictámenes independientes de conformidad ni una clasificación de proveedores.
La guía de accesibilidad de LiveChat declara WCAG 2.2 AA para su Chat Widget y enlaza un VPAT. Distingue colores predeterminados de la comprobación de colores personalizados e identifica una limitación de los elementos predeterminados para captar la atención. Solicita el informe aplicable a la configuración prevista, sin extender su titular a todas las funciones visuales opcionales.
Las preguntas frecuentes de Messenger de Intercom indican que su Web Messenger fue evaluado en enero de 2026 y describen WCAG 2.2 AA como mayoritariamente compatible, con áreas parcialmente compatibles en el VPAT enlazado. Distinguen esa interfaz de su aplicación web y sus SDK móviles no evaluados, y advierten que combinaciones de colores personalizadas pueden empeorar la accesibilidad.
La página de accesibilidad de Zendesk enumera informes separados para distintos productos. En esta revisión, la entrada del Web Widget de mensajería lleva fecha de septiembre de 2025, mientras la del Classic Web Widget lleva diciembre de 2019. Selecciona el informe del producto real, no el documento que aparezca primero.
Una declaración clara de excepciones aporta información que evaluar. No vuelve automáticamente inadecuado a un proveedor: la decisión depende de si la excepción afecta al recorrido necesario y de si existe una solución verificada.
Envía una solicitud delimitada de pruebas antes de elegir el widget
Usa la misma solicitud para todos los proveedores, incluido Achla. Solicita pruebas aplicables sin presumir que todos tienen el mismo formato de informe o que la ausencia de un documento demuestra que el producto es inaccesible.
- Identifica el producto exacto y el recorrido del visitante que se plantea.
- Solicita la evaluación fechada, la versión aplicable y la norma, versión y nivel.
- Solicita el alcance, el método, los datos del evaluador y las excepciones conocidas.
- Pregunta qué ajustes o personalizaciones del sitio anfitrión pueden cambiar el resultado.
- Acuerda quién resolverá las preguntas pendientes y qué pruebas permitirán cerrarlas.
Una solicitud práctica puede decir: «Queremos usar el widget público en estas páginas de WordPress, con este tema y ubicación. Identifiquen la evaluación de esa interfaz, la versión a la que se refiere, sus exclusiones y las pruebas pertinentes para estas tareas».
Adjunta esta hoja:
| Prueba solicitada | Qué necesita distinguir el comprador |
|---|---|
| Evaluador, fechas y métodos | Afirmación del proveedor frente a hallazgos documentados de evaluación |
| Producto, compilación y páginas | Versión aplicable frente a otro producto o un informe histórico |
| Entorno de navegador y tecnologías de apoyo | Configuración probada frente a una promesa sin especificar |
| Supuestos sobre tema, ubicación e identidad visual | Valores predeterminados cubiertos frente al comportamiento personalizado del sitio |
| Excepciones conocidas y requisitos previos | Alcance respaldado frente a tareas necesarias sin resolver |
| Contactos del proveedor y del sitio | Quién responde sobre el producto y quién se responsabiliza de cambios del sitio |
| Motivos y registro de repetición | Qué cambios reabren la decisión de compra |
La plantilla de informe de evaluación de W3C incluye alcance, revisores, proceso y hallazgos, y remite a recursos de informes actualizados. Su introducción a la evaluación de conformidad explica la relación entre evaluar e informar: generar un informe no realiza la evaluación. Pide los hallazgos reales que respaldan el documento.
Separa afirmaciones, observaciones y pruebas ausentes
La afirmación de un proveedor describe el alcance que declara. Un hallazgo local describe lo que un evaluador observó en un entorno concreto. Una condición de compra describe qué exiges antes de seleccionar o implantar el producto. Mantén visibles los tres elementos.
| Registro | Afirmación y fuente del proveedor | Vinculación con versión y configuración | Pruebas locales | Responsable y condición de compra |
|---|---|---|---|---|
| Cobertura de la interfaz | Registrar declaración exacta y fecha | Confirmar que cubre el widget público | Aún sin evaluar | Comprador solicita informe aplicable |
| Identidad visual personalizada | Registrar límites declarados de personalización | Registrar tema, colores y ubicación elegidos | Registrar hallazgos o «sin comprobar» | Propietario aporta pruebas delimitadas |
| Recorrido necesario | Registrar alcance respaldado y excepciones | Registrar páginas y versión del producto | Registrar resultado y referencia a pruebas | Responsable resuelve cualquier bloqueo pertinente |
| Nueva versión | Conservar la declaración anterior | Registrar versión nueva y ajustes cambiados | Repetición pendiente | Comprador reabre condiciones afectadas |
Estas filas son estructuras vacías para decidir, no evaluaciones completadas. Rellénalas con documentos y observaciones reales; no conviertas «sin comprobar» en un resultado favorable.
Utiliza estados distintos. Pruebas ausentes significa que no has obtenido la evaluación o el hallazgo local necesarios. Fuera de alcance significa que el material se refiere a otra interfaz o configuración. Discrepancia significa que pruebas y afirmación no describen la misma versión o requisito. Defecto confirmado exige un hallazgo real reproducible. Cada estado requiere un siguiente paso diferente.
Por ejemplo, un informe de administración entregado para un requisito de widget de visitantes está fuera de alcance. Una evaluación actual del widget sin pruebas locales para tu tema personalizado supone una carencia de pruebas locales. Son ejemplos hipotéticos de clasificación, no acusaciones contra un proveedor identificado.
Identifica al responsable del defecto y la condición de repetición
Concreta la responsabilidad para poder actuar. Asigna el comportamiento del producto a un contacto identificado del proveedor, los cambios de plantilla o estilo al mantenedor, los hallazgos al evaluador y el veredicto de compra al comprador. Un defecto compartido puede involucrar a varias personas, pero una debe coordinar la próxima decisión.
Registra la tarea afectada, la referencia de pruebas, la versión pertinente y la condición de aceptación propuesta. «El proveedor mejorará la accesibilidad» no es verificable. Una condición útil identifica qué recorrido antes bloqueado debe resultar utilizable en el entorno indicado y qué revisor registrará el resultado.
La guía de W3C sobre declaraciones de accesibilidad recomienda datos de contacto, limitaciones conocidas y entornos probados. Eso favorece la transparencia; una declaración de accesibilidad no constituye por sí misma una evaluación técnica. Úsala para encontrar al contacto adecuado y contrastar los límites declarados con el informe.
Reabre las filas pertinentes cuando cambien una versión relevante del widget, el tema, la ubicación o la personalización. Conserva las pruebas anteriores y añade el resultado nuevo sin reescribir la historia. Una corrección prometida, una nota de versión o una captura de otra página no cierran una condición pendiente de compra.
Para procedimientos prácticos de teclado, lector de pantalla y área de visualización, consulta la guía existente de accesibilidad de la barra de búsqueda. Esta hoja regula las pruebas del proveedor y la responsabilidad de aceptación.
Decide evaluar, solicitar pruebas, mantener en espera o rechazar el alcance
Elige un veredicto delimitado y explica el motivo:
- Evaluar: las pruebas aportadas se refieren a la interfaz prevista y el trabajo específico del sitio restante tiene responsable.
- Solicitar pruebas: sigue abierta una pregunta material sobre alcance, fecha, excepción o evaluación.
- Mantener en espera: un bloqueo confirmado afecta a un recorrido necesario y su solución aún no está verificada.
- Rechazar el alcance propuesto: no puede satisfacer un requisito necesario, o el proveedor no ofrece una configuración adecuada que pueda evaluarse.
Estos veredictos son recomendaciones de contratación, no un sistema de puntuación de conformidad. Lo desconocido sigue siendo desconocido. Un precio atractivo no debe eliminar silenciosamente un recorrido requerido.
Registra las páginas, la configuración y las pruebas utilizadas. Una decisión limitada de evaluación no aprueba todas las versiones futuras ni cada página del sitio. Haz que el comprador acepte ese alcance y conserva las condiciones abiertas.
Aplica la misma solicitud de pruebas a Achla
Examina el conector de WordPress y la documentación de instalación para definir la interfaz y ubicación que evaluarías. Achla documenta respuestas con citas a contenido público y un conector con un único modo global de ubicación. La documentación examinada no demuestra una auditoría WCAG de Achla, una declaración de conformidad ni compatibilidad certificada con tu tema.
Usa la documentación de resolución de problemas para preguntas de comportamiento documentado. Revisa los planes actuales por separado de las pruebas de accesibilidad. La visión general de búsqueda del sitio proporciona contexto de categoría; no sustituye un informe aplicable.
Si las respuestas públicas con citas encajan, usa la incorporación para explorar el producto bajo tus condiciones de evidencia. Mantén la selección, la evaluación y la eventual autorización de lanzamiento como decisiones explícitas con su responsable.