In la prima parte di questa serie abbiamo esaminato i difetti che portano agli elementi strutturali nuovi in ​​HTML5; in la seconda parte della serie abbiamo esaminato in dettaglio le conseguenze di tali carenze; in questa parte finale cercheremo una via da seguire e trarremo alcune conclusioni sullo stato attuale del gioco.

Questo non è un problema astratto: le persone devono effettivamente insegnare queste cose. La prossima generazione di web designer e sviluppatori verrà insegnata con HTML5 come punto di partenza. Mi dispiace per chiunque debba cercare di spiegare delineando e sezionando il raccolto attuale e futuro degli studenti. Forse staranno saggiamente nel semplice formato che abbiamo, che funziona ancora bene: usare i div con ID o classi.

È ragionevole suggerire che forse gli agenti utente in futuro, come i browser e gli screen reader, faranno di più con gli elementi strutturali di HTML5, e questo li renderà più appetibili per noi come autori.

Bruce Lawson di Opera ha suggerito proprio questo sul Mailing list WHATWG nel 2009 :

Dopotutto, non conosco agenti utente che possano usare il tempo, la sezione, il piè di pagina, il datagrid, ecc., Ma per lo più ci aspettiamo che ci sia presto.

Ed ecco cosa Hickson, l'editor HTML5, ha risposto in risposta:

Io non. La maggior parte dei nuovi elementi ha lo scopo di semplificare lo styling, in modo da non dover utilizzare le classi.

Tutto ciò e l'editor non vede gli user-agent nemmeno utilizzare questi elementi. Sono lì, dice, per salvarci dall'usare le classi. In altre parole, il creatore di questi elementi sembra incerto sul motivo per cui sono persino nelle specifiche, salvo "rendere lo styling più semplice".

Abbiamo bisogno di più semantica in HTML?

C'è una scuola di pensiero che dice che abbiamo solo bisogno di una manciata di nuove semantiche. Dopotutto, le specifiche diventerebbero gonfiate se ci fossero decine o centinaia di nuovi termini aggiunti.

Da una parte, sono d'accordo. In termini di strutturazione di una pagina Web di base, direi che staremmo meglio senza gli elementi di sezione HTML. Quello che una volta era un semplice esercizio nell'utilizzo di div è diventato un complicato caos in HTML5 senza alcun guadagno netto.

Tuttavia, in termini di semantica in generale, ci sono casi in cui è possibile aggiungere più significato in cima alla struttura della nostra pagina Web (sia HTML4, 5 o qualsiasi cosa succeda dopo) utilizzando attributi aggiuntivi sui nostri elementi esistenti.

ARIA per l'accessibilità

