Introduction

In today’s digital ecosystem, web accessibility has gone from being an option to an ethical, legal, and commercial imperative. However, many organizations address this requirement superficially, publishing generic accessibility statements that don’t reflect the actual user experience. These documents, often copied from templates, not only fail to inform but can also erode user trust and expose the company to legal risks. The key to making a difference lies in creating practical accessibility statements, living documents that honestly communicate compliance status, ongoing improvement efforts, and effective contact methods. This approach transforms the statement of an administrative burden into a pillar of the user experience strategy and a testament to the brand’s commitment to inclusivity.

This article breaks down the methodology for building and maintaining these authentic statements. The entire cycle will be covered: from the initial audit and defining a realistic roadmap, to transparent content writing and the integration of an effective feedback system. We will measure success not only by the level of compliance with the Web Content Accessibility Guidelines (WCAG), but also through key performance indicators (KPIs) such as the success rate of critical tasks for users with disabilities (expected increase of 25%), the reduction in the average time to resolve accessibility issues (target: <48 hours for critical issues), and the improvement in brand perception (Net Promoter Score).

Collaboration between development and design teams and users with disabilities is essential for the accessibility statement to reflect a genuine effort and not just be a static document.

Vision, Values, and Proposal

Focus on Results and Measurement

Our vision is a digital environment where accessibility is not a last-minute patch, but an intrinsic quality of the product, planned from the outset (Shift-Left Accessibility). We are guided by values ​​of transparency, accountability, and continuous improvement. We apply the Pareto principle (80/20) to prioritize remediation actions, focusing first on those problems that impact the largest number of users or block critical flows, such as the purchasing process or access to essential information. Our technical reference standard is the Web Content Accessibility Guidelines (WCAG) 2.1 and 2.2 at level AA, aligned with European standard EN 301 549 and other relevant international legislation. The value proposition is clear: to turn accessibility into a competitive advantage, improving the experience for all users, expanding the potential market, and building a strong and socially responsible brand reputation.

• Value 1: Radical Transparency. The statement must explicitly list known areas of non-compliance, explaining why they exist (e.g., third-party content, technical limitations) and what the plan is to address them.
• Value 2: User Empowerment. Multiple and easy-to-use contact channels must be provided for users to report barriers, along with a commitment to response and action through a defined Service Level Agreement (SLA).
• Value 3: Data-Driven Decision-Making. We use a decision matrix to prioritize fixes, cross-referencing the impact on the user (blocking, high, medium, low) with the complexity of implementation (hours/story points). High-impact, low-complexity problems are given top priority.
• Quality Criterion: Recurring Audits. Accessibility status is validated through a combination of automated tools (covering 30-40% of criteria), expert manual audits, and testing with real users of assistive technologies, conducted at least once a year or after each major redesign.

Services, Profiles, and Performance

Portfolio and Professional Profiles

We offer a portfolio of services designed to guide organizations in creating and maintaining practical and effective accessibility statements. These services are performed by a multidisciplinary team that includes certified accessibility auditors (e.g., WAS, CPACC), front-end developers with experience in WAI-ARIA, UX/UI specialists with a focus on inclusive design, and digital strategy consultants. Our services include:

• Comprehensive Accessibility Audit (WCAG 2.1/2.2 AA/AAA): A thorough analysis that combines automated tools, manual review of code and user flows, and testing with assistive technologies (screen readers, magnifiers, voice control).
• Remediation Consulting: Technical support for development teams, providing specific code solutions and validating implemented fixes.
• Accessibility Statement Drafting and Maintenance: Creation of a customized document, based on the audit results, that complies with W3C standards and local legislation (e.g., Royal Decree 1112/2018 in Spain).
• Customized Training: Workshops and courses for design, development, content, and QA teams to integrate accessibility into their workflows Daily.

Operational Process

