Come convalidare xhtml?

Come validare XHTML significa verificare che un documento rispetti due livelli di regole: la sintassi XML e il suo DTD o schema dichiarato. XHTML 1.0 è una riformulazione di HTML 4.01 in XML, quindi un documento può essere ben formato ma non valido, come quando <a target="_blank"> appare in XHTML 1.0 Strict.

Convalidare XHTML significa verificare che un documento rispetti contemporaneamente due livelli di regole:

1. Regole di sintassi XML: tag annidati correttamente, attributi tra virgolette, chiusura obbligatoria di tutti gli elementi (compresi quelli vuoti come <br />), un singolo elemento radice, una codifica dichiarata coerente, ecc.
2. Regole DTD o schema dichiarato: quali elementi e attributi esistono, in quale contesto possono apparire e quali valori sono consentiti. Ecco i classici DTD di XHTML 1.0 (Strict, Transitional, Frameset), XHTML 1.1, XHTML Basic e XHTML Modularization.

Un documento può essere XML ben formato ed essere comunque non valido: ad esempio, se si utilizza <a target="_blank"> in XHTML 1.0 Strict, la sintassi è impeccabile ma l’attributo target non esiste in quel DTD. Questa distinzione tra ben formato e valido è la principale causa di confusione quando qualcuno vede un errore e non ne capisce il motivo.

È inoltre opportuno ricordare che XHTML 1.0 è una riformulazione dell’HTML 4.01 in XML, definita dal W3C. Oggi, il suo valore pratico è duplice: serve per progetti legacy che vengono ancora serviti come application/xhtml+xml o text/html, e serve come disciplina mentale per scrivere markup pulito. Se desideri il contesto normativo completo su come convalidare XHTML, la especificación de XHTML 1.0 del W3C è la fonte primaria.

I validatori che valgono la pena (e quando usare ognuno)

Non esiste un unico validatore “corretto”. La scelta dipende dal fatto che si stia validando un frammento, una pagina di produzione, un intero sito o un documento che è già XHTML5.

Strumento	Cosa valida	Ideale per	Limitazione principale
W3C Markup Validation Service (validator.w3.org)	XHTML 1.0/1.1, HTML4, HTML5	Convalida puntuale per URL, file o inserimento diretto	Il “Nu Html Checker” moderno dà priorità a HTML5; i DTD obsoleti richiedono la selezione manuale
Nu Html Checker (vnu)	HTML5 e XHTML5	Nuovi progetti, convalida locale e in CI	Non valida i DTD classici di XHTML 1.x
Validatori locali (vnu.jar, tidy)	In base alla configurazione	Automazione, pre-commit, pipeline	Richiede l’installazione di Java o binari; configurazione iniziale
xmllint	Ben formato XML e convalida contro DTD/XSD	Verificare lo strato XML puro	Non conosce regole specifiche di HTML oltre allo schema
Estensioni browser / IDE	Markup in tempo reale	Feedback immediato durante la scrittura	Spesso utilizzano motori obsoleti o incompleti

Il W3C Markup Validation Service

Rimane il punto di partenza per coloro che si chiedono come validare XHTML. Supporta tre modalità: Convalida tramite URI, Convalida tramite caricamento file e Convalida tramite input diretto. Per l’XHTML classico, il trucco sta nel menu a discesa Document Type: se il tuo documento dichiara il proprio DTD tramite il DOCTYPE, il validatore lo rispetta; in caso contrario, è necessario forzarlo manualmente.

Correlato: UserWay — Widget di accessibilità con piano gratuito per empezar hoy mismo.

Un dettaglio di cui molti non sono a conoscenza: il moderno validatore W3C si affida al Nu Html Checker, che comprende HTML5 e XHTML5 ma tratta i vecchi DTD con minore priorità. Per XHTML 1.0 Strict funziona ancora, ma è consigliabile verificare che il risultato rifletta il DTD atteso e non un’interpretazione permissiva.

Nu Html Checker (vnu)

Questo è il validatore che il W3C stesso utilizza internamente. Esiste come servizio web, come eseguibile JAR e come immagine Docker. Il suo grande vantaggio è che puoi eseguirlo localmente e in integrazione continua, cosa essenziale se gestisci un sito di grandi dimensioni. Per XHTML servito come application/xhtml+xml, vnu rileva errori di nidificazione e di attributo che un validatore HTML tollerante lascerebbe passare.

xmllint

Se la tua preoccupazione è il puro livello XML — ad esempio, perché generi XHTML da template XSLT — allora xmllint è insostituibile. Con --noout --valid documento.xhtml verifica la correttezza formale e la validità rispetto al DTD referenziato. È veloce, scriptabile e non dipende dalla rete.

Vale la pena dare un'occhiata: AudioEye — Accessibilità gestionale: automatizzazione combinata con revisione umana.

Convalida nell’editor

