Blog

Come scrivere il testo alternativo sulle immagini

La realizzazione di un sito accessibile passa anche per gli attributi alt delle immagini: ecco come rispettare legge Stanca e WCAG 2.0

Uno dei primi punti da osservare per la realizzazione di un sito accessibile è l’utilizzo di testi alternativi sui contenuti non testuali come le immagini. Potrebbe sembrare un compito facile da assolvere, ma non è sempre così, soprattutto perchè a seconda delle situazioni le soluzioni possibili cambiano radicalmente.

Legge Stanca e WCAG 2.0

La normativa italiana e le linee guida del W3C sono molto precise a riguardo, questi sono gli enunciati:

Legge Stanca, requisito n°3

Fornire una alternativa testuale equivalente per ogni oggetto non di testo presente in una pagina e garantire che quando il contenuto non testuale di un oggetto cambia dinamicamente vengano aggiornati anche i relativi contenuti equivalenti predisposti. L’alternativa testuale equivalente di un oggetto non testuale deve essere commisurata alla funzione esercitata dall’oggetto originale nello specifico contesto.

WCAG 2.0, linea guida 1.1

Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.

Per ogni immagine presente sulla pagina è quindi necessario fornire un’alternativa testuale: il cosiddetto alt text.

Come usare l’attributo alt

Prima di tutto è d’obbligo tenere presente che ogni immagine inserita nel codice HTML di una pagina, soprattutto con doctype di tipo XHTML 1.0 Strict, necessita dell’attributo alt. Questo serve non solo quando l’attributo ha un valore, perchè è sempre utile indicare (ad esempio agli screen reader) che l’immagine non ha un significato rilevante e può essere saltata (usando alt=””). Questo accade spesso con le immagini puramente decorative, che sarebbe comunque meglio inserire tramite il foglio di stile.

Per eliminare ogni dubbio su cosa scrivere nell’attributo alt, la soluzione migliore è porsi una semplice domanda:

“Se dovessi illustrare al telefono la pagina che stai visitando, descriveresti l’immagine e il suo contenuto?”

Se la risposta è sì, allora è bene che quell’immagine abbia un testo alternativo, altrimenti non servirà a niente. Il metodo viene direttamente da Roger Johansson, e lo trovo perfetto per casi come questi.

L’importante è ricordarsi sempre di non esagerare, perchè è facile cadere nell’errore opposto: inserire troppe informazioni (inutili) in una pagina. Rendere accessibili le immagini di un sito non significa usare testi alternativi esageratamente lunghi e descrittivi: creerebbero solamente problemi. La cosa migliore è inserirli solo dove necessario, ad esempio in immagini che contengono del testo, per far arrivare all’utente lo stesso identico messaggio.

Conclusioni

Non è sempre facile trovare il giusto testo alternativo per le immagini di una pagina web. Le soluzioni variano a seconda dei casi, ma la regola fondamentale è ricordarsi che il testo alternativo deve servire per veicolare lo stesso messaggio dell’immagine, non per descriverla.

La differenza tra le due cose in certi casi potrebbe essere sottile, ma l’importante è essere coscienti del problema e cercare di risolverlo. Un sito accessibile passa anche per questi dettagli.

Guida WordPress 2.7: come personalizzare i post

Con la nuova versione di Wordpress è possibile personalizzare i post con facilità: ecco come modificare il codice del proprio template.

La versione 2.7 di WordPress è arrivata: la nuova interfaccia di amministrazione fa parlare di sè, ma ci sono altri cambiamenti che possono aiutare gli sviluppatori a personalizzare i temi, senza più bisogno di hack e plugin esterni.

Una delle novità più interessanti riguarda la personalizzazione dei post. Adesso infatti è presente una nuova funzione chiamata post_class() che assegna automaticamente a tutti i post contenuti nel loop alcune classi HTML. Queste classi possono essere utilizzate nel CSS, per modificare l’aspetto delle pagine e degli articoli.

La funzione post_class()

Per sfruttare la nuova funzione è sufficiente individuare nel template il blocco di codice HTML relativo ad ogni post, che si apre con:

<div class="post" id="post-<?php the_ID(); ?>">

A questo punto sostituitelo con:

<div <?php post_class(); ?> id="post-<?php the_ID(); ?>">