1. Phase 1: Diagnosis (1-2 weeks). A full audit is performed. KPI: 100% identification of applicable WCAG criteria and documentation of all nonconformities with examples and recommendations.
2. Phase 2: Planning (1 week). Findings are prioritized in a remediation roadmap. KPI: 95% agreement rate with the client on priorities. Deviation from estimated budget < 10%.
3. Phase 3: Initial Drafting (1 week). The first draft of the statement is prepared, reflecting the current status and the roadmap. KPI: The draft includes all sections required by the regulations.Phase 4: Remediation (Variable, depending on scope). The client team implements the corrections with our support. KPI: Weekly reduction of the number of critical/high errors by 15%.

   Phase 5: Verification and Publication (1 week). The corrections are validated as effective, and the declaration is updated for publication. KPI: 0 accessibility regressions in the corrected areas.

   Phase 6: Maintenance (Ongoing). A quarterly or semi-annual review cycle of the declaration is established. KPI: The “last review” date of the statement never exceeds 6 months.

Tables and Examples

Improve the inclusive user experience.Success rate for key tasks (e.g., login, purchase) for JAWS/NVDA/VoiceOver users. Net Promoter Score (NPS) of users with disabilities.Usability testing with real users with disabilities. Implement a dedicated feedback channel.Increase the success rate from 60% to 90%. Increase the NPS in this segment by 20 points.Reduce legal risk.Number of complaints or lawsuits related to accessibility.Publish an accessibility statement in compliance with the law. Establish a complaint management process with an SLA.Reduce the number of formal complaints to zero within 12 months.Promote a culture of accessibility.Number of employees trained. Inclusion of accessibility criteria in the Definition of Done (DoD).Role-specific training programs. Integration of accessibility linters into the CI/CD pipeline.80% of the digital product team trained within one year. 100% of new features undergo basic accessibility testing before deployment.

Representation, campaigns, and/or production

Professional development and management

Managing a digital accessibility program is analogous to producing a complex project.

It requires meticulous coordination, resource planning, and proactive risk management. In this context, the accessibility statement is the public report on the state of that “production.” The logistics involve coordinating audits, planning remediation sprints without interrupting the development of new features, and managing communication between teams (development, QA, legal, marketing). The implementation schedule must be realistic, establishing quarterly milestones for correcting specific types of errors (e.g., Q1: contrast and alternative text errors; Q2: keyboard accessibility; Q3: focus management and WAI-ARIA).

Vendor management is crucial, especially when integrating third-party content or functionalities (maps, payment gateways, social media widgets). It is essential to require vendors to provide their own accessibility statements or VPATs (Voluntary Product Accessibility Templates) and to reflect any limitations arising from these external components in our statement. This is part of honest risk management.

• Documentation Checklist:
  • Detailed audit report.
  • Prioritized remediation roadmap.
  • Minutes of project follow-up meetings.
  • Versions of the accessibility statement with change control.
  • Log of user feedback and actions taken.
• Contingency Plans:
  • • What to do if a third-party library introduces an accessibility barrier? -> Contact the vendor, find an alternative, or document the limitation.
    • What to do if an urgent production change introduces a regression? -> Have a hotfix process that includes rapid accessibility validation.
    • What to do in the event of a formal or legal complaint?

  -> Activate the response protocol defined with the legal team, which must include an immediate technical evaluation of the reported problem.

Content and/or Media that Convert

Messages, Formats, and Conversions: The Power of an Honest Statement

The accessibility statement itself can be a powerful conversion tool—not for sales, but for building trust. A user with a disability who finds a detailed, honest statement about their limitations and clear information on how to get help is more likely to persevere in the face of a barrier than if they find a legalistic and vague document. The key is sincerity. The main call to action (CTA) is not “Buy,” but “Help us improve: contact us if you encounter a barrier.” This CTA should be prominent and lead to a simple form or an actively monitored email address.

