{"id":70439,"date":"2026-05-13T19:39:36","date_gmt":"2026-05-13T17:39:36","guid":{"rendered":"https:\/\/cronuts.digital\/accesibilidad-web\/remediation-tecnica\/"},"modified":"2026-05-13T19:39:36","modified_gmt":"2026-05-13T17:39:36","slug":"remediation-tecnica","status":"publish","type":"page","link":"https:\/\/cronuts.digital\/en\/accesibilidad-web\/remediation-tecnica\/","title":{"rendered":"Remediation T\u00e9cnica Accesibilidad Web \u00b7 WCAG 2.2 AA Implementation"},"content":{"rendered":"\n

La auditor\u00eda sola no genera compliance: hay que remediar los issues detectados con c\u00f3digo real.<\/strong> CRONUTS.DIGITAL ejecuta remediation t\u00e9cnica en ciclos iterativos de dos semanas, no big-bang, priorizando el 30% de issues que generan el 50% del impacto compliance. El stack var\u00eda seg\u00fan la tecnolog\u00eda del cliente: WordPress + Gutenberg para webs corporate y blog, WordPress headless + Next.js para SaaS B2B h\u00edbridos, y design systems con Radix UI o Headless UI como base accesible para dashboards SaaS multi-tenant.<\/p>\n\n\n\n

Cinco pr\u00e1cticas t\u00e9cnicas core (cross-stack)<\/h2>\n\n\n\n

1. HTML sem\u00e1ntico antes que ARIA<\/h3>\n\n\n\n

La primera regla del WAI-ARIA Authoring Practices Guide: “No ARIA es mejor que mal ARIA”<\/em>. Reemplazamos <div><\/code> gen\u00e9ricos por <main><\/code>, <nav><\/code>, <article><\/code>, <section><\/code>, <aside><\/code>, <header><\/code>, <footer><\/code> donde corresponda. Los screen readers navegan por landmarks: si tu HTML no tiene la estructura sem\u00e1ntica correcta, la navegaci\u00f3n se convierte en una lectura lineal cansada.<\/p>\n\n\n\n

Headings hierarchy obligatoria sin saltos: H1 \u00fanico por p\u00e1gina, H2 para secciones principales, H3 para subsecciones. Listas con <ul><\/code> y <ol><\/code> donde aplique. Tablas de datos con <th><\/code> y scope<\/code> correctos. Botones de acci\u00f3n con <button><\/code>, no con <div onclick><\/code>.<\/p>\n\n\n\n

2. ARIA solo cuando HTML sem\u00e1ntico es insuficiente<\/h3>\n\n\n\n

ARIA roles, states y properties aplican cuando HTML nativo no expresa el patr\u00f3n: custom widgets como tabs, accordion, modal, autocomplete, combobox, menu, tooltip. WAI-ARIA Authoring Practices Guide documenta el patr\u00f3n canonical para cada uno. CRONUTS.DIGITAL implementa siempre la versi\u00f3n can\u00f3nica; los componentes custom inventados desde cero suelen romper la accesibilidad.<\/p>\n\n\n\n

Los antipatrones m\u00e1s comunes: aria-label<\/code> en elementos que ya tienen texto visible (duplica la lectura), role=\"button\"<\/code> en <a><\/code> sin gestionar Enter\/Space, aria-hidden=\"true\"<\/code> en elementos enfocables (focus trap invisible).<\/p>\n\n\n\n

3. Focus management expl\u00edcito<\/h3>\n\n\n\n

Focus visible obligatorio con \u00e1rea m\u00ednima 2×2 CSS px y contraste 3:1 contra el fondo adyacente (WCAG 2.2 nuevo criterio 2.4.13). Focus trap en modales y dialogs: el foco no debe salir del modal hasta que el usuario lo cierre. Focus return al elemento trigger al cerrar el modal. Skip links visibles al recibir el foco para saltar el header sticky.<\/p>\n\n\n\n

WCAG 2.2 (nuevo en 2023) a\u00f1ade el criterio 2.4.11 Focus Not Obscured<\/em>: cuando un elemento recibe foco, no puede quedar oculto parcialmente por overlays, banners de cookies o headers sticky. Implementaci\u00f3n: scroll-margin-top<\/code> CSS o JavaScript focus handler que ajuste el scroll.<\/p>\n\n\n\n

4. Color contrast cuantificado<\/h3>\n\n\n\n

Ratios obligatorios WCAG 2.2 AA: 4.5:1 para texto regular (<18px o <14px bold), 3:1 para texto grande (≥18px o ≥14px bold) y 3:1 para componentes UI no textuales (botones, form inputs, indicadores de estado, gr\u00e1ficos). Tools de medici\u00f3n: Stark, Adobe Color Contrast Analyzer, axe DevTools color checker, Lighthouse audit.<\/p>\n\n\n\n

El antipatr\u00f3n frecuente es el color como \u00fanico indicador de informaci\u00f3n: textos de error solo en rojo sin icono ni texto adicional, gr\u00e1ficos con datos diferenciados solo por color, links sin subrayado ni hover state. WCAG 1.4.1 requiere alternativa textual o visual no-color.<\/p>\n\n\n\n

5. Form accessibility canonical<\/h3>\n\n\n\n

Labels asociados via <label for=\"id\"><\/code> en lugar de placeholder-only. Error messages con aria-describedby<\/code> apuntando al texto del error. Autocomplete attributes para campos comunes (name<\/code>, email<\/code>, tel<\/code>, postal-code<\/code>, address-line1<\/code>) que aceleran completado para usuarios con discapacidad motora.<\/p>\n\n\n\n

Validaci\u00f3n en tiempo real anunciada con aria-live=\"polite\"<\/code> para que los screen readers la lean sin interrumpir la escritura. Mensajes de error que explican el problema y c\u00f3mo corregirlo, no solo “campo inv\u00e1lido”. Foco autom\u00e1tico al primer campo con error tras submit fallido.<\/p>\n\n\n\n

Stack-specific implementation<\/h2>\n\n\n\n

WordPress + Gutenberg<\/h3>\n\n\n\n

Themes accesibles auditados (revisi\u00f3n de blocks core y custom blocks). Plugin axe-core integrado en admin para detecci\u00f3n durante edici\u00f3n. ACF din\u00e1mico para gestionar metadata accessibility por p\u00e1gina (alt text controlado, ARIA labels en componentes complejos). Mu-plugins custom para forzar attributes en outputs theme-controlled. Cronuts.digital opera WordPress como CMS principal y todo nuevo theme nace WCAG 2.2 AA compliant.<\/p>\n\n\n\n

WordPress headless + Next.js<\/h3>\n\n\n\n

React a11y patterns con eslint-plugin-jsx-a11y bloqueando merges con violations. axe-core\/react integrado en CI\/CD para detecci\u00f3n autom\u00e1tica pre-deploy. Componentes UI desde headless libraries con accessibility de f\u00e1brica (Radix UI o Headless UI). Server-side rendering accesible (Next.js App Router) con focus management correcto entre route transitions.<\/p>\n\n\n\n

SaaS dashboards multi-tenant<\/h3>\n\n\n\n

Design system audit completo (Storybook + accessibility addon documentando cada componente). Component library refactor con Radix UI o Headless UI como base. Custom widgets complejos (data tables, calendars, autocompletes) implementados sobre los patterns canonicales WAI-ARIA Authoring Practices. Testing automatizado con Playwright + axe para flujos cr\u00edticos.<\/p>\n\n\n\n

Timeline remediation por tier<\/h2>\n\n\n\n
\n\n
Tier<\/th>Precio remediation<\/th>Timeline<\/th>Approach<\/th><\/tr><\/thead>\n
Web corporate <50 pages<\/td>3.000-6.000 €<\/td>14-21 d\u00edas<\/td>Single sprint dedicated team<\/td><\/tr>\n
Web B2B + intranet<\/td>6.000-12.000 €<\/td>30-45 d\u00edas<\/td>2 sprints iterativos: high-impact + residuales<\/td><\/tr>\n
Ecommerce + dashboard SaaS<\/td>10.000-25.000 €<\/td>45-60 d\u00edas<\/td>3 sprints: critical flows + content + components library<\/td><\/tr>\n
Enterprise multi-site<\/td>25.000 € +<\/td>60-90 d\u00edas<\/td>Sprint plan customizado por dominio<\/td><\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n

QA testing y compliance certificate<\/h2>\n\n\n\n

Tras cada sprint de remediation: re-validaci\u00f3n con axe + WAVE + Lighthouse + testing manual NVDA\/VoiceOver\/keyboard-only. Iteraci\u00f3n hasta alcanzar el 100% AA pass en los criterios sobre los que se trabaj\u00f3. El cliente recibe un compliance statement publicable bajo accessibility statement en footer del sitio, con UNE-EN 301 549 cross-reference para auditor\u00eda externa o respuesta a procurement Tier 1.<\/p>\n\n\n\n

Opcional con retainer 200-500 euros\/mes: monitoreo continuo con re-validaci\u00f3n trimestral, audit autom\u00e1tico mensual y alerts ante regression deploy. Necesario en sitios con cadencia de release alta donde un commit puede introducir issues nuevos en producci\u00f3n sin que nadie lo detecte hasta la siguiente auditor\u00eda manual.<\/p>\n\n\n\n

Pr\u00f3ximos pasos<\/h2>\n\n\n\n