La nuova funzione genera automaticamente la classe post e ne crea di nuove, contenenti tra l’altro informazioni su categorie e tag. Se avete bisogno di aggiungere una classe a quelle di WordPress, vi basta specificarla con la funzione:

<?php post_class('nome-classe'); ?>

o se avete bisogno di più classi:

<?php post_class('classe1 classe2 altra-classe'); ?>

Infine se volete utilizzare la funzione all’esterno del loop o nelle pagine dei singoli post, potete farlo passando come secondo parametro l’ID del post:

<?php post_class('', $post_id); ?>

Come risultato finale avrete numerose classi a disposizione con cui personalizzare i vostri temi. Questo è l’elenco nel dettaglio:

  • .post: classe generica, applicata a tutti gli articoli
  • .sticky: classe assegnata ai post in evidenza, che con WordPress 2.7 possono essere visualizzati prima di tutti gli altri
  • .hentry: classe usata nei microformats
  • .category-nomecategoria: classe che indica la categoria di appartenenza del post, può essere più di una
  • .tag-nometag: classe che indica il tag di appartenenza del post, può essere più di una

Potete già immaginare le possibilità offerte da questa nuova funzione di WordPress 2.7. Niente che prima non si potesse fare con qualche hack, ma adesso è tutto pronto all’uso e collaudato, all’interno della piattaforma. Ora creare un post in evidenza con un aspetto diverso dagli altri è semplice, così come assegnare un’icona o uno sfondo differente ad ogni articolo, a seconda della categoria.

Nel prossimo post dedicato alla nuova versione di WordPress descriverò come personalizzare i commenti.

Addio layout elastici?

Pro e contro dei layout con misure definite in em. Sono ancora validi o non vale la pena spendere tempo e risorse per realizzarli?

I layout elastici sono definiti in questo modo per la loro capacità di adattarsi alle dimensioni del testo di una pagina. Ingrandendo i caratteri cambiano tutte le dimensioni di conseguenza: questi layout sono infatti definiti interamente in em, unità di misura relativa. Per chiarirvi le idee potete trovare un esempio pratico su CSS Zen Garden.

Chi ha realizzato un layout elastico sa quanto lavoro comporti, ma come sempre prima di cimentarsi in pratiche dispendiose è sempre bene valutarne pro e contro.

Conviene ancora realizzare siti interamente in em?

La domanda sorge da un dato di fatto: tutti gli ultimi browser offrono la possibilità di ridimensionare le pagine con un effetto zoom. In questo modo anche i layout a larghezza fissa non presentano grandi problemi, ancora meno le altre tipologie.

I layout elastici hanno sempre avuto la fama di essere accessibili e utili per l’utente che desidera personalizzare la dimensione dei caratteri, ma allo stato attuale l’unico browser che ottiene un vantaggio netto da questo tipo di design è Internet Explorer 6.

Mettendovi nei panni di un utente con problemi di vista o con la necessità di ingrandire il testo, cosa fareste? Molto probabilmente usereste un browser con la possibilità di zoomare le pagine, o un ingranditore di schermo, non IE6. E’ così assurdo come ragionamento? Non credo.

Per questo i layout in em ormai si stanno avviando verso l’estinzione. Considerando anche i tempi di sviluppo ed il rapporto costi/benefici, ormai non conviene più realizzare siti simili, a meno che non si abbia un ampio target di utenti utilizzatori di Explorer 6. Non esistono certezze assolute, ma a distanza di 5 anni dallo storico articolo di A List Apart sui layout elastici, è ormai tempo di metterli da parte per la maggior parte dei casi, tenendoli comunque presenti per le necessità impreviste.

Regali di Natale: alcune idee originali

Alcune idee regalo per il Natale 2008: tornano i suggerimenti un anno dopo le segnalazioni per regali geek del 2007.

Dopo aver dedicato nel 2007 un articolo ai regali di Natale per geek, quest’anno mi sembra giusto scrivere un altro post a tema. Se siete in cerca di idee e volete fare un regalo originale, potreste trovare qui ciò che fa per voi.

Here!

Idea originale disponibile sul sito Fred, dove troverete molti altri oggetti fuori dal comune. Questo è un attaccapanni a forma di freccia, che ovviamente indica il punto dove appendere la vostra giacca.

Help!

Un semplice tappo per lavandino, che ha una forma decisamente fuori dal comune. Anche questo disponibile su Fred.

T-Shirt su 10tees.com