To optimize this content, we can run A/B tests on the language. For example, compare a more formal, corporate tone with a more approachable and direct one to see which generates more constructive feedback. The conversion metrics here aren’t clicks or sales, but rather the quantity and quality of feedback received, and the time spent on the statement page. A key metric is the Feedback Resolution Rate: the percentage of issues reported by users that are effectively resolved within a given timeframe. Improving this metric builds unwavering loyalty. Practical and well-written accessibility statements are, in essence, trustworthy marketing.

Statement Production Workflow

1. Data Collection (Responsible: Accessibility Auditor): Conduct audits and consolidate the results.
2. Analysis and Prioritization (Responsible: Product Manager): Cross-reference audit data with business objectives to create the roadmap.
3. Drafting (Responsible: Content Specialist / UX Writer): Write the statement content in clear and simple language, avoiding technical jargon. Structure it according to the W3C model.
4. Technical Review (Responsible: Technical Lead / Senior Developer): Validate that the problem descriptions and proposed solutions are accurate.
5. Legal Review (Responsible: Legal Department): Ensure that the document complies with all applicable legal requirements.
6. Final Approval (Responsible: Product Owner / Digital Director): Give the go-ahead for publication.
7. Publication and Dissemination (Responsible: Webmaster / Marketing Team): Publish the statement at an easily accessible URL (usually in the footer) and ensure the link is accessible.
8. Feedback Monitoring (Responsible: Support Team / Community Manager): Actively manage the communication channel specified in the statement.

Training and employability

Demand-driven catalog

For an accessibility statement to be sustainable and reflect real-world practice, the organization must internalize the knowledge.

We offer a training catalog designed to empower teams and reduce long-term reliance on external consultants, thereby improving employability and internal skills.

Module 1: Web Accessibility Fundamentals (for all roles). What is accessibility? Who benefits? WCAG (POUR) principles, disability models, and basic assistive technology concepts.

