Gestionar l'execució: seguiment, canvis, garantia i final del contracte

L'accessibilitat d'un servei digital es degrada amb el temps si ningú no en té cura: cada nova versió, cada component de tercers que s'integra i cada contingut que es publica poden introduir barreres. A la lliçó anterior vas veure com fer el seguiment de les fites i organitzar les proves d'acceptació. Aquesta lliçó s'ocupa del que passa al voltant i després: qui vigila l'accessibilitat durant l'execució, com s'integra en cada lliurament, què passa amb els subcontractistes i els components externs, com es gestionen els canvis normatius i les queixes, i com es tanca el contracte sense perdre el que s'ha aconseguit.

La persona responsable del contracte i el seguiment

L'article 62 de la LCSP obliga a designar una persona responsable del contracte, a qui correspon supervisar-ne l'execució i dictar les instruccions necessàries per assegurar la realització correcta de la prestació. Aquesta persona poques vegades és especialista en accessibilitat, de manera que convé que compti amb el suport de la unitat responsable d'accessibilitat i que el tema sigui un punt fix de les reunions de seguiment, recolzat en indicadors que l'adjudicatari aporta en cada informe:

Indicador	Què revela
Incidències d'accessibilitat obertes, per criticitat	El volum pendent i la seva gravetat
Temps mitjà de correcció davant del termini del plec	Si es compleixen els compromisos i escau aplicar penalitats
Regressions per lliurament (errors que tornen)	Si hi ha un control de qualitat real abans de cada lliurament
Queixes ciutadanes traslladades i el seu estat	Si l'entitat podrà respondre dins de termini

Accessibilitat en cada lliurament: la definició de fet

En els projectes amb metodologies àgils, el contracte s'executa en iteracions curtes i la verificació per fites que vas veure a la lliçó 4 s'ha de traduir al ritme de l'equip. L'eina és la definició de fet (definition of done): les condicions que ha de complir qualsevol història d'usuari per considerar-se acabada. Si l'accessibilitat en forma part, cada lliurament la incorpora; si no, s'acumula com a deute per al final. El plec pot exigir que la definició de fet inclogui criteris d'accessibilitat i que l'adjudicatari la lliuri a l'inici perquè s'aprovi.

Compara dos criteris d'acceptació per a la mateixa història d'usuari:

Criteri insuficient:
- El formulari de sol·licitud compleix les WCAG.

Criteri verificable:
- Tots els camps tenen una etiqueta visible associada i un nom accessible
  igual al text visible o que el conté (2.5.3 Etiqueta en el nom).
- El formulari es completa i s'envia només amb teclat; el focus és
  visible i no queda ocult per la barra fixa (2.4.7, 2.4.11).
- En enviar amb errors, s'identifiquen en text, s'anuncien al lector
  de pantalla i el focus va al primer error (3.3.1, 4.1.3).
- No es tornen a demanar dades ja aportades en el pas anterior
  (3.3.7 Entrada redundant).
- Provat amb NVDA + Firefox i VoiceOver + Safari a iOS; sense errors
  d'axe-core a la integració contínua.

El segon criteri es comprova en minuts. Combina eina automàtica i prova manual perquè, com saps des del nivell 4, les eines només detecten una part dels problemes.

Subcontractistes i components de tercers

L'article 215 de la LCSP permet subcontractar, amb els límits i comunicacions que estableixin els plecs, i deixa clar que els subcontractistes només queden obligats davant del contractista principal, que assumeix la total responsabilitat de l'execució davant de l'Administració. Per a l'accessibilitat, això vol dir que l'adjudicatari no es pot excusar en el fet que la part inaccessible la va fer una altra empresa: respon de tot el que ha lliurat.

Més delicats són els components de tercers: passarel·la de pagament, mapa, cita prèvia, xat, reproductor de vídeo, avís de galetes, verificació antibots. D'aquí provenen molts incompliments greus. El plec ha d'exigir que l'adjudicatari avaluï qualsevol component extern abans d'integrar-lo, obtingui la conformitat de la persona responsable del contracte i, si no hi ha cap alternativa accessible, ho documenti per a la declaració d'accessibilitat.