Le estensioni per VS Code, i plugin IDE e gli strumenti da riga di comando offrono un feedback immediato. Sono convenienti, ma tendono a rimanere indietro rispetto agli standard. Usali come prima linea di difesa, mai come unica verifica.

Come convalidare XHTML passo dopo passo

1. Dichiarare correttamente il DOCTYPE e la codifica

Il DOCTYPE determina rispetto a quali regole viene effettuata la convalida. Per XHTML 1.0 Strict:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="es" lang="es">
<head>
  <meta http-equiv="Content-Type"
        content="application/xhtml+xml; charset=UTF-8" />
  <title>Esempio valido</title>
</head>

Due errori classici qui: dimenticare l’attributo xmlns (obbligatorio in XHTML) e dichiarare una codifica nel meta che non coincide con il file reale. Il validatore rileva entrambi, ma il secondo a volte si manifesta solo come caratteri corrotti.

2. Verificare la correttezza formale (well-formedness) prima della validità

Prima di combattere con il DTD, assicurati che l’XML sia ben formato. xmllint --noout archivo.xhtml te lo dirà in pochi secondi. Se fallisce qui, nessun validatore DTD ti aiuterà: prima chiudi i tag, correggi la nidificazione ed effettua l’escape delle entità (&, <, >).

3. Convalidare rispetto al DTD

Con il documento ben formato, passalo attraverso il Validatore W3C o vnu. Analizza non solo quanti errori ci sono, ma di che tipo. Un singolo errore di nidificazione può generare una cascata di errori secondari che scompaiono correggendo il primo.

4. Convalidare l’intero sito, non solo la home

Un errore comune è convalidare la pagina principale e presumere che il resto sia corretto. Template, componenti e pagine generate dinamicamente spesso introducono markup non valido. Automatizza: scansiona gli URL principali con uno script ed esegui vnu su ogni risposta.

Correlato: IAAP CPACC / WAS Certification — La certificazione professionale che accredita la tua esperienza di accessibilità.

5. Integrare la convalida nel proprio flusso

La convalida manuale non è scalabile. Aggiungi un passaggio di convalida nella tua pipeline (hook pre-commit, build task o job CI) che fallisca se appare un nuovo errore. In questo modo, il markup non valido non raggiungerà mai la produzione.

Interpretare gli errori: quelli che vedrai più e più volte

• “end tag for X omitted, but OMITTED end tags are not allowed”: tipico di <li>, <p> o <td> senza chiusura. In XHTML, tutto deve essere chiuso.
• “there is no attribute X”: l’attributo non esiste nel tuo DTD. Casi comuni: target, name in alcuni elementi, attributi data-* in XHTML 1.0 (non presenti nel DTD classico).
• “element X undefined”: utilizza un elemento che il tuo DTD non prevede, spesso a causa della copia di markup HTML5 in un documento XHTML 1.0.
• “character data is not allowed here”: contenuto testuale dove il DTD prevede solo elementi, o un & senza escape.
• “reference to entity X for which no system identifier could be generated”: entità HTML nominate che non sono definite in XML (ad esempio   senza dichiarazione). In XHTML puro usa   o dichiara l’entità.

La regola d’oro su come convalidare XHTML: correggere dall’alto verso il basso. Il primo errore è solitamente la causa; i successivi ne sono la conseguenza.

XHTML5: la sfumatura che cambia le regole

Se servite XHTML5 — XHTML serializzato secondo la sintassi HTML5 — le regole cambiano. Non esiste più un DTD: la conformità è definita nella specifica HTML di WHATWG e nelle specifiche W3C su HTML. Il validatore corretto è Nu Html Checker, non il classico validatore DTD.

Se stai facendo acquisti: accessiBe — Sovrapposizione di IA che promette il completamento del WCAG in 48 ore.

Differenze pratiche da tenere a mente riguardo a come convalidare XHTML:

• Gli attributi data-* sono validi in XHTML5, non in XHTML 1.0.
• Il DOCTYPE è semplificato in <!DOCTYPE html>.
• La convalida viene effettuata rispetto al conformance checker di HTML5, che è più permissivo in alcuni punti e più severo in altri (ad esempio, nell’uso di certi elementi obsoleti).

Scegliere tra XHTML 1.0 e XHTML5 non è solo una questione tecnica: se il tuo progetto è nuovo, XHTML5 con convalida vnu è la strada più sensata. Se mantieni un sistema legacy con DTD, rimani in XHTML 1.0 e convalida rispetto al suo DTD.

Convalida e accessibilità: due livelli distinti

Un errore comune è credere che un documento valido sia automaticamente accessibile. Non è così. La convalida verifica la sintassi e la conformità allo schema; l’accessibilità viene valutata rispetto alle WCAG del W3C, che coprono percezione, operabilità e compatibilità con le tecnologie assistive.