Se siete in cerca di una maglietta originale, in rete ci sono innumerevoli siti da esplorare. 10tees raccoglie le migliori magliette disponibili su questi siti in diverse categorie, passando dalla tipografia a Star Wars. Se non vi bastassero questi suggerimenti e cercate un regalo per un web designer, potete sempre acquistare la maglietta di Carsonified come ho fatto io.

On/Off Mug

La tazza On/Off disponibile su Charles & Marie cambia stato quando vengono versate delle bevande calde al suo interno. Decisamente geek.

Lego Poster

Mike Stimpson è un fotografo professionista che si diverte a ricreare ambientazioni con i mattoncini Lego. Sul suo sito trovate delle fantastiche composizioni in formato poster che possono essere acquistate, ispirate da famosi scatti fotografici.

Altre idee regalo

idee-regalo-originali

Siete ancora indecisi? Una raccolta di oltre 200 idee regalo è quello che fa per voi. Su questa pagina trovate di tutto: dalle esperienze agli oggetti fisici, passando per i regali personalizzati: l’ispirazione è dietro l’angolo, basta scorrere le idee a disposizione.

Bonus: regali di Natale originali

Se l’elenco fino ad ora non vi ha soddisfatti, ecco la risorsa definitiva. Una raccolta di idee originali categorizzate per prezzo. Soluzioni per tutte le tasche con oggetti che sicuramente non rischiano di essere dei doppioni in casa dei vostri amici.

Slideshow e gallerie di immagini accessibili

Le migliori soluzioni JavaScript per realizzare gallerie di immagini accessibili, utilizzando i framework jQuery e Mootools.

Dall’uscita di Lightbox le soluzioni JavaScript per realizzare gallerie di immagini si sono moltiplicate: le scelte a disposizione sono innumerevoli, ma non è solo l’aspetto estetico quello che conta. Molto spesso gli script disponibili in rete sono fin troppo pesanti per il loro scopo, o non tengono presenti gli standard minimi per quanto riguarda l’accessibilità dei contenuti.

In questo articolo troverete una selezione di alcuni effetti che consentono di creare gallerie di immagini accessibili: non intrusivi, degradano nel modo giusto se JavaScript è disabilitato, e si appoggiano a framework già collaudati come jQuery e Mootools. Potrebbero essere migliorati ulteriormente, ma sono un’ottima base di partenza.

SmoothGallery

Soluzione basata sulla libreria Mootools, consente di creare slideshow di immagini mettendo a disposizione vari parametri come lo scorrimento automatico ed il tempo riservato ad ogni fotografia. E’ possibile anche avere più set di immagini nella stessa galleria: funzione comoda per risparmiare spazio nella pagina.

In assenza di JavaScript, le immagini appaiono comunque precedute da titolo e descrizione. Il difetto riguarda i controlli, non è infatti possibile scorrere le foto da tastiera.

Slideshow 2

Un buon set di effetti a disposizione anche per questo script basato sul framework Mootools, che può essere a sua volta esteso con altre funzionalità, come l’anteprima delle immagini con Lightbox.

Notevole la realizzazione degli esempi: disabilitando JavaScript le funzionalità restano le stesse, spariranno semplicemente le transizioni. Ottimi anche i controlli, non c’è alcun problema a spostarsi tra le immagini utilizzando anche la tastiera.

Galleria

Probabilmente il migliore tra quelli presentati, questo script si basa su jQuery e pesa solamente 4kb. Non è intrusivo, degrada senza problemi in assenza di JavaScript o con i CSS disabilitati e può essere personalizzato facilmente anche nell’aspetto. Le immagini sono organizzate in una lista nel codice HTML: una soluzione ottimale.

Notevole anche l’efficienza dello slideshow, perchè le foto vengono caricate e mostrate solo quando disponibili, evitando attese nel momento dell’interazione.

Se conoscete altre soluzioni accessibili per la creazione di gallerie di immagini segnalatele nei commenti, è sempre utile conoscere le migliori risorse in questo ambito. Potete trovare altri script nel mio precedente post dedicato a Lightbox ed ai suoi cloni: se comunque volete uno slideshow accessibile il mio consiglio è di partire dagli script appena illustrati.

Dichiarazione di accessibilità: come scriverla

Suggerimenti utili per scrivere una dichiarazione di accessibilità evitando gli errori più comuni.

