Interazioni tra siti accessibili e motori di ricerca

hogudo

Interazioni tra siti accessibili e motori di ricerca

Iniziamo ogni un nuovo capito.
Iniziamo con il discutere sulle interazioni tra accessibilità e motori di ricerca.
Spesso vedo sul campo e sul forum che molti siti che vogliono e devono essere competitivi sui motori di ricerca, iniziano a porsi problematiche relative ad una maggiore pulizia del codice, altresì spesso coincidente con le linee guida w3c relative al wcag e alla redazione in xhtml, in quanto ottimizzazione aggiuntiva.

Questo forum è pieno infatti di discussioni in merito a siti pensati secondo questa filosofia, che sempre più spesso vengono a farci visita in questa sezione per avere le opinioni sia concettuali che pratiche.

Ora però, come avevamo ipotizzato con Giorgio all'inizio del nostro percorso, alcuni webmaster con l'occhio rivolto all'innovazione e che sanno guardarsi intorno, stanno facendo anche il ragionamento inverso.

Ovvero un sito che deve normativamente parlando, attenersi alle linee guida di accessibilità, per esempio della Legge Stanca, può essere ottimizzato (e come) senza snaturare la comunicazione verso il suo target che, per natura istituzionale, deve essere il più ampio possibile?

Una bellissima soddisfazione a coronamento del lavoro che (mi scusino i lettori per l'auto citazione) sia io, che IWA, che il ForumGT ed alcune istituzioni lungimiranti stiamo facendo, è venuto dalla webmaster del Comune di Piegaro, Slvia Bocci, che sta cercando e riuscendo di applicare ove possibile diversi concetti sopra esposti.

Questo primo link, http://comune.piegaro.pg.it/ , spero possa diventare, insieme ad altri in futuro, attività di studio e di confronto sui temi e gli scopi della nostra sezione.

A voi la parola

mamilu

Il ragionamento inverso.

In effetti stranamente [ma non poi tanto] è di questo che si tratta; abbiamo da sempre guardato alla validazione puntando al posizionamento, cercando di dare maggiore competitività al sito, ed ora ci troviamo a valutare quanto un sito validato a priori [perchè così deve essere per legge] possa pure essere ottimizzato e spinto nei motori.

Quasi come se l'ottimizzazione fosse pregiudicata, o messa in discussione dalla validazione.
Così come spesso si considerano brutti i siti validati; di difficile validazione cioè forme grafiche avanzate.

Ora vediamo che ne pensano i nostri geniacci sia di grafica che di posizionamento [forse varrebbe la pena coinvolgerli direttamente nei loro rispettivi forum], ma nel frattempo vorrei fare i miei complimenti al WM che ha realizzato http://comune.piegaro.pg.it/

Colpisce davvero la pulizia e ... l'***accessibilità ***di quel sito.
Tutto appare molto chiaro, gradevole, ben esposto ed usabile dall'utente.

Interessante lavoro davvero

catone

Saranno boh, 4 anni che puntualmente qualcuno pone questo quesito: un sito validato posiziona meglio? Alcuni sostengono di sì, altri di no.

Personalmente credo che un sito validato indirettamente posizioni meglio. E mi spiego: se pensiamo al passaggio dello spider come ad un flusso, meglio come ad una corrente di un fiume, ecco che un sito validato è un fiume senza detriti, lo spider passa e non trova ostacoli.
Ma, evidentemente, lo stesso principio potrebbe valere per un sito non validato, ma formalmente corretto. Definire un sito formalmente corretto è operazione piuttosto difficile e soggettiva, quindi, per assurdo, la validazione è operazione più facile da ottenere.

Quanto al codice v'è da dire che secondo le specifiche w3c è doveroso utilizzare l'accoppiata xhtml+css in luogo di tabelle per definire layout. Di contro un sito formalmente corretto che si appoggia alle tabelle per la costruzione del template può tranquillamente validare.

Ma poniamo che il realizzatore di siti segua comunque il precetto, per meglio dire la linea guida. Ebbene l'accoppiata xhtml+css (per la definizione del layout) genera, mediamente, dal 20% al 50% di codice in meno rispetto alla maniera tradizionale (html+tabelle). Questo comporta, lo testo ogni giorno sui miei siti, che il rapporto contenuti/codice aumenta e questo piace molto ai motori di ricerca.

Consideriamo, infine, la possibilità di giocare con i css e di poter spostare, in alcuni layout, lato codice, i blocchi di informazione in una modalità diversa rispetto al lato della visione effettiva del sito. Nella fattispecie è, ad esempio, possibile inserire la gabbia principale, il box, in testa al codice con un posizionamento assoluto. Ebbene anche in questo caso si ha un vantaggio evidente, i motori individuano subito i contenuti principali del sito, soffermandosi poi su barre di navigazione e link di servizio.

Quindi, sotto l'aspetto tecnico, per mia modestissima opinione, un sito validato e, almeno parzialmente, accessibile dovrebbe avere una performance migliore nei motori di ricerca di uno che non presenta tali caratteristiche.

E' giusto però sottolineare che vi sono però dei problemi allorquando si voglia ottenere la completa accessibilità, soprattutto, lato contenuti.
Se pensiamo ad un generico testo di un sito ben ottimizzato, pensiamo ad un artefatto, ad un testo che mai e poi mai inserirei in una brochure aziendale. Per costruzione e per ripetizione di chiavi quest'ultimo può risultare farraginoso e quindi, mediamente, poco accessibile.
In particolare un grosso problema, a mio avviso, è quello dell'alt delle immagini. In termini di accessibilità, l'attributo deve fornire una descrizione alternativa all'immagine. Per il posizionamento rappresenta, invece, un'altra arma per posizionare. Capita sovente che ad un'immagine che esprime un certo concetto venga associato un attributo alt che non ha nessun rapporto con la prima, la chiave su cui si vuole ottimizzare la pagina. Lo stesso può accadere con gli attributi di tabella nascosti o palesi. Vi sono altri innumerevoli esempi che ora non ricordo.

Quindi dire, sempre mio personalissimo parere, che dal lato dei contenuti il connubio accessibilità posizionamente non è facilmente raggiungibile. E poichè l'accessibilità è tale se si rispettano tutte le direttive, direi che è il posizionamente a doversi fare un po' da parte in questi casi.

jardem

Oltre che accessibile, mi sembra abbia una buona usabilità...

Non ho idea cosa pensino i SEO... se fosse un sito di area molto competitiva!? Forse diranno: "struttura eccellente, lavorare sui titoli, tutti gli h1 sono uguali, etc, etc,

Solo curiosità:

sono delle pagine statiche html?
perchè viene usato import x screen e rel x print?

jardem

Da un articolo di Maurizio Boscarol:

Un utente cieco che stavo osservando navigare su alcune pagine, ha riferito che sentire il contenuto dell?elemento h1 in cima ad ogni pagina fosse noioso e ridondante. Poiché lo screen-reader leggeva per primo il contenuto dell?elemento title, quell?elemento serviva come titolo effettivo del documento, mentre l?h1 ? che ripeteva il contenuto del title ? era inutile. Naturalmente, questo risultava vero solo se l?elemento title conteneva informazioni utili e pertinenti.

 Date queste informazioni, una buona linea guida potrebbe suggerire che l?elemento title debba contenere sempre le informazioni essenziali per l?orientamento, compreso il nome del sito e della specifica pagina. L?elemento h1 dovrebbe a quel punto essere preceduto da un link alle principali aree del documento, come ?vai al: contenuto, alla navigazione principale, alla navigazione secondaria, al piè di pagina?, per permettere agli utenti ciechi di saltare le informazioni potenzialmente ridondanti (nel nostro esempio, l?h1 ripetitivo).

Articolo completo:
http://www.usabile.it/282006.htm

hogudo

Quindi dire, sempre mio personalissimo parere, che dal lato dei contenuti il connubio accessibilità posizionamente non è facilmente raggiungibile.

Sono d'accordo, è difficilmente raggiungibile, soprattutto per l'esempio da te fatto, perchè spesso per siti aziendali è il cliente a scegliere ed aggiornare immagini senza cognizione. Così come molti contenuti sono fatti fare dalla segretaria o peggio dal direttore stesso.

Un buon CMS (magari con un modulo apposito per il SEO), progettato bene ed una adeguata formazione credo possano tranquillamente sopperire e colmare molte lacune. Ottima analisi.

Aggiungerei che comunque, in ottica di web semantico, i contenuti saranno sempre più dominatori di artefatti e trucchi, quindi suppongo che con l'andare avanti il vantaggio di un sito accessibile aumenterà sempre di più.

Solo curiosità:

sono delle pagine statiche html?
Ah-ah, che hai fatto al convegno: non sei stato attento alla mia relazione???
Domani vengo a casa tua e ti interrogo!!!
Da quello che ho capito le pagine sono dinamiche cambiate con una tecnica di rewrite

mentre l’h1 – che ripeteva il contenuto del title – era inutile.
Non era progettato bene.
A parte il fatto che possiamo anche mettere i link interni ai contenuti sopra l'h1, copiare il title paro paro nella parte iniziale solitamente messa in h1 non mi piace affatto, meglio ottimizzarlo

jardem

Per quanto riguarda h1, purtroppo è un errore che molti di noi (io) fanno

Che poi se ben strutturati aiuterebbero UTENTI DISABILI e MOTORI...

@hogudo said:

Ah-ah, che hai fatto al convegno: non sei stato attento alla mia relazione???
Domani vengo a casa tua e ti interrogo!!!
Da quello che ho capito le pagine sono dinamiche cambiate con una tecnica di rewrite

Giuro che non dormivo... :Trilly-95-77:

Rewrite: Era una curiosità... infondo un sito può essere gestisto benissimo anche con un editor e un ftp (boh... non mi sembra una tecnica di rewrite)

giorgiotave

@hogudo said:

Una bellissima soddisfazione a coronamento del lavoro che (mi scusino i lettori per l'auto citazione) sia io, che IWA, che il ForumGT ed alcune istituzioni lungimiranti stiamo facendo, è venuto dalla webmaster del Comune di Piegaro, Silvia Bocci, che sta cercando e riuscendo di applicare ove possibile diversi concetti sopra esposti.

Questo primo link, http://comune.piegaro.pg.it/ , spero possa diventare, insieme ad altri in futuro, attività di studio e di confronto sui temi e gli scopi della nostra sezione.

Ma che bella questa storia!

Penso che Silvia abbia fatto un ottimo lavoro, di alto profilo sicuramente

Oltre che accessibile, come dice jardem, è molto usabile. Risulta pulito e fresco, semplice; è davvero interessante.

Lato Seo mi sembra ok, non vedo gli h1 sempre uguali come dice Jardem, anche in settori molto competitivi non c'è molto da cambiare, forse qualche sbavatura di poco conto (tipo qualche link che punta a http://comune.piegaro.pg.it/index.html invece che http://comune.piegaro.pg.it/ ma sono cose veniali). Confermo, Lato SEO, per quella tipologia di sito, è sicuramente ottimo.

Secondo il mio modesto parere, l'accessibilità e l'usabilità, insieme al buon senso, portano già ad un'ottima ottimizzazione

Ora ne dico un'altra più grossa: chi ha una formazione ed è predisposto mentalmente verso l'accessibilità e l'usabilità, riesce a capire meglio i meccanismi dell'ottimizzazione per i motori di ricerca ed il loro percorso formativo è molto più breve di un qualsiasi webmaster aspirante SEO.

Speriamo presto di vedere tanti siti fatti in quel modo, è importante informare sempre di più

jardem

@Giorgiotave said:

non vedo gli h1 sempre uguali come dice Jardem,

Su h1, forse mi sono espresso male, non dicevo che tutti gli h1 sono uguali, ma quelli in testa a tutte le pagine: "<h1> Comune di Piegaro </h1>".
(Anche il sito del Comune di Sala Consilina, sviluppato da esperti, usa la stessa struttura)

Quello che mi chiedo: dato che c'è il tag <title> che identifica il documento, serve questo h1 in testa uguale in ogni pagina?

Con parole più chiare lo scrive Boscarol:
"una buona linea guida potrebbe suggerire che l?elemento title debba contenere sempre le informazioni essenziali per l?orientamento, compreso il nome del sito e della specifica pagina. L?elemento h1 dovrebbe a quel punto essere preceduto da un link alle principali aree del documento, come ?vai al: contenuto, alla navigazione principale, alla navigazione secondaria, al piè di pagina?, per permettere agli utenti ciechi di saltare le informazioni potenzialmente ridondanti (nel nostro esempio, l?h1 ripetitivo)."

P.S.
Come già detto: **oltre che accessibile, mi sembra abbia una buona usabilità...

**

claudioweb

Quoto Catone. Riguardo alla sintassi, seo e accessibilità vanno d'accordo. Molto meno riguardo alla semantica.

Il problema dell'accessibilità, di un sito ottimizzato per i motori di ricerca, sta nei contenuti e nella loro gestione.

Spesso non si può fare a meno di ricorrere ad inganni, che inevitabilmente colpiscono non solo gli spider, ma anche molti utenti.

Si gioca molto sul dare più importanza a livello di codice ai contenuti utili ai fini del posizionamento, e non a quelli più utili per l'utente.

Questo si fa in diversi modi, giusto per dirne alcuni:

Impostando le posizioni dei div con i css, così mettendo in testa i contenuti più interessanti dal punto di vista seo.

A questo proposito penso siano molto utili in testa i link che portano al menu di navigazione o al footer di cui parla jardem. Cosa a cui, onestamente, non avevo mai pensato;

Usando tag totalmente ridefiniti (h1, h2 o altri). Per poterli sfruttare a proprio piacimento e dare rilevanza a contenuti che visualizzati nei browser comuni all'apparenza non così importanti;
Inserendo testi alternativi non descrittivi dell'immagine, ma contenenti solo testi utili per i motori di ricerca;

Attualmente l'ottimizzazione implica questi e altri inganni.

Per il resto, l'uso codice validabile non può che far bene per ottenere una coretta interpretazione dei propri contenuti.

silviab

@Giorgiotave said:

Ma che bella questa storia!

Penso che Silvia abbia fatto un ottimo lavoro, di alto profilo sicuramente

Oltre che accessibile, come dice jardem, è molto usabile. Risulta pulito e fresco, semplice; è davvero interessante.

Lato Seo mi sembra ok, non vedo gli h1 sempre uguali come dice Jardem, anche in settori molto competitivi non c'è molto da cambiare, forse qualche sbavatura di poco conto (tipo qualche link che punta a http://comune.piegaro.pg.it/index.html invece che http://comune.piegaro.pg.it/ ma sono cose veniali). Confermo, Lato SEO, per quella tipologia di sito, è sicuramente ottimo.

Grazie per i complimenti
Ancora c'è tanto lavoro da fare,
sono stata attenta alla relazione del convegno di Bologna di Hogudo,
e quando son tornata a casa ho cercato di mettere in pratica.
Anche se di poco conto, puoi indicarmi il link che punta ad index.hml,
non mi sono accorta e vorrei correggere... altrimenti hogudo mi sgrida

hogudo

Ciao,
vederti qui sì che è un bel regalo di Natale.

A occhio, ma non sono riuscito a trovare conferma,
http://siteexplorer.search.yahoo.com/search?p=http%3A%2F%2Fcomune.piegaro.pg.it%2Findex.php&bwm=i&bwms=p&bwmf=u&fr2=seo-rd-se
http://search.msn.com/results.aspx?q=link%3Ahttp://comune.piegaro.pg.it/index.php

mi rimandavano a 2 pagine con collegamento a index.php che immagino sia invece stato rimosso e/o ottimizzato

Bella anche la pagina personalizzata di Errore404

silviab

Ciao Massimiliano,
spero di non essere l'unico regalo di Natale...
altrimenti sei messo male

Per la pagina 404, ho predisposto anche un modulo in modo che l'utente possa comunicare l'errore.
Il problema è che in questi form, inviando una mail tramite il comando mail di php, mi arrivano caratteri strani al posto delle lettere accentate.
Questo è un grave errore che sto cercando di risolvere.

hogudo

è per via del charset
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

provo a buttarmi
inserire nel form accept-charset="iso-8859-1" ?

hogudo

pardon... ISO-8859-15

hogudo

oppure se l'errore è contrario, scrivere accept-charset="utf-8"

silviab

Ho fatto le prove, ma niente.
Il problema, è solo su win,
io uso mac, e ogni volta che modifico per far prove,
devo andare a cercare in qualche chat qualcuno che mi prova su win
Cmq, spero di risolvere prima della fine dell'anno

Se vuoi vedere con i tuoi occhi, il problema è a questo link di prova:
www.comune.piegaro.pg.it/privata/posta.php

hogudo

Immagino che tu abbia provato anche ad obbligare ad usare il charset utf8...

hogudo

nel form... accept-charset="utf-8"

silviab

Si, mi pare che avevo provato.
Cmq, adesso ho messo accept-charset="utf-8"

Stiamo andando OT ?