Canvis normatius, modificacions i pròrrogues

Un contracte de manteniment pot durar diversos anys, i en aquest temps les normes evolucionen: les WCAG 2.2 ja s'exigeixen expressament en els plecs ben redactats i l'EN 301 549 v4.1.1 (PDF, s'obre en una finestra nova), que les incorpora, es va publicar el setembre de 2026 i està pendent de citació al DOUE. Si el plec no ho preveu, adaptar el servei a una nova versió harmonitzada es pot presentar com una feina nova, amb el seu cost. Hi ha dues maneres d'anticipar-s'hi:

• Incloure l'adaptació en l'obligació de manteniment: l'adjudicatari adaptarà el servei a la versió de la norma que es publiqui com a harmonitzada durant l'execució, dins de l'esforç de manteniment ofertat.
• Preveure una modificació: l'article 204 permet les modificacions previstes en el plec, formulades de manera clara, precisa i inequívoca, amb un límit del vint per cent del preu inicial. Es pot reservar per a adaptacions de més abast.

La pròrroga (article 29) l'acorda l'òrgan de contractació: abans de prorrogar, revisa l'historial d'incidències, terminis i queixes d'accessibilitat.

Queixes ciutadanes i resultats de l'Observatori

Durant el contracte arribaran comunicacions pel mecanisme del RD 1112/2018 (PDF, s'obre en una finestra nova) i resultats de l'Observatori d'Accessibilitat Web. L'entitat ha de respondre les sol·licituds i queixes dins de termini (vint dies hàbils segons el RD 1112/2018, o el que fixi la seva administració), i per això necessita que l'adjudicatari analitzi cada cas amb rapidesa. El plec li ha de fixar un termini d'anàlisi clarament inferior (per exemple, cinc dies hàbils per diagnosticar i proposar una data de correcció) i un termini de correcció segons la criticitat. Una queixa d'una persona que no pot completar un tràmit és, per definició, una incidència crítica.

Garantia i final del contracte

L'article 210 de la LCSP preveu un termini de garantia comptat des de la recepció, durant el qual el contractista respon dels defectes del que ha lliurat. Perquè les no conformitats d'accessibilitat descobertes en aquest període (per una queixa, per l'Observatori o per una auditoria posterior) es corregeixin sense cost, el plec les ha de qualificar com a defectes i fixar-ne els terminis. I si l'accessibilitat s'ha configurat com a obligació essencial o com a condició especial d'execució (article 202), el seu incompliment greu i reiterat pot portar a la resolució, d'acord amb l'article 211.

En acabar el contracte, l'entitat s'ha de quedar amb el que necessita per mantenir l'accessibilitat amb un altre proveïdor o amb mitjans propis. L'article 308 estableix que, tret que el plec disposi una altra cosa, els contractes de serveis que desenvolupen productes protegits per propietat intel·lectual comporten la seva cessió a l'Administració. Lliurables finals que el plec ha d'exigir:

• Codi font i biblioteca de components amb la seva documentació d'accessibilitat (rols, comportament amb teclat, anuncis).
• Guia d'estil amb els tokens de color i tipografia que compleixen els contrastos.
• Últim informe de conformitat per requisit i relació d'incidències pendents.
• Proves automàtiques configurades i casos de prova manuals reutilitzables.
• Sessió de traspàs de coneixement al nou equip.

Resum

• La persona responsable del contracte ha de fer el seguiment de l'accessibilitat amb indicadors: incidències per criticitat, temps de correcció, regressions, queixes i components de tercers.
• En projectes àgils, l'accessibilitat entra en la definició de fet amb criteris d'acceptació verificables, que combinen proves automàtiques i manuals.
• El contractista respon del que facin els seus subcontractistes; els components de tercers s'han d'avaluar abans d'integrar-los.
• Els canvis normatius s'anticipen en el plec, com a obligació de manteniment o com a modificació prevista; les queixes necessiten terminis d'anàlisi compatibles amb els vint dies hàbils de resposta.
• En garantia, les no conformitats són defectes; en el tancament, l'entitat ha de rebre codi, components, guia, informe i traspàs de coneixement.