El importe del plan de mejora en sí suele ser limitado: es el documento con la lista priorizada de problemas, los plazos asociados y la justificación de por qué algo es o no urgente. Los costes reales están en el siguiente paso, en la adaptación efectiva del sitio web, tienda online o aplicación por parte de un desarrollador. Y ese importe varía enormemente, dependiendo de varios factores que se analizan a continuación.
Lo que principalmente lo determina no es el número de problemas encontrados sino el tipo de problema y dónde se encuentra. Un contraste de color faltante en unos pocos encabezados se puede resolver en una tarde. Un proceso de pago que no se puede utilizar con teclado suele afectar el código subyacente de un componente pagado o personalizado, y eso requiere notablemente más tiempo. El plan de mejora especifica qué debe hacerse y en qué orden; no dice cuántas horas necesita un desarrollador, ya que eso depende de cómo esté construido el sitio.
De dónde procede el importe
La mayoría de presupuestos para corregir problemas de accesibilidad se dividen en tres partes: el tiempo para entender el problema, el tiempo para resolverlo y el tiempo para verificar que la solución funciona con un lector de pantalla o solo con teclado. Esta última parte a menudo se olvida en una estimación inicial, pero es precisamente donde el trabajo de corrección se alarga: un botón que se ve bien visualmente aún puede no comunicar su función a la tecnología de asistencia.
Un segundo factor de coste es la plataforma en sí. Una tienda online en una plataforma estándar con temas bien mantenidos a menudo ya tiene una parte de la base en orden, como la estructura correcta de encabezados y el orden de enfoque básico. Un sitio empresarial con un entorno de inicio de sesión personalizado o un flujo de pedido propio a veces carece completamente de esa base, y entonces no se trata de ajustar configuraciones sino de reescribir componentes. revisar por situación qué se evalúa exactamente da una idea de qué partes de un sitio suelen requerir más trabajo.
Un tercer factor es quién realiza el trabajo. Los desarrolladores internos que ya conocen el código suelen ser más rápidos que una parte externa que primero debe averiguar cómo funciona todo. A la inversa, una parte externa que realiza este tipo de trabajo de corrección con frecuencia tiene una ventaja en la experiencia con exactamente este tipo de defectos, como etiquetas de formulario o textos alternativos que faltan de manera sistemática.
Lo que no reduce el coste
Un widget de accesibilidad que pretende mejorar el sitio en un clic no resuelve ninguno de estos problemas subyacentes y, por lo tanto, tampoco reduce los costes reales. Tal superposición añade una capa en la parte frontal del sitio, pero el código subyacente, las etiquetas de formulario, el orden de enfoque, permanece sin cambios. Las autoridades de supervisión y el propio texto legal se basan en la accesibilidad real del servicio subyacente, no en lo que un widget promete hacer. Quien confía en esto solo pospone los costes del trabajo de corrección real.
Otro malentendido es que todo debe corregirse de una vez para ahorrar costes en la tarifa por hora. En la práctica, un enfoque por fases suele ser más económico, porque los problemas más graves — por ejemplo, un proceso de pago que no se puede completar con un lector de pantalla — se resuelven primero, mientras que puntos menores como el contraste de color se incluyen en un ciclo de mantenimiento regular. Eso es exactamente donde una lista de acciones priorizada en lenguaje sencillo añade valor: los desarrolladores saben entonces por dónde empezar primero, en lugar de abordarlo todo a la vez.
Qué hace y qué no hace axessia
Axessia elabora la lista de acciones, registra qué se ha evaluado y supervisa si una modificación del sitio requiere una nueva evaluación. El trabajo de reparación real, escribir nuevo código o adaptar un tema, corresponde a su propio desarrollador o agencia. Esta distinción es deliberada: una exploración automática no puede evaluar parte de los requisitos, y la realización de reparaciones requiere conocimiento de su plataforma específica que una exploración no tiene.
Quien quiera saber qué parte de los costos es realmente relevante para su situación, comienza con la pregunta de si la ley le es aplicable. obtener en unas pocas preguntas una indicación inicial muestra si se aplica una exención, por ejemplo para microempresas, antes de pensar en costos de reparación. Para quien ya sabe que la ley es aplicable y tiene curiosidad por saber qué cuesta el propio informe y declaración de axessia, eso es independiente del trabajo de reparación en el resumen de suscripciones y qué incluyen.
¿Sigue teniendo dudas sobre una parte de su sitio, o quiere saber cómo se realizó una evaluación anterior antes de contratar a un desarrollador? consultar de dónde procede la evaluación explica qué fuentes se utilizan en el proceso.
La exploración rápida gratuita ofrece una primera visión sobre un puñado de páginas clave de dónde están los mayores problemas, sin necesidad de cuenta alguna. Este es un buen punto de partida para estimar cuánto trabajo de reparación aproximadamente le espera, antes de solicitar un presupuesto a un desarrollador.