Detto questo, esiste una reale sovrapposizione: un markup non valido implica solitamente una struttura carente (intestazioni mal nidificate, liste interrotte, moduli senza etichette corrette), e questo influisce sull’accessibilità. La strategia sensata su come convalidare XHTML e altri documenti è convalidare prima (eliminare il rumore strutturale) e effettuare l’audit di accessibilità dopo con strumenti come axe, Lighthouse o revisioni manuali. La convalida è una condizione necessaria, ma non sufficiente.

Errori frequenti nella convalida di XHTML

Quando impari come convalidare XHTML, evita questi errori comuni:

• Convalidare solo la home. Il markup problematico si trova solitamente nei template interni.
• Ignorare la codifica. Un charset dichiarato male produce errori fantasma.
• Confondere ben formato con valido. Sono livelli distinti; risolvili in ordine.
• Usare il validatore sbagliato. vnu per XHTML5, DTD per XHTML 1.x.
• Correggere gli errori a cascata senza leggere il primo. Si perde tempo e si curano i sintomi.
• Nessuna automazione. La convalida manuale non sopravvive al secondo sprint.
• Presumere che valido = accessibile. Sono standard diversi con scopi diversi.

Punti chiave

• Convalidare XHTML comporta due livelli: correttezza formale XML (well-formedness) e conformità al DTD o schema dichiarato.
• Il W3C Markup Validation Service e il Nu Html Checker (vnu) sono gli strumenti di riferimento su come convalidare XHTML; xmllint copre il puro livello XML.
• Per XHTML 1.0/1.1, usa la convalida rispetto al DTD; per XHTML5, usa vnu e dimentica i DTD classici.
• Correggi gli errori dall’alto verso il basso: il primo solitamente causa i successivi.
• Automatizza la convalida nella tua pipeline; la revisione manuale non è scalabile.
• Valido non è sinonimo di accessibile: sono standard complementari, non equivalenti.

Fonti e ulteriori letture

• XHTML — Wikipedia: Extensible HyperText Markup Language (XHTML) is part of the family of XML markup languages which mirrors or extends versions of the widely used HyperText Markup…
• XHTML Basic — Wikipedia: XHTML Basic is an XML-based markup language designed for simple user agents with limited computing power, such as early mobile phones, PDAs, pagers, and set-top…

Domande frequenti

Qual è la differenza tra XHTML ben formato e XHTML valido?

Un documento ben formato segue le regole sintattiche di XML: tag chiusi, nidificazione corretta e attributi tra virgolette. Un documento valido, inoltre, rispetta il DTD o lo schema che dichiara: utilizzando solo elementi e attributi consentiti nel suo contesto. Puoi avere un documento ben formato ma non valido, ad esempio se utilizzi un attributo che non esiste in XHTML 1.0 Strict.

Ha ancora senso convalidare XHTML nel 2024?

Sì, per due motivi. Primo, molti progetti legacy continuano a servire XHTML e devono rimanere validi per non rompersi in modalità XML. Secondo, la convalida è una disciplina che rileva errori strutturali che influiscono sull’accessibilità e sulla manutenzione. Se il tuo progetto è nuovo, probabilmente usa HTML5 o XHTML5, ma l’abitudine di convalidare rimane comunque preziosa.

Quale validatore devo usare per XHTML5?

Nu Html Checker (vnu), disponibile come servizio web, JAR eseguibile e immagine Docker. È lo stesso motore che utilizza il moderno W3C Markup Validation Service e comprende la sintassi HTML5 e la sua serializzazione XHTML. Non usare i classici validatori DTD per XHTML5: non riconosceranno gli attributi data-* o altre funzionalità di HTML5.

Perché il validatore del W3C mi dà errori che non capisco?

Perché molti errori sono la conseguenza di uno precedente. Una nidificazione errata può generare decine di messaggi secondari. La strategia corretta è correggere il primo errore, convalidare di nuovo e ripetere. Accade anche che il validatore applichi il DTD dichiarato nel DOCTYPE; se quel DTD non è quello che ti aspettavi, gli errori sembreranno arbitrari.

Posso convalidare XHTML dalla riga di comando?

SÌ. Se ti stai chiedendo come convalidare XHTML tramite CLI, xmllint --noout --valid archivo.xhtml verifica la correttezza e la validità rispetto al DTD. Per HTML5/XHTML5, vnu.jar archivo.xhtml fa lo stesso. Entrambe le opzioni sono ideali per l’integrazione in script di build, hook di pre-commit o processi di integrazione continua, in cui la convalida manuale non è scalabile.

Un sito XHTML valido è automaticamente accessibile?

No. La validazione controlla la conformità sintattica e dello schema; l’accessibilità viene valutata rispetto alle WCAG, che coprono aspetti come il contrasto, la navigazione tramite tastiera, il testo alternativo o la struttura semantica. Un documento può essere perfettamente valido e tuttavia rimanere inaccessibile. Convalidare prima e controllare l’accessibilità dopo: sono livelli complementari.