Una delle cose più semplici da implementare su un sito esistente o nuovo sono i punti di riferimento ARIA. (ARIA è l'acronimo di Accessible Rich Internet Applications ed è una specifica che definisce un modo per rendere le applicazioni Web e le pagine Web più accessibili).

I punti di riferimento ARIA sono un sottoinsieme della specifica generale ARIA e un tipo semplice di metadati che consente agli utenti non vedenti e ipovedenti con gli screen reader di saltare alle parti significative di una pagina, ovvero i "punti di riferimento". Semplicemente aggiungiamo role = "nome-punto di riferimento" a un elemento esistente, nello stesso modo in cui aggiungeremo class = "nome-classe" a un elemento. I punti di riferimento di AIRA sono discusso in confronto a HTML5 qui .

I punti di riferimento ARIA sono una corrispondenza molto migliore per ciò che facciamo attualmente. La denominazione è un po 'vistosa, ma almeno rispecchia la pratica effettiva dell'authoring web. Ad esempio, possiamo usare:

  • banner per l'intestazione della pagina generale.
  • navigazione per la navigazione.
  • complementare per barre laterali.
  • contentinfo per il footer.
  • principale per l'area del contenuto principale.

(Ricorda che banner, informazioni principali e di contenuto dovrebbero essere utilizzate solo una volta per documento).

I punti di riferimento ARIA sono una soluzione semplice che migliora le opzioni di navigazione per gli utenti di screen reader, senza sfiorare l'oscuro territorio del documento delineato in HTML. Sono veloci e facili da implementare e dovrebbero davvero far parte del modello di progetto HTML di base.

Motori di ricerca

Quindi abbiamo più semantica per l'accessibilità, ma abbiamo anche più semantica disponibile per i motori di ricerca.

In primo luogo, vorrei essere assolutamente chiaro che gli elementi HTML5 non hanno alcun vantaggio per SEO di sorta. È un mito e dobbiamo metterlo a letto. L'utilizzo di un tag di articolo non aiuterà il tuo cliente o il tuo cliente a posizionarsi più in alto rispetto al prossimo. Puoi fidarti che Google ha capito come trovare e classificare i tuoi contenuti ormai.

Tuttavia, i motori di ricerca sono desiderosi di capire il modo migliore per visualizzare (notare: non classificare ) i contenuti web in modo più strutturato.

Pertanto, i principali motori di ricerca hanno, nel corso degli anni, presentato o adottato metodi standard esistenti per il markup dei dati strutturati in una pagina Web in modo che possano estrarre le informazioni appropriate. Ad esempio, durante la ricerca di recensioni potresti aver notato che le valutazioni a stelle vengono visualizzate nei primi risultati di Google. Questo è un caso in cui i motori di ricerca sono in grado di estrarre il punteggio della recensione in modo standardizzato e migliorare la visualizzazione dei risultati. Le ricette sono un altro esempio, in cui è elencato il tempo di cottura per ogni risultato. Sebbene tali dati non migliorino il posizionamento di un sito, il risultato più dettagliato potrebbe incoraggiare un maggior numero di utenti a fare clic, quindi c'è un potenziale vantaggio per un sito, ed è spesso necessario in una situazione di corsa agli armamenti dove tutti i concorrenti lo stanno facendo Comunque.

Mentre questo tipo di dati ricchi è stato intorno per un po 'in varie forme, solo l'anno scorso i principali motori di ricerca lanciato una vasta gamma di standard per questo tipo di dati strutturati. Li chiamano "schemi" e sono ospitati in Schema.org . Usano lo standard dei microdati HTML e sono già stati implementati da marchi come eBay, IMDB, Rotten Tomatoes e altro ancora.

Questo è il più grande passo avanti verso una rete più semantica da anni, eppure è stato fatto a porte chiuse con poca fanfara e nessun processo standard. Ci è caduto addosso senza preavviso, e da allora è volato per lo più sotto il radar della comunità del web design. C'è anche molta sovrapposizione con la semantica HTML5, per esempio per gli schemi articoli , web pagine e web elementi della pagina , tra molti più schemi che includono tutto da Episodi TV a condizioni mediche . È anche il modo consigliato di descrivere video sul web.

Dopo tutto il dibattito sulla semantica dell'HTML (e sulla sua mancanza), i motori di ricerca hanno chiarito che vogliono dati molto più semantici nel nostro markup, ma che succederà sopra le strutture esistenti e non con nuovi elementi.

Ma sicuramente per noi, in quanto comunità interessata alla semantica e agli standard web, né l'approccio limitato alla grammatica dell'HTML, né l'approccio chiuso e fuori dal tempo dei principali motori di ricerca rappresentano il miglior percorso da seguire.

In un certo senso, il cavallo semantico HTML5 si è schiantato; sta solo a noi per contenere il danno. Per quanto riguarda schema.org, è un mondo completamente nuovo, e dovremmo esaminarlo molto da vicino, o un altro piccolo gruppo determinerà ciò che è nei nostri interessi, e il Web, per noi. In effetti, potrebbe essere già successo.

conclusioni

Concludiamo con alcune conclusioni

  • I titoli contano: in primo luogo, dovremmo davvero preoccuparci della struttura delle intestazioni delle nostre pagine per aiutare gli utenti non vedenti e ipovedenti che cercano di andare in giro con gli screen reader. I venerabili elementi h1-h6 possono essere limitati, ma sono fortemente dipendenti dagli utenti di screen reader.
  • La struttura HTML5 è un casino: dovremmo probabilmente ignorare del tutto gli elementi strutturali HTML. Sono stati un po 'disastrosi - abbiamo essenzialmente biforcato le specifiche, creato molti schemi spezzati, e abbiamo perso troppo tempo già cercando di capire come funziona un sistema fondamentalmente rotto. Lunga vita alle immersioni.
  • Prendi in considerazione i punti di riferimento ARIA: aggiungere punti di riferimento ARIA al tuo sito è un altro modo semplice ed efficace per aiutare gli utenti di screen reader.
  • Considera schema.org e il futuro della semantica: schema.org ha il supporto dei principali motori di ricerca, e mentre al momento è sicuramente un mix di opzioni, sembra essere il futuro dei dati strutturati sul web.

Ci sono molte buone parti nelle specifiche HTML5, dalle nuove funzionalità dei moduli all'API della cronologia e all'implementazione della tela. In effetti, senza WHATWG, che è stata la forza trainante di HTML5, saremmo rimasti bloccati con HTML4 / XHTML 1.0 mentre aspettavamo che il W3C si riunisse. Tuttavia, solo perché HTML5 e tutta la relativa tecnologia che la circonda è nuova ed eccitante, non significa che dobbiamo accettare tutto ciò che ci viene dato.

A volte vale la pena vedere come viene prodotta la salsiccia HTML, quindi sappiamo cosa stiamo mangiando. E nel caso della semantica strutturale di HTML, preferirei passare.

Affamato di più? Il libro di Luke "The Truth About HTML5" è disponibile per un periodo limitato attraverso il nostro sito gemello MightyDeals.com con uno straordinario sconto del 50%.

Hai usato i punti di riferimento ARIA o Schema.org? Vedi un futuro per gli elementi strutturali di HTML5? Fateci sapere nei commenti.

Immagine in primo piano / miniatura, usi immagine della struttura via Shutterstock.