Accessibility audit evaluates digital products against WCAG 2.1/2.2 standards and inclusive design principles. The skill produces accessibility scorecards, violation inventories, and remediation roadmaps that ensure digital experiences are usable by people with diverse abilities.
TL;DR
Evalua conformidad WCAG 2.1/2.2 en niveles A, AA y AAA con inventario detallado de violaciones
Clasifica hallazgos por severidad, impacto en usuarios y esfuerzo de remediacion
Produce scorecard de accesibilidad por componente, pagina y flujo critico
Evaluar por principio WCAG — Assess each POUR principle: Perceivable (alt text, contrast, captions), Operable (keyboard, timing, seizures), Understandable (readable, predictable, input assistance), Robust (parsing, name/role/value)
Clasificar violaciones — Rate each finding by severity (critical/major/minor/advisory) and user impact
Priorizar remediacion — Rank fixes by: critical user impact first, then legal exposure, then effort-to-impact ratio
Disenar estrategia de testing — Establish automated CI checks, manual testing cadence, and assistive technology testing protocol
Producir guia de diseno — Document accessible patterns for ongoing development (color, typography, forms, navigation, media)
Criterios de Calidad
All WCAG 2.1/2.2 success criteria evaluated at target conformance level
Automated and manual testing combined (automated catches ~30-40% of issues)
Violations include WCAG criterion reference, severity, and specific remediation
Screen reader testing covers at least one major AT (NVDA, VoiceOver, or JAWS)
Keyboard navigation tested for all interactive elements
Color contrast ratios measured against WCAG thresholds (4.5:1 normal, 3:1 large text)
Remediation roadmap includes effort estimates and ownership
Design guidelines are actionable for development teams
Supuestos y Limites
Automated tools detect only 30-40% of accessibility issues — manual testing is essential
Full WCAG AAA conformance is aspirational; AA is the standard legal/regulatory target
Does not replace formal accessibility audit by certified professionals (IAAP)
Assistive technology behavior varies across versions and platforms
Casos Borde
Aplicacion legacy sin semantica HTML — Cuando el producto usa tablas para layout o divs sin roles ARIA, el skill genera un inventario de deuda semantica y prioriza remediacion por flujo critico en lugar de cobertura completa.
SPA con contenido dinamico pesado — Single Page Applications que actualizan el DOM sin notificar al screen reader requieren auditoria especifica de live regions, focus management y route announcements.
Contenido multimedia sin captions — Si el producto tiene video/audio extenso sin subtitulos ni transcripciones, el skill calcula esfuerzo de captioning y propone priorizacion por trafico y criticidad del contenido.
Objetivo AAA solicitado — Cuando se pide conformidad AAA, el skill advierte que es aspiracional, identifica criterios AAA alcanzables y separa los que requieren inversion desproporcionada.
Decisiones y Trade-offs
Auditoria automatizada + manual vs. solo automatizada — Se requiere ambas porque las herramientas automaticas detectan solo 30-40% de issues; el costo adicional de testing manual se justifica por la cobertura critica que aporta.
Nivel AA como default vs. A — AA es el estandar legal en la mayoria de jurisdicciones (ADA, EN 301 549) y cubre issues de mayor impacto; A es insuficiente para usuarios reales.
Priorizacion por impacto en usuario vs. por esfuerzo — Se prioriza impacto en usuario primero (bloqueos de acceso antes que inconvenientes), aceptando que algunas correcciones de alto impacto son costosas.
Testing con un AT vs. multiples — Se requiere minimo un screen reader (VoiceOver o NVDA) como baseline; testing con multiples ATs es ideal pero se deja como recomendacion, no requisito.
Knowledge Graph
graph TD
subgraph Core["Accessibility Audit"]
A[WCAG Assessment] --> B[Violation Inventory]
A --> C[Remediation Roadmap]
A --> D[Testing Strategy]
end
subgraph Inputs["Inputs"]
E[Product/App Name] --> A
F[Target Level A/AA/AAA] --> A
G[Page/Flow Scope] --> A
end
subgraph Outputs["Outputs"]
A --> H[Scorecard a11y]
B --> I[Inventario Violaciones]
C --> J[Hoja de Ruta]
D --> K[Guia Diseno Inclusivo]
end
subgraph Related["Related Skills"]
L[testing-strategy] -.-> D
M[ux-research] -.-> A
N[design-system] -.-> C
end
Output Templates
Markdown (default)
Filename: quality_a11y-audit_{producto}_{WIP}.md
Structure: TL;DR -> Scorecard por principio POUR -> Inventario de violaciones (tabla) -> Roadmap priorizado -> Estrategia de testing
Via openpyxl con Design System MetodologIA v5. Headers branded (fondo navy, texto blanco, Poppins), formato condicional con colores semaforo, auto-filtros, valores sin formulas. Para scorecards de accesibilidad, inventario de violaciones y matrices de remediacion.
Via python-pptx con MetodologIA Design System v5. Slide master con gradiente navy, titulos Poppins, cuerpo Montserrat, acentos gold. Max 20 slides (ejecutiva) / 30 slides (tecnica). Speaker notes con referencias de evidencia. Para comites directivos y presentaciones C-level.
Evaluacion
Dimension
Peso
Criterio
Trigger Accuracy
10%
Activa ante "audit accessibility", "WCAG", "a11y" sin confundir con testing general o UX review
Completeness
25%
Cubre los 4 principios POUR, testing automatizado y manual, y roadmap de remediacion
Clarity
20%
Cada violacion referencia criterio WCAG especifico con remediacion concreta
Robustness
20%
Maneja SPAs, legacy sin semantica, contenido multimedia y objetivo AAA
Efficiency
10%
8 pasos sin redundancia; automatizado primero para filtrar antes de manual
Value Density
15%
Scorecard y roadmap son directamente presentables a stakeholders
Umbral minimo: 7/10 en cada dimension para considerar el skill production-ready.
Cross-References
metodologia-testing-strategy: Integration of a11y testing into overall test strategy
metodologia-ux-research: User research with people with disabilities
metodologia-design-system: Accessible component library and design tokens
Autor: Javier Montaño · Comunidad MetodologIA | Version: 1.0.0