• Module 2: Inclusive Design and Accessible UX (for designers and UX professionals). Color contrast, legible typography, form design, visible focus states, accessible prototyping, and annotations for developers.
• Module 3: Accessible Front-End Development (for developers). Semantic HTML, WAI-ARIA in practice, focus management, accessible component patterns (modals, dropdown menus, carousels), and accessibility unit testing.
• Module 4: Creating Accessible Content (for editors and marketers). Alternative text for images, captions and transcripts for videos, proper use of headings, clear and simple language, and document accessibility (PDF).
• Module 5: QA and Accessibility Testing (for testers). Manual testing methodologies (keyboard navigation, use of basic screen readers), automated tools, and how to effectively report accessibility errors.Methodology

  Our training methodology is eminently practical (“learning by doing”). Each module combines a theoretical foundation with practical workshops where participants work on real components of their own digital product. Assessment is carried out using rubrics that measure the ability to apply the concepts learned. For example, a developer will be assessed on their ability to correct an inaccessible component, and a designer on their ability to create a prototype that meets the criteria for contrast and navigation. At the end of the training cycle, participants not only acquire knowledge but will have directly contributed to improving the product’s accessibility. This translates into a measurable product improvement and an increase in internal skills, creating a virtuous cycle that reinforces the veracity of the accessibility statement.

  Operational Processes and Quality Standards

  From Request to Execution

  A standardized operational process is the backbone that supports a practical accessibility statement. This pipeline ensures that every step, from identifying a problem to resolving it, is traceable, measurable, and consistent.

  1. Diagnostic Phase: Begins with a comprehensive audit or user report. The deliverable is a detailed report with each identified problem, its severity (critical, high, medium, low), the affected WCAG criterion, and the impacted user population. The acceptance criterion is that each issue be reproducible.
  2. Proposal and Planning Phase: The report is translated into tasks in a project management system (e.g., Jira, Azure DevOps). Each task includes a technical description, a suggested solution, and an effort estimate. The deliverable is a prioritized backlog. The acceptance criterion is the Product Owner’s approval of the roadmap.
  3. Pre-Production Phase (Design and Development): The design team adjusts the mockups, and the development team implements the fixes. The deliverables are the updated designs and the pull requests with the code. The acceptance criterion includes design validation against accessibility guidelines and passing automated tests in the CI/CD pipeline.
  4. Execution and QA Phase: The QA team performs manual and assistive technology testing in a pre-production environment. The deliverable is the QA validation report. The acceptance criterion is that there are no regressions and that the fix is ​​effective (100% resolution rate for the original issue).
  5. Closing and Updating Phase: Once the solution is deployed, the task is closed. Periodically (e.g., quarterly), the accessibility statement is updated to reflect the improvements. The deliverable is the new version of the statement. The acceptance criterion is that the published statement accurately reflects the current state of the product.

  Quality Assurance

  Quality assurance is an ongoing process, not a final phase.

  It relies on a combination of people, tools, and processes.

  • • Defined Roles: There is an “Accessibility Champion” on each team, responsible for being the first point of contact and promoting best practices.
    • Incident Escalation: Critical incidents (e.g., a user cannot complete a purchase) have a direct escalation channel that can even halt a deployment.
    • Acceptance Indicators (SLAs):
      • First Response Time to User Feedback: < 24 business hours.
      • Critical Bug Resolution Time: < 3 business days.
      • Accessibility Regression Rate: < 2% per release.

  PhaseDeliverablesControl IndicatorsRisks and MitigationContent Accuracy.Risk: The statement is outdated. Mitigation: Schedule regular reviews as a recurring task on the team’s calendar.

  Accessibility Process Phase Quality Control Table

  Diagnosis	Audit Report	100% coverage of applicable WCAG criteria. False positive rate < 5%.	Risk: Superficial audit. Mitigation: Combine automated tools with expert manual review and user testing.
  Planning	Prioritized Backlog	90% alignment with business objectives. Plan deviation <15%.	Risk: Incorrect prioritization. Mitigation: Use an impact vs. effort matrix and validate with stakeholders.
  Development	Pull Request with fixed code	0 blocking accessibility errors in the CI/CD linter. Accessibility unit test coverage.	Risk: Fix introduces new problems. Mitigation: Peer code reviews with a focus on accessibility.
  QA and Verification	Test Report	100% success rate in test scenarios for fixes. 0 regressions.	Risk: Testing does not cover all use cases or assistive technologies. Mitigation: Define a baseline set of browsers/screen readers and conduct testing with real users periodically.
  Maintenance	Updated Accessibility Statement	Update frequency (minimum semi-annually).

  Application Cases and Scenarios

  Case 1: Fashion E-commerce Platform

  Challenge: A major online retailer detected a high cart abandonment rate (75%) in sessions identified as originating from screen readers. The audit revealed multiple critical barriers: product images without alt text, search filters inaccessible by keyboard, and a checkout process with form fields lacking associated labels and confusing error messages.

  Process and Solution: A 3-month remediation plan was implemented.

  Month 1: The purchase flow was prioritized. Checkout forms were corrected, associating labels with each field, ensuring that error messages were displayed by screen readers, and improving button contrast.

  Month 2: Product and listing pages were addressed. A system was developed to generate descriptive alt text, and filtering components were redesigned to be fully keyboard-operatable.

  Month 3: A validation audit was conducted, and the content team was trained on how to maintain accessibility in new product pages. The accessibility statement was updated to reflect WCAG 2.1 AA compliance across 90% of the site, detailing the remaining areas (e.g., a third-party 3D viewer) as “partially compliant” with an action plan.

  Results and KPIs:

  • Reduction in cart abandonment rate for screen reader users from 75% to 30% (60% improvement).
  • Increase in conversion rate in this segment by 150%.
  • Project ROI: 250% in the first year, calculated from increased sales and reduced support costs.
  • Implementation time: 12 weeks.

  Case 2: Public Administration Services Portal

  Desafío: Un ayuntamiento necesitaba adecuar su portal de trámites al Real Decreto 1112/2018 para evitar sanciones y, sobre todo, para garantizar el acceso a servicios esenciales a todos los ciudadanos. El portal era un laberinto de PDFs inaccesibles, formularios complejos y carecía de una declaración de accesibilidad formal.

  Proceso y Solución: Se abordó el proyecto en dos fases a lo largo de 8 meses.

  Fase 1 (4 meses): Auditoría completa y remediación de los 10 trámites más utilizados. Esto incluyó convertir los PDFs a formularios HTML5 accesibles, simplificar el lenguaje y la estructura de las páginas, y asegurar la compatibilidad con lectores de pantalla y navegación por teclado. Se redactó y publicó una primera versión de la declaración de accesibilidad, calificando el sitio como “parcialmente conforme” y detallando qué trámites ya eran accesibles.

  Fase 2 (4 meses): Se escaló la remediación al resto del portal y se estableció un programa de formación para los funcionarios encargados de subir contenido, con un foco especial en la creación de documentos ofimáticos accesibles. Se implementó un canal de feedback prominente en la declaración.

  Resultados y KPIs:

  • Cumplimiento del 100 % con los requisitos del Real Decreto 1112/2018.
  • Reducción del 40 % en las llamadas al teléfono de atención ciudadana relacionadas con problemas en la web.
  • Net Promoter Score (NPS) del portal incrementado en 35 puntos entre usuarios con discapacidad.
  • Plazo total: 8 meses. El coste total fue de 80.000 €, amortizado en menos de 2 años por el ahorro en costes de atención telefónica y la mejora de la eficiencia.

  Caso 3: Plataforma de e-learning (SaaS B2B)

  Desafío: Una empresa de software de formación online quería vender su plataforma a grandes corporaciones y universidades, las cuales exigían un VPAT (Voluntary Product Accessibility Template) que demostrara conformidad con WCAG 2.1 AA. El reproductor de vídeo de la plataforma no tenía controles accesibles, los contenidos de los cursos no eran navegables por teclado y los cuestionarios eran inutilizables con lectores de pantalla.

  Proceso y Solución: La accesibilidad se integró en su ciclo de desarrollo ágil (2 semanas por sprint).

  Sprint 1-2: Se reconstruyó el reproductor de vídeo con controles accesibles, capacidad para añadir subtítulos y transcripciones.

  Sprint 3-4: Se aseguró que toda la interfaz de navegación del curso (índice, lecciones, recursos) fuera completamente operable por teclado y tuviera una estructura de encabezados lógica.

  Sprint 5-6: Se rediseñaron los componentes de los cuestionarios (opción múltiple, arrastrar y soltar) para que fueran compatibles con WAI-ARIA y anunciaran correctamente la información a los lectores de pantalla.

  Paralelamente, se documentó cada mejora en un borrador del VPAT. Al final del proceso, se generó un VPAT completo y una declaración de accesibilidad pública para su web.

  Resultados y KPIs:

  • Desbloqueo de 3 contratos corporativos por un valor de 500.000 €, que estaban bloqueados por los requisitos de accesibilidad.
  • Reducción del tiempo de desarrollo de nuevas funcionalidades en un 10 % al integrar la accesibilidad desde el principio (“Shift-left”).
  • ADR (Average Deal Rate) incrementado al poder competir en el sector público y corporativo.
  • Mejora de la satisfacción del cliente (CSAT) en un 20 % en las encuestas post-curso.

  Guías paso a paso y plantillas

  Guía 1: Cómo realizar una auditoría rápida de accesibilidad (Checklist Inicial)

  Esta guía no reemplaza una auditoría experta, pero permite identificar problemas evidentes en 30 minutos.

  1. Prueba de teclado:
     • Intenta navegar por toda la página usando solo la tecla `Tab` (para avanzar), `Shift+Tab` (para retroceder) y `Enter` (para activar).
     • Checklist: ¿Puedes ver claramente qué elemento está enfocado en todo momento (un borde resaltado)? ¿Puedes acceder a todos los elementos interactivos (enlaces, botones, campos de formulario)? ¿El orden de navegación es lógico? ¿No te quedas atrapado en ningún componente (una “trampa de teclado”)?
  2. Prueba de contraste de color:
     • Usa una extensión de navegador (como “axe DevTools” o “WAVE”) para analizar el contraste de los textos.
     • Checklist: ¿Todo el texto importante cumple con el ratio de contraste mínimo de 4.5:1 (o 3:1 para texto grande)? ¿Los elementos no textuales (iconos, bordes de campos) tienen un contraste de 3:1?
  3. Prueba de zoom y redimensionamiento:
     • Aumenta el zoom del navegador al 200 %.
     • Checklist: ¿Se pierde contenido o funcionalidad? ¿Aparece una barra de desplazamiento horizontal? El contenido debe reajustarse en una sola columna.
  4. Prueba de imágenes:
     • Usa una extensión para ver los textos alternativos de las imágenes.
     • Checklist: ¿Todas las imágenes que transmiten información tienen un texto alternativo (`alt`) descriptivo? ¿Las imágenes decorativas tienen un `alt` vacío (`alt=””`)?
  5. Prueba de estructura:
     • Usa una extensión para visualizar la jerarquía de encabezados (H1, H2, H3…).
     • Checklist: ¿Hay un solo H1 por página? ¿Los niveles de encabezado son lógicos y no se saltan (p. ej., de un H2 a un H4)?

  Guía 2: Plantilla comentada para una Declaración de Accesibilidad Práctica

  Utiliza esta estructura como base, adaptando el lenguaje para que sea claro y directo.

  1. Compromiso con la accesibilidad:“[Nombre de la Organización] se compromete a hacer su sitio web accesible, de conformidad con [Normativa aplicable, p. ej., Real Decreto 1112/2018]. Esta declaración se aplica a [URL del sitio].”
  2. Estado de cumplimiento:“Este sitio web es parcialmente conforme con [Normativa aplicable] debido a las excepciones y a la falta de conformidad de los aspectos que se indican a continuación.” (Sé honesto: es raro ser 100 % conforme. Otras opciones: “plenamente conforme”, “no conforme”).
  3. Contenido no accesible:“El contenido que se recoge a continuación no es accesible por lo siguiente:”
     • Falta de conformidad con la normativa: “Podrían existir algunos vídeos sin subtítulos [Criterio WCAG 1.2.2] porque fueron publicados antes de nuestra política actual. Estamos trabajando para subtitularlos antes de [Fecha].” (Sé específico sobre el problema, el criterio y el plan).
     • Carga desproporcionada: “No aplica.” (Solo usar en casos muy justificados).
     • El contenido no entra dentro del ámbito de la legislación aplicable: “Podrían existir archivos ofimáticos en PDF publicados antes del 20 de septiembre de 2018 que no cumplan en su totalidad todos los requisitos de accesibilidad.”
  4. Preparación de la presente declaración de accesibilidad:“La presente declaración fue preparada el [Fecha]. El método empleado para preparar la declaración ha sido una autoevaluación llevada a cabo por [o una auditoría externa realizada por] [Nombre de la Empresa]. Última revisión de la declaración: [Fecha].”
  5. Observaciones y datos de contacto:“Puede realizar comunicaciones sobre requisitos de accesibilidad (artículo 10.2.a del RD 1112/2018) como por ejemplo: informar sobre cualquier posible incumplimiento por parte de este sitio web, transmitir otras dificultades de acceso al contenido o formular cualquier otra consulta o sugerencia de mejora relativa a la accesibilidad del sitio web a través del siguiente [Enlace al formulario de contacto] o enviando un correo a [dirección de correo]. Nos comprometemos a responder en un plazo de [p. ej., 2 días laborables].”
  6. Procedimiento de aplicación:“Si una vez realizada una solicitud de información accesible o queja, esta hubiera sido desestimada… podrá iniciar una reclamación…” (Incluir el procedimiento oficial que marque la ley).

  Guía 3: Proceso de gestión del feedback de accesibilidad

  1. Paso 1: Acuse de recibo automático. El usuario recibe un correo electrónico instantáneo confirmando que su mensaje ha sido recibido y que se le dará una respuesta personalizada en un plazo X (p. ej., 24-48 horas).
  2. Paso 2: Triaje y registro. Un responsable de soporte analiza el mensaje. ¿Es una duda, una sugerencia o un reporte de error? Lo registra en un sistema de tickets con la etiqueta “Accesibilidad” e intenta reproducir el problema.
  3. Paso 3: Respuesta personalizada. Se envía una respuesta al usuario agradeciéndole el reporte, confirmando si se ha podido reproducir el problema y explicando los siguientes pasos. Se le proporciona un número de ticket para seguimiento.
  4. Paso 4: Creación de la incidencia técnica. El ticket de soporte se convierte en una incidencia en el backlog del equipo de desarrollo, vinculada al ticket original. Se prioriza según el impacto.
  5. Paso 5: Resolución y validación. El equipo de desarrollo soluciona el problema. QA valida que la corrección es efectiva y no introduce regresiones.
  6. Paso 6: Comunicación de cierre. El responsable de soporte contacta de nuevo al usuario para informarle de que el problema ha sido resuelto y agradeciéndole de nuevo su contribución. Este paso es VITAL para generar confianza.
  7. Paso 7: Análisis de tendencias. Trimestralmente, se analizan todos los tickets de accesibilidad para identificar problemas recurrentes que puedan indicar una necesidad de formación o un cambio de proceso.

  Recursos internos y externos (sin enlaces)

  Recursos internos

  • Guía de Estilo de Contenido Accesible.
  • Biblioteca de Componentes de UI Accesibles (basada en el sistema de diseño).
  • Plantilla para la “Definition of Done” (DoD) que incluye criterios de accesibilidad.
  • Checklist de accesibilidad para QA.
  • Actas de las reuniones del Comité de Accesibilidad.

  Recursos externos de referencia

  • Web Content Accessibility Guidelines (WCAG) 2.1 y 2.2 del W3C.
  • Norma Europea EN 301 549.
  • Real Decreto 1112/2018, de 7 de septiembre (legislación española).
  • Guías de WAI-ARIA (Accessible Rich Internet Applications) del W3C.
  • Metodología de Evaluación de Conformidad de Accesibilidad Web (WCAG-EM).
  • Herramientas de evaluación: axe-core, WAVE, Accessibility Insights for Web, NVDA, JAWS, VoiceOver.

  Preguntas frecuentes

  ¿Es posible alcanzar una accesibilidad del 100 %?

  En la práctica, es extremadamente difícil, si no imposible, garantizar una conformidad del 100 % en todo momento, especialmente en sitios web grandes y dinámicos con contenido de terceros. Por eso, el objetivo es la “conformidad sustancial” y la mejora continua. Una declaración de accesibilidad honesta reconoce esto y se enfoca en la transparencia sobre las áreas problemáticas y el compromiso de solucionarlas, en lugar de afirmar una perfección inalcanzable.

  ¿Cuál es la diferencia entre una política de accesibilidad y una declaración de accesibilidad?

  Una política de accesibilidad es un documento interno de alto nivel que establece el compromiso de la organización con la accesibilidad, define roles y responsabilidades y marca los objetivos generales. La declaración de accesibilidad es un documento público y específico para un producto digital concreto (un sitio web o una app), que detalla su nivel de conformidad actual, los problemas conocidos y cómo los usuarios pueden reportar barreras. La declaración es la manifestación pública de la política.

  ¿Con qué frecuencia debo actualizar mi declaración de accesibilidad?

  Como mínimo, una vez al año. Sin embargo, una buena práctica es revisarla y, si es necesario, actualizarla después de cada rediseño importante, al añadir funcionalidades significativas o al completar un ciclo de remediación importante. Una declaración con una fecha de revisión de hace dos años envía un mensaje de abandono. Las declaraciones de accesibilidad prácticas son documentos vivos.

  ¿Las herramientas de auditoría automática son suficientes para validar la accesibilidad?

  No. Las herramientas automáticas son excelentes para detectar entre el 30 % y el 40 % de los problemas de accesibilidad (como falta de contraste, textos alternativos ausentes o errores de ARIA). Sin embargo, no pueden evaluar aspectos que requieren cognición humana, como si un texto alternativo es realmente descriptivo, si el orden de navegación es lógico o si un proceso es usable. Son un complemento necesario, pero nunca un sustituto, de la auditoría manual experta y las pruebas con usuarios reales.

  Tengo un presupuesto limitado. ¿Por dónde empiezo a mejorar la accesibilidad?

  Aplica el principio 80/20. Comienza con los “low-hanging fruits” (frutos maduros) que tienen un alto impacto. Esto suele incluir: asegurar que todo es operable por teclado, corregir los problemas de contraste de color, añadir textos alternativos a las imágenes informativas, usar correctamente los encabezados y garantizar que los campos de formulario tienen etiquetas. Estos cambios básicos solucionan una gran parte de las barreras más comunes y severas.

  Conclusión y llamada a la acción

  Hemos recorrido el camino que transforma una declaración de accesibilidad de una formalidad legal a un activo estratégico. La clave es el cambio de mentalidad: verla no como un escudo, sino como un puente hacia los usuarios. Las declaraciones de accesibilidad prácticas se fundamentan en procesos sólidos, auditorías honestas, un compromiso de mejora continua y, sobre todo, una comunicación transparente. Al adoptar este enfoque, las organizaciones no solo minimizan sus riesgos legales, sino que abren sus puertas a un mercado más amplio, mejoran la experiencia de todos los usuarios y construyen una marca que se percibe como inclusiva y digna de confianza. El retorno de la inversión se mide en KPIs tangibles como el aumento de la conversión, la reducción de costes de soporte y la mejora del NPS.

  El próximo paso es accionable: no espere a una queja o a un rediseño completo. Realice hoy mismo la auditoría rápida descrita en nuestras guías. Identifique una barrera, por pequeña que sea, corríjala y actualice su declaración para reflejar esa mejora. Ese es el primer paso para convertir su declaración en un documento vivo que demuestre un compromiso real y continuo con la accesibilidad para todos.

  Glosario

  A11Y

  Acrónimo de “Accessibility” (accesibilidad). El número 11 representa las once letras entre la ‘a’ y la ‘y’.

  WAI-ARIA

  Acronímo de “Web Accessibility Initiative – Accessible Rich Internet Applications”. Es una especificación técnica del W3C que proporciona un marco para mejorar la accesibilidad de contenido dinámico y componentes de interfaz de usuario avanzados.

  WCAG

  Acrónimo de “Web Content Accessibility Guidelines” (Pautas de Accesibilidad para el Contenido Web). Es el estándar internacionalmente reconocido para la accesibilidad web, publicado por el W3C. Se organiza en tres niveles de conformidad: A (el más bajo), AA (el estándar de referencia para la mayoría de las legislaciones) y AAA (el más alto).

  Lector de pantalla (Screen Reader)

  Software utilizado por personas con discapacidad visual para interpretar y comunicar el contenido de una pantalla a través de voz sintetizada o una línea braille.

  VPAT (Voluntary Product Accessibility Template)

  Es un documento que evalúa cuán accesible es un producto en particular de acuerdo con los estándares de accesibilidad. Es comúnmente utilizado en procesos de adquisición en el sector público y corporativo, especialmente en Estados Unidos.

  Conformidad Parcial

  Término utilizado en las declaraciones de accesibilidad para indicar que un sitio web cumple con la mayoría de los requisitos de accesibilidad, pero existen algunas partes o contenidos que no son totalmente conformes. La declaración debe especificar cuáles son esas partes y por qué.