Saltar al contenido principal

Zayloft Accessibility

Zayloft se compromete a hacer que sus experiencias digitales sean utilizables por el mayor número razonable de personas, incluidas quienes usan tecnologías de asistencia o formas alternativas de navegar, leer, escuchar o interactuar con el contenido.

Nuestro enfoque se centra en la experiencia, el código y el contenido subyacentes en lugar de depender de overlays o afirmar accesibilidad universal. Utilizamos WCAG 2.2 Nivel AA como referencia práctica cuando corresponde.

Las traducciones se ofrecen por comodidad. En caso de conflicto, prevalece la versión inglesa en la medida permitida por la ley.

Nuestro enfoque de accesibilidad.

1. Alcance

Esta Declaración se aplica a sitios públicos, experiencias autenticadas, interfaces para desarrolladores y contenido digital relacionado de Zayloft donde se haga referencia a ella. Los productos e integraciones pueden tener características distintas y un aviso específico puede complementar esta página.

2. Estándar de referencia

Zayloft utiliza WCAG 2.2 Nivel AA como objetivo práctico de referencia cuando corresponde. WCAG se organiza en contenido perceptible, operable, comprensible y robusto. Salvo que Zayloft publique una declaración específica de conformidad para un producto, versión y alcance evaluados, esta página no debe interpretarse como afirmación de conformidad total de cada página o función.

3. Accesibilidad desde el diseño

La accesibilidad funciona mejor cuando los problemas se resuelven en el diseño, código y contenido en lugar de depender de overlays o modos separados. Zayloft busca incorporarla a la estructura, interacción, contenido, formularios, navegación y revisión de producto.

Interacción y presentación.

4. Acceso por teclado

Los controles interactivos deberían poder alcanzarse y utilizarse con teclado cuando la función pueda operarse razonablemente sin ratón o touch. El orden debe ser significativo y el foco identificable. Los scripts de protección o atajos no deberían bloquear navegación normal por teclado, comandos de tecnología de asistencia o funciones de accesibilidad del navegador.

5. Foco visible y gestión del foco

Los elementos interactivos deberían ofrecer una indicación visible de foco con contraste suficiente. Headers fijos, dialogs y otro contenido no deberían ocultar innecesariamente el foco, y las interfaces temporales deberían gestionarlo de forma comprensible para usuarios de teclado y screen readers.

6. Texto, contraste, zoom y reflow

Zayloft busca tipografía legible, contraste suficiente y layouts utilizables cuando se amplía el texto o el zoom. La información no debería depender solo del color y los diseños responsivos deberían permitir reflow sin scroll bidimensional innecesario para contenido ordinario.

7. Movimiento, animación y flashes

Las animaciones y el movimiento deberían ser moderados para evitar barreras vestibulares, cognitivas o de atención. Cuando sea apropiado, Zayloft busca respetar preferencias de reduced motion y evitar patrones de flashes que creen riesgos evitables.

Estructura, contenido y formularios.

8. Estructura semántica y tecnologías de asistencia

Las páginas deberían usar headings, landmarks, labels, links y elementos semánticos significativos cuando sea práctico. Los controles personalizados deberían exponer nombre, rol, estado y valor accesibles, y el idioma y dirección de página deberían identificarse correctamente.

9. Imágenes, iconos y contenido no textual

Las imágenes informativas deberían tener alternativas de texto apropiadas y las decorativas no deberían añadir ruido innecesario para screen readers. Los iconos interactivos deberían tener un nombre accesible que comunique su función.

10. Audio, video y media temporal

Cuando Zayloft publique media pregrabada importante, deberían considerarse captions, transcripts, audio description u otras alternativas según el contenido y los requisitos aplicables. Los captions automáticos pueden necesitar revisión porque los errores pueden alterar el significado.

11. Formularios, autenticación y errores

Los campos deberían tener labels o nombres accesibles y las instrucciones deberían explicar formatos o restricciones cuando sea necesario. Los errores deberían comunicarse en texto y asociarse al campo cuando sea práctico. Los flujos de autenticación y verificación deberían evitar barreras cognitivas innecesarias y ofrecer alternativas accesibles cuando corresponda.

12. Links, botones y tamaño de objetivos

Links y botones deberían comunicar su propósito mediante el nombre accesible y el contexto. Los objetivos interactivos deberían tener tamaño y separación que reduzcan activaciones accidentales cuando sea práctico. Nuevas ventanas y acciones irreversibles no deberían resultar innecesariamente sorprendentes.

Productos, idiomas y terceros.

13. Experiencias móviles y responsivas

Zayloft busca soportar operación accesible en tamaños de viewport y métodos de entrada comunes. Los layouts móviles deberían preservar orden de lectura, labels y acceso a acciones esenciales.

14. Idioma, localización y RTL

Zayloft soporta varios idiomas y presentación right-to-left donde esté habilitada. El contenido localizado debería preservar semántica, orden, labels y significado, y los cambios de idioma deberían identificarse cuando sea necesario para tecnologías de asistencia.

15. Interfaces de desarrollador y cuenta

Dashboards y herramientas de desarrollador pueden contener datos complejos, código, tablas, logs, controles de credenciales y estados. Deberían ofrecer labels significativos, acceso por teclado y alternativas textuales cuando sea práctico. API y SMPP no son interfaces de accesibilidad de navegador, pero su documentación y herramientas de configuración sí forman parte de la experiencia digital.

16. Contenido e integraciones de terceros

Algunas experiencias pueden incluir pagos, autenticación, comunicaciones, media o soporte de terceros. Zayloft busca seleccionar y configurar componentes teniendo en cuenta accesibilidad cuando sea razonablemente posible, aunque también depende del proveedor y la configuración del Cliente. Las barreras reportadas pueden evaluarse para una alternativa o remediación.

Feedback, evaluación y mejora.

17. Evaluación y estado de conformidad

La accesibilidad es un proceso continuo. Las herramientas automáticas no sustituyen revisión con teclado, screen readers, evaluación visual o experiencia especializada. Zayloft no afirma que cada página, integración o experiencia configurada por un Cliente esté libre de defectos.

18. Reportar una barrera

Si encuentras una barrera, escribe a support@zayloft.com con “Accessibility” en el asunto e indica página o función, tarea, problema y, si deseas, navegador, dispositivo o tecnología de asistencia. No incluyas contraseñas, API keys, tokens, OTPs u otros secretos.

19. Acceso alternativo y asistencia razonable

Si una barrera impide información o una acción importante, explica la tarea que necesitas completar. Cuando sea razonablemente posible, Zayloft puede evaluar un formato alternativo, método de comunicación o ruta asistida mientras se revisa el problema, sin exigir datos sensibles innecesarios ni reducir la seguridad.

20. Requisitos aplicables y actualizaciones

Las obligaciones de accesibilidad varían por jurisdicción, producto, tipo de Cliente y servicio. Zayloft abordará los requisitos aplicables sin afirmar que un único estándar técnico resuelve automáticamente toda obligación legal. Esta Declaración puede actualizarse cuando cambien productos, estándares, prácticas o requisitos.

Reportar un problema de accesibilidad

support@zayloft.com