In molti siti e soprattutto in quelli che si preoccupano di essere accessibili, spesso viene inserita una dichiarazione di accessibilità per illustrare la conformità delle pagine agli standard in vigore.

Fondamentalmente una pagina autocelebrativa non serve a niente, soprattutto perchè inserirla non rende un sito automaticamente accessibile. Fornire informazioni utili ai propri visitatori resta comunque una buona idea, soprattutto se questo porta ad una migliore esperienza di navigazione.

Alcuni suggerimenti utili

Scrivendo una dichiarazione di accessibilità si possono commettere diversi errori. I consigli più semplici da imparare e da tenere sempre presenti sono:

  • Non addentrarsi troppo in dettagli tecnici che la maggior parte degli utenti non potrà capire: parlare di CSS, attributi alt sulle immagini, testi in em e progressive enhancement non serve a niente.
  • Mettere bene in evidenza un recapito per segnalare problemi ed errori.
  • Realizzare una pagina bene organizzata: è fondamentale suddividere le sezioni della dichiarazione con dei titoli, ad esempio parlando di navigazione, testi, collegamenti, ecc.
  • Non nascondere il collegamento: va bene inserire un link nel footer, ma non rendetelo invisibile, altrimenti tutti i presupposti di un sito accessibile spariranno fin dalla vostra dichiarazione di conformità agli standard.

Tenete comunque presente che non è obbligatorio inserire una pagina dedicata alla dichiarazione di accessibilità, anzi. Se il vostro sito è ben realizzato, nella maggior parte dei casi non avrete alcun bisogno di mettere in evidenza il vostro buon lavoro. Un sito è veramente accessibile quando gli utenti sono in grado di navigarlo senza nessun suggerimento da parte vostra.

A tale proposito proprio su questo sito non ho deciso di inserire una vera e propria dichiarazione di accessibilità, ma un semplice testo esplicativo nel footer. Nel caso ci siano problemi o gravi errori, il mio invito è sempre quello di contattarmi per segnalarli.

Layout a tabelle con i CSS

Con Internet Explorer 8 sarà possibile usare la proprietà CSS display:table. Cambierà qualcosa per i web designer?

Dopo aver abbandonato l’uso delle tabelle per il layout, in questo periodo si sta tornando a parlare del loro utilizzo in forma diversa: non più all’interno del codice HTML, ma con la proprietà display dei CSS.

Come fa notare Digital Web Magazine, con l’imminente uscita di Internet Explorer 8 questa proprietà supporterà correttamente i valori table, table-row e table-cell per la prima volta su un browser Microsoft. Le ultime versioni di Safari, Opera e Firefox seguono già gli standard e non dovrebbero avere alcun problema.

Come funziona la tecnica?

Basta realizzare una semplice struttura nel codice HTML con dei div:

<div id="main">
<div id="nav">
...contenuto della colonna
</div>
<div id="content">
...contenuto della pagina
</div>
</div>

Quindi è sufficiente applicare gli stili relativi, facendo in modo che il contenitore principale abbia un display: table, e le singole colonne un display: table-cell:

#main {
display: table;
border-collapse: collapse;
}
#nav {
display: table-cell;
width: 180px;
}
#content {
display: table-cell;
width: 580px;
}

Da notare che una tecnica simile dal punto di vista della semantica del codice non presenta alcuna controindicazione. L’aspetto tabellare infatti viene gestito interamente tramite i fogli di stile, il markup è ben organizzato e non ha particolari differenze rispetto a quello di un layout con i float.

Incompatibilità e difetti

Per ogni nuova tecnica è fondamentale considerare quanto essa sia realmente applicabile. Nel caso dei layout a tabelle con i CSS, uno dei punti deboli è sicuramente il mancato supporto di IE6 e IE7. Non poter usare questa soluzione sui due browser che da soli rappresentano più del 70% del mercato, la rende di fatto inutilizzabile: al momento è poco più che esercizio di stile.

Un altro aspetto poco considerato è l’ordine dei contenuti all’interno del codice HTML. Con questa tecnica si ripresenta uno dei difetti principali delle tabelle: l’impossibilità di organizzarli secondo la loro importanza. Usando un layout tabellare tutti i vantaggi del posizionamento con i float spariscono, dovendo per forza di cose ordinare gli elementi secondo il loro ordine di apparizione nella pagina.

Se volete continuare ad approfondire il discorso, vi rimando ad un post di Edit di qualche settimana fa. Dal mio punto di vista, potrebbe essere interessante sperimentare la tecnica per il futuro, ma con qualche riserva. Sarà infatti possibile usarla quando IE6 e IE7 spariranno dalla circolazione, ma i CSS3 saranno ormai alle porte con nuove soluzioni per gestire il layout di un sito.

Web Design: tendenze e sperimentazione

Il difficile equilibrio tra innovazione e buone consuetudini nella realizzazione di un sito web.

Nella realizzazione di siti web è normale che emergano delle tendenze più o meno di successo. E’ accaduto con i siti Web 2.0, poi è stata la volta dello stile grunge, nei prossimi mesi noteremo sicuramente nuove mode.

In questo ambito però viene spesso trascurata la componente innovativa: quanto è conveniente seguire le tendenze del momento a scapito della sperimentazione? Realizzare un sito che somigli a qualcosa di già visto potrebbe essere controproducente, e sicuramente non darà ai visitatori dei motivi per rimanere impressionati positivamente.

Un esempio chiave è il recente redesign di Duoh.com, presentato qualche settimana fa sul blog di Veerle Pieters: se non avete visitato la sua creazione vi consiglio di impiegare qualche minuto del vostro tempo per navigare tra le pagine ed esplorarle a fondo.

In questo caso l’obiettivo era realizzare qualcosa di innovativo, ed è stato centrato in pieno. Raggiungere un simile traguardo non è impresa da poco, anche perchè sperimentare significa uscire dagli schemi ed andare contro le mode del momento: a volte è indispensabile.

Veerle scrive a questo proposito:

we needed to explore some new territory and be a little experimental along the way

Esplorare nuove strade è necessario: se nessuno avesse il coraggio di andare oltre le consuetudini, avremmo siti tutti uguali. E’ quello che è accaduto nel periodo di maggior successo dello stile Web 2.0, che fortunatamente ora sta diventando obsoleto.

Sicuramente con il passare degli anni il Web Design ha le possibilità di evolversi e conservare alcune buone abitudini, l’importante è non fossilizzarsi su di esse. Non vanno dimenticati i passi avanti fatti nell’utilizzo della tipografia e in alcune scelte di layout (mi vengono subito in mente i footer alti), ma un Web Designer deve anche saper osare.

Nei vostri lavori quanto concedete alla sperimentazione? Trovare il giusto compromesso è probabilmente l’aspetto più difficile, ma se avete intenzione di farvi notare ricordate che non sempre è sufficiente imitare.

WCAG 2.0: le nuove linee guida

La seconda versione delle WCAG raggiunge lo stato di Proposed Recommendation: ecco tutto ciò che occorre sapere sulle nuove linee guida.

Dopo aver atteso a lungo, il 3 Novembre 2008 le WCAG 2.0 hanno raggiunto lo stato di Proposed Recommendation: il rilascio finale è questione di poco tempo, si parla di fine anno.

Sono passati diversi anni da quando è iniziato lo studio di una seconda versione per linee guida del W3C: basti pensare che le WCAG 1.0 risalgono al 1999. Già nel 2006 affrontai l’argomento su questo blog, parlando della presa di posizione di Joe Clark sulle pagine di A List Apart; da allora sono stati fatti diversi passi avanti, già evidenti al raggiungimento dello stato di Candidate Recommendation nel Maggio scorso.

12 linee guida

Le WCAG 2.0 sono costituite da 12 punti. In questi criteri vengono riassunte tutte le problematiche relative all’accessibilità, con l’obiettivo di dare indicazioni generali, non legate ad una particolare tecnologia o dispositivo. L’obiettivo viene così raggiunto senza perdersi in linee guida troppo specifiche e limitanti.

Ognuno dei 12 punti è poi suddiviso in 3 (o meno) livelli di conformità: le già famose A, AA, AAA, che servono ad indicare quali siano le priorità.

Cosa cambia dalle WCAG 1.0 alle WCAG 2.0

Chi da sempre si preoccupa di realizzare siti accessibili indipendentemente dai requisiti obbligatori e dalle linee guida può rimanere tranquillo. L’obiettivo delle WCAG 2.0 è proprio quello di avere delle indicazioni universali, indipendenti dalla tecnologia e dal dispositivo utilizzati: se vi siete preoccupati di realizzare dei siti accessibili preoccupandovi dei problemi reali e non semplicemente di seguire delle regole, molto probabilmente non dovrete cambiare niente.

Se volete approfondire il discorso e scoprire le differenze, è comunque disponibile una bozza comparativa tra tutti i checkpoint delle WCAG 1.0 e delle WCAG 2.0 appena pubblicate.

Risorse utili

Per non rimanere disorientati dall’enorme documentazione disponibile, ecco alcuni punti di riferimento per capire meglio e poter seguire senza problemi le WCAG 2.0:

  • L’accessibilità è 2.0: un ottimo articolo di Punto Informatico sulle nuove linee guida.
  • Understanding WCAG 2.0: una guida del W3C per capire ed implementare ogni singolo punto delle WCAG.
  • Techniques for WCAG 2.0: tutte le informazioni tecniche necessarie per osservare i requisiti, facendo riferimento a HTML, CSS e altri linguaggi. Interessanti anche gli esempi relativi al mancato rispetto delle linee guida.
  • Accessible forms using WCAG 2.0: una guida completa per realizzare form realmente accessibili

Se conoscete altre risorse utili disponibili, segnalatele e provvederò ad aggiungerle in questa pagina.

Guida all’utilizzo di ID e classi nel codice HTML

Consigli utili per ottimizzare il codice HTML, mantenendo separato il contenuto dalla presentazione.

Nello sviluppo di un sito spesso ci si preoccupa degli aspetti più complessi per poi dimenticare i dettagli elementari. All’interno del codice HTML hanno una notevole importanza ID e classi, ma capita di utilizzare questi attributi senza attenzione, in maniera spesso controproducente.

In ogni progetto è fondamentale considerare almeno due aspetti riguardanti il codice delle pagine:

  1. le possibilità di sviluppo future
  2. la leggibilità

Per ottenere i migliori risultati e soprattutto consentire a chiunque di comprendere il codice HTML, è sufficiente ricordarsi alcuni punti ben illustrati sul blog di Jens Meiert che ho voluto approfondire.

1. Ridurre al minimo ID e classi

Finchè è possibile, evitate di appesantire il codice HTML e sfruttate i selettori discendenti dei CSS. Sono uno strumento potente, e potrete così limitare gli ID ai contenitori principali (ad esempio #container, #header, #nav…). Potrebbe sembrare un dettaglio di poco conto, ma con la pratica vi accorgerete che questa non è un’indicazione assurda, anzi.

Ovviamente su elementi che hanno bisogno di personalizzazioni su misura (ad esempio un’icona associata) è indispensabile l’uso di classi ad hoc, ma questo modo di pensare sarà molto utile anche in futuro con i selettori dei CSS3. Sarete già pronti ad utilizzarli senza dover cambiare le vostre abitudini di lavoro.

2. Utilizzare nomi relativi alla funzione dell’elemento

Uno degli errori più comuni è usare per ID e classi un nome relativo all’aspetto dell’elemento e non alla sua funzione. Un esempio potrebbe essere .red_text invece di .alert. Commettendo questo errore resterete vincolati, ed in futuro non potrete cambiare la visualizzazione di quel particolare elemento senza modificare anche il nome dell’attributo. Avere una classe .red_text che fa riferimento ad un elemento di colore diverso dal rosso sarebbe assurdo!

A questo proposito non ci sono degli standard (anche se non sarebbe male averli), ma è buona pratica usare nomi come #menu o #nav per la navigazione, #content per il corpo centrale del sito, #header e #footer per testata e piede. Osservando i layout dei web designer più famosi potete farvi un’idea di quali siano le convenzioni più diffuse.

3. Sintetizzare in maniera comprensibile

Per velocizzare il lavoro ed evitare di avere fogli di stile esageratamente lunghi è sempre meglio cercare di usare nomi brevi per ID e classi. Questo però non deve andare a scapito della comprensibilità: #nav è sicuramente meglio di #navigation, ma usare .wdg al posto di .widget sarebbe esagerato.

Quelli mostrati sono dettagli elementari: proprio per questo andrebbero sempre tenuti presenti. Non pensate che siano aspetti poco importanti, la realizzazione di un buon sito inizia proprio dal codice scritto. A questo proposito, quali sono le vostre convenzioni per l’uso di ID e classi? Lasciate un commento per discuterne insieme.