Qué significa aquí «apunta a WCAG 2.2 AAA»
La palabra apunta es deliberada. Esta página dice con precisión qué se verifica, con qué, qué no verifica nada y qué pensamos hacer con esa brecha. Lily nunca afirma «cumplir» WCAG: ninguna auditoría lo respalda.
Verificado de forma continua
- El elemento semántico canónico, los atributos ARIA y las clases de enlace de cada componente, comprobados por conjuntos de pruebas unitarias de cada framework (más de 15 000 casos en siete frameworks).
- Cada una de las 571 páginas de demostración de componentes de la aplicación de ejemplo de SvelteKit no tiene errores de axe (conjuntos de reglas WCAG 2.0/2.1 A+AA y 2.2 AA): el barrido de todo el catálogo, con base inicial el 2026-08-27 y repetido el 2026-10-06, además de las bases por aplicación en las rutas de inicio, de catálogo y compuestas de las siete aplicaciones de ejemplo.
- Contratos de teclado para cada componente interactivo, documentados en los metadatos canónicos de cada componente y ejercitados por los conjuntos de pruebas; los paquetes de asistentes ejecutan además especificaciones de Playwright en navegadores reales.
- Mínimos de tamaño de objetivo y protecciones contra desbordamiento de WCAG 2.2 en los 45 temas; enlace de salto, regiones de referencia y ausencia de desbordamiento horizontal en cuatro tamaños de ventana por aplicación; aplicación de
lang/dir, incluida la inversión para escritura de derecha a izquierda.
No verificado por nada
- Nunca se ha realizado una auditoría de conformidad. Ni VPAT ni certificación. Las herramientas automáticas cubren solo una minoría de los criterios de éxito de WCAG.
- Los criterios específicos de AAA (contraste mejorado y otros) son intenciones de diseño, no propiedades verificadas; los conjuntos de reglas de axe se ejecutan en A/AA. Todavía no hay un tema específico de alto contraste.
- El comportamiento con lectores de pantalla apenas se ha probado. Los conjuntos de pruebas comprueban atributos ARIA, no lo que anuncian VoiceOver, NVDA o JAWS; y este proyecto ha publicado en más de una ocasión pruebas en verde con defectos reales, cada uno documentado en el registro de cambios precisamente porque las pruebas no podían verlos.
Qué pensamos hacer al respecto
Una auditoría de accesibilidad independiente es el primer uso previsto de cualquier financiación del proyecto, y el alcance que necesita un auditor ya está preparado. Hasta entonces, lo que más desea este proyecto son informes de lectores de pantalla: «el componente X anuncia Y, y es incorrecto porque Z» se puede abordar directamente.
Informar de un problema
Abre una incidencia en github.com/LilyDesignSystem/lily-design-system o escribe a joel@joelparkerhenderson.com. Indicar un criterio de WCAG ayuda, pero no es obligatorio: «No pude manejar X con el teclado» es un informe completo.
La declaración completa, con la tabla de verificación y su historial de revisiones, está en el repositorio: docs/accessibility-statement.md.