Siti istituzionali
e-democracy, e-governement
Comunicazione Multimediale
DEFINIZIONI

E-government
Come riferisce il documento del Governo "Linee Guida
del Governo per lo Sviluppo della Società
dell'Informazione" le pubbliche amministrazioni devono
soddisfare alcune condizioni per definirsi pienamente
allineate al nuovo modo di comunicazione e
informazione, come:
- Tutti i servizi ‘prioritari’ disponibili on-line
- Tutta la posta interna alla Pubblica Amministrazione via
e-mail
- Alfabetizzazione certificata dei dipendenti pubblici
- 2/3 degli uffici della Pubblica Amministrazione con
accesso on-line all’iter delle pratiche da parte dei cittadini
- Tutti gli uffici che erogano servizi dotati di un sistema di
customer satisfaction.
DEFINIZIONI

E-democracy
Si prevede un costante coinvolgimento dei cittadini alle
decisioni pubbliche, in tutti gli ambiti possibili come, per
esempio, vita politica, ambiente, urbanistica, trasporti.
Molti siti di enti locali hanno predisposto forum aperti di
dialogo con i cittadini, coinvolgendo la cittadinanza e la
società civile nei progetti per l'ambiente e per la qualità
della vita nella città.
Questi nuovi modelli di comunicazione avvicinano sempre
di più il cittadino-utente alla pubblica amministrazione, in
un rapporto non più di subordinazione ma, invece, di
interazione e cooperazione, grazie al quale il cittadino
diventa finalmente protagonista del suo futuro.
DEFINIZIONI

M-Government
Il "mobile government" è la nuova frontiera dei servizi
erogati dalla Pubblica Amministrazione ed ha come
piattaforma tecnologica le infrastrutture degli operatori
mobili.
Mediante questo nuovo servizio i cittadini possono
effettuare una serie di operazioni usufruendo, per
esempio, del cellulare per pagare il parcheggio, essere
informati dalle liste di collocamento e tante altre infinite
opportunità.
Tra i moltissimi servizi erogabili mediante cellulare:




accesso alle cartelle cliniche
comunicazione di ritardi nei servizi pubblici
pagamento parcheggi pubblici servizi per anziani e portatori di
handicap: avviso agli accompagnatori con l'indirizzo dell'anziano
servizio di mappe stradali su GPRS .
Modello di e-government
Un sistema di e-government rappresenta un potente strumento di
coinvolgimento e partecipazione dei cittadini ai processi decisionali,
evolvendo verso modelli innovativi di eDemocracy.
Si è progettato un modello composto da sei elementi chiave:
 Erogazione servizi - Un insieme di servizi che dovranno essere resi disponibili
attraverso modalità innovative e ad un livello di qualità elevato a utenti-clienti
(cittadini ed imprese). Per focalizzare gli sforzi di sviluppo, sono stati individuati
alcuni servizi prioritari dal punto di vista degli utenti-clienti, che saranno
considerati nelle iniziative di digitalizzazione. Questi servizi saranno forniti con un
unico punto di accesso anche se implicano l'intervento di più Amministrazioni. Le
complessità interne alla Pubblica Amministrazione verranno cioè mascherate
all'utente/cliente.
 Riconoscimento digitale - Modalità di riconoscimento dell'utente e di firma sicure
attraverso la Carta di Identità Elettronica, la Carta Nazionale dei Servizi e la firma
digitale
 Canali di accesso - Una pluralità di canali innovativi attraverso cui l'utente accede
ai servizi offerti: Internet, call centre, cellulare, reti di terzi, etc
 Enti eroganti - Un back office efficiente ed economicamente ottimizzato dei diversi
enti eroganti
 Interoperabilità e cooperazione - Standard di interfaccia tra le Amministrazioni che
consentano comunicazioni efficienti e trasparenza verso l'esterno
 Infrastruttura di comunicazione - Un'infrastruttura di comunicazione che colleghi
tutte le Amministrazioni
Modello di egovernment
L’efficacia aumenta in modo significativo quando tutti gli attori sono
mutuamente in relazione e i progetti investono l’intero ambito
territoriale.
Il valore della rete, fatta di mutue connessioni legittimanti, segnala il pregio
delle migliori iniziative. Le direttive ministeriali sui servizi on line invitano ad
avere un approccio multicanale in relazione alle esigenze dell’utenza,
indicando la strada dell’integrazione come soluzione realmente efficace in
funzione della semplificazione e del progresso dei servizi on line.
Una tale visione porta a spostare il baricentro dell’analisi dei siti
istituzionali dalla sola dimensione dell’e-government al più ampio alveo dell’egovernance, ovvero guardare ai siti istituzionali come alla parte di un “tutto”
più complesso.
informazioni e servizi possono essere raggiunti dalle proprie case grazie ad
Internet e oggi, tramite sistemi di collegamento senza fili, come il wi-fi,
potenzialmente da qualsiasi luogo.
L’idea è di superare grazie al wireless il digital divide causato dalla non
copertura della banda larga in alcune zone della penisola.
ESIGENZE DA SODDISFARE
La prima esigenza da soddisfare è la tempestività
dell’informazione. Utile a tale scopo il supporto
di comunicati stampa raggiungibili dall’home
page, ordinati cronologicamente e magari divisi
per tematiche. Pubblicano comunicati stampa
l’85,4% dei comuni capoluogo, l’84,3% delle
province,19 regioni su 20. Vengono aggiornati
quotidianamente quasi tutti i siti regionali e più
del 60% dei siti di province e comuni capoluogo.
Meno sollecito l’aggiornamento dei siti di comuni
non capoluogo.
ESIGENZE DA SODDISFARE
L’immediatezza del contatto con
l’amministrazione è favorita dalla presentazione
in home page di un numero telefonico (in più del
40% degli enti) e dalla possibilità di invio di
messaggi e richieste tramite form on line:
persino per i comuni non capoluogo ben più della
metà dei siti consente una forma di relazione
istantanea con l’amministrazione accessibile dai
primi secondi di navigazione.
ESIGENZE DA SODDISFARE
La buona pratica di pubblicare FAQ (Frequently
Asked Questions) riassuntive delle domande
degli utenti nasce per agevolare la prontezza di
risposta.
Si tratta inoltre di uno strumento utile per
l’amministrazione che riduce così lo sforzo di
risposta alle domande principali che
pervengono. Le FAQ sono nelle home page di
12 regioni, e in più del 20% di siti provinciali e
delle città capoluogo.
ESIGENZE DA SODDISFARE
La presenza di un elenco dei servizi
disponibili on line, raccomandato peraltro
dalla direttiva del MIT sui servizi on line,
facilita la ricerca di quanto è possibile
“fare” on line, prima di avventurarsi nella
navigazione e nel browsing delle pagine.
E’ evidente come sia particolare
l’attenzione in questo senso dei comuni
capoluogo, che lo predispongono nel
43,7% dei casi
ESIGENZE DA SODDISFARE
Maggiore attenzione è dedicata a chiarire ai
cittadini obiettivi e competenze dei diversi
uffici amministrativi in modo da facilitarli
nell’orientamento circa l’ambito più adatto a cui
rivolgersi. Se prima era solo intorno al 40% la
percentuale di province e comuni capoluogo che
dedicavano spazio alla descrizione approfondita
delle competenze e finalità delle strutture
amministrazione, oggi questa percentuale
supera abbondantemente il 70%, mentre
raggiunge quasi il 50% nei comuni con più di
40.000 abitanti e quasi il 38,8% negli altri
comuni analizzati
ESIGENZE DA SODDISFARE
La comunicazione di tipo politico sui siti della Pa italiana
trova come già in passato ampio spazio. C'è una
crescita anche nella tendenza ad aggiornare e rendere
trasparente l’attività quotidiana dei vertici politici:
sono 17 le regioni che pubblicano le delibere di giunta
(tab.16), 15 delle quali le pubblicano in versione
integrale (erano 13 nella precedente rilevazione).
Delibere di giunta sono presenti integralmente nel 35,2%
dei siti provinciali (che comunque danno informazioni in
diversa misura delle delibere in oltre il 60% dei casi).
Anche per i comuni capoluogo, è di oltre il 60% la
pubblicazione delle delibere, quasi il 40% pubblicate
interamente, la maggior parte delle volte è presente un
motore di ricerca che facilita la consultazione.
Dal punto di vista tecnico le prestazioni dei siti tendono a
peggiorare, per la pesantezza delle pagine e la conseguente
maggiore lentezza di caricamento.
Elevato il numero di siti che risultano lenti al caricamento con
connessione analogica, in particolare siti provinciali ma anche di
comuni. Tale situazione danneggia il 41,3% degli utenti che, da
casa, ancora si collega con la linea commutata.
Cresce, a discapito del software proprietario windows, l’utilizzo di
software open source per la pubblicazione dei siti. Per la prima
volta, nei comuni capoluogo, l’utilizzo di sistema operativo open
source (nella maggior parte dei casi si tratta di Linux) supera il
50% (tab. 26). Non essendoci ancora, se non in alcune regioni
italiane, un forte indirizzo verso l’utilizzo di software aperto, è da
ritenere che tali scelte vengano compiute sulla base di motivazioni
economiche, pratiche o anche di scelte nelle politiche
tecnologiche.
Studio sulle linee guida per l'accessibilità e le
metodologie tecniche per la verifica dell'accessibilità
Requisito n. 1
Enunciato: Realizzare le pagine e gli oggetti al loro interno utilizzando tecnologie definite
da grammatiche formali pubblicate, nelle versioni più recenti disponibili quando sono
supportate dai programmi utente. Utilizzare elementi ed attributi in modo conforme alle
specifiche, rispettandone l’aspetto semantico
In particolare, per i linguaggi a marcatori HTML (HypertText Markup Language) e XHTML
(eXtensible HyperText Markup Language):
a) Per tutti i siti di nuova realizzazione, utilizzare almeno la versione 4.01 dell'HTML o
preferibilmente la versione 1.0 dell'XHTML, in ogni caso con DTD (Document Type
Definition - Definizione del Tipo di Documento);
b) Per i siti esistenti, in sede di prima applicazione, nel caso in cui non sia possibile
ottemperare al punto a) è consentito utilizzare la versione dei linguaggi sopra indicati
con DTD Transitional, ma con le seguenti avvertenze:

evitare di utilizzare, all’interno del linguaggio a marcatori con il quale la pagina è
realizzata, elementi ed attributi per definirne le caratteristiche presentazionali (per
esempio, caratteristiche dei caratteri del testo, colori del testo stesso e dello
sfondo, ecc.), ricorrendo invece ai Fogli di Stile CSS (Cascading Style Sheets) per
ottenere lo stesso effetto grafico;

evitare la generazione di nuove finestre; ove ciò non fosse possibile, avvisare
esplicitamente l'utente del cambiamento del focus;

pianificare la transizione dell'intero sito alla versione con DTD Strict del
linguaggio utilizzato. Il piano di transizione va presentato alla Presidenza del
Consiglio dei Ministri – Dipartimento per l'Innovazione e le Tecnologie da parte del
responsabile della accessibilità informatica (Art. 9 Regolamento).
Studio sulle linee guida per l'accessibilità e le
metodologie tecniche per la verifica dell'accessibilità
Requisito n. 2
Enunciato: Non è consentito l'uso dei frame nella realizzazione di nuovi siti
In sede di prima applicazione, per i siti esistenti già realizzati con frame, è
consentito l'uso di HTML 4.01 o XHTML 1.0 con DTD frameset, ma con le
seguenti avvertenze:
 evitare di utilizzare, all’interno del linguaggio a marcatori con il quale la
pagina è realizzata, elementi ed attributi per definirne le caratteristiche
presentazionali (per esempio, caratteristiche dei caratteri, del testo, colori del
testo stesso e dello sfondo, ecc.), ricorrendo invece ai Fogli di Stile CSS
(Cascading Style Sheets) per ottenere lo stesso effetto grafico;
 fare in modo che ogni frame abbia un titolo significativo per facilitarne
l'identificazione e la navigazione. Se necessario, descrivere anche lo scopo
dei frame e la loro relazione;
 pianificare la transizione a XHTML almeno nella versione 1.0 con DTD Strict
dell'intero sito. Il piano di transizione va presentato alla Presidenza del
Consiglio dei Ministri – Dipartimento per l'Innovazione e le Tecnologie da
parte del responsabile della accessibilità informatica (Art. 9 Regolamento).
Studio sulle linee guida per l'accessibilità e le
metodologie tecniche per la verifica dell'accessibilità
Requisito n. 3
Enunciato: 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.
Requisito n. 4
Enunciato: Garantire che tutti gli elementi informativi e tutte le funzionalità siano
disponibili anche in assenza del particolare colore utilizzato per presentarli nella
pagina.
Requisito n. 5
Enunciato: Evitare oggetti e scritte lampeggianti o in movimento le cui frequenze di
intermittenza possano provocare disturbi da epilessia fotosensibile, disturbi della
concentrazione o che possano causare il malfunzionamento delle tecnologie assistive
utilizzate. Qualora esigenze informative richiedano comunque il loro utilizzo, avvisare
l’utente del possibile rischio prima di presentarli e predisporre metodi che consentano
di evitare tali elementi.
Studio sulle linee guida per l'accessibilità e le
metodologie tecniche per la verifica dell'accessibilità
Requisito n. 6
Enunciato: Garantire che siano sempre distinguibili il contenuto informativo (foreground)
e lo sfondo (background), ricorrendo a un sufficiente contrasto (nel caso del testo) o a
differenti livelli sonori (in caso di parlato con sottofondo musicale). Un testo in forma
di immagine in genere è da evitare ma, se non è possibile farne a meno, deve essere
realizzato con gli stessi criteri di distinguibilità indicati in precedenza..
Requisito n. 7
Enunciato: Utilizzare mappe immagine sensibili di tipo lato client piuttosto che lato
server, eccetto nel caso in cui le zone sensibili non possano essere definite con una
delle forme geometriche predefinite indicate nella DTD adottata
Requisito n. 8
Enunciato: Se vengono utilizzate mappe immagine lato server, fornire i collegamenti di
testo alternativi necessari per poter ottenere tutte le informazioni o i servizi
raggiungibili interagendo direttamente con la mappa.
Studio sulle linee guida per l'accessibilità e le
metodologie tecniche per la verifica dell'accessibilità
Requisito n. 9
Enunciato: Per le tabelle dati usare gli elementi (marcatori) e gli attributi
previsti dalla DTD adottata per descrivere i contenuti e identificare le
intestazioni di righe e colonne.
Requisito n. 10
Enunciato: Per le tabelle dati usare gli elementi (marcatori) e gli attributi
previsti nella DTD adottata per associare le celle di dati e le celle di
intestazione che hanno due o più livelli logici di intestazione di righe o
colonne.
Requisito n. 11
Enunciato: Usare i fogli di stile per controllare la presentazione dei contenuti e
organizzare le pagine in modo che possano essere lette anche quando i fogli
di stile siano disabilitati o non supportati.
Studio sulle linee guida per l'accessibilità e le
metodologie tecniche per la verifica dell'accessibilità
Requisito n. 12
Enunciato: La presentazione e i contenuti testuali di una pagina devono potersi
adattare alle dimensioni della finestra del browser utilizzata dall’utente senza
sovrapposizione degli oggetti presenti o perdita di informazioni tali da
rendere incomprensibile il contenuto, anche in caso di ridimensionamento,
ingrandimento o riduzione dell’area di visualizzazione e/o dei caratteri
rispetto ai valori predefiniti di tali parametri
Requisito n. 13
Enunciato: Qualora si utilizzino le tabelle a scopo di impaginazione:
 garantire che il contenuto della tabella sia comprensibile anche quando
questa viene letta in modo linearizzato,
 utilizzare gli elementi e gli attributi di una tabella rispettandone il valore
semantico definito nella specifica del linguaggio a marcatori utilizzato
Requisito n. 14
Enunciato: Nei moduli (form), associare in maniera esplicita le etichette ai
rispettivi controlli, posizionandole in modo che per chi utilizza le tecnologie
assistive la compilazione dei campi sia agevolata.
Studio sulle linee guida per l'accessibilità e le
metodologie tecniche per la verifica dell'accessibilità
Requisito n. 15
Enunciato: Garantire che le pagine siano utilizzabili quando script, applet, o


altri oggetti di programmazione sono disabilitati oppure non supportati. Se
questo non è possibile:
fornire una spiegazione della funzionalità svolta;
garantire una alternativa testuale equivalente in modo analogo a quanto
indicato nel requisito n. 3
Requisito n. 16
Enunciato: Garantire che i gestori di eventi che attivano script, applet oppure
altri oggetti di programmazione o che possiedono una propria specifica
interfaccia, siano indipendenti da uno specifico dispositivo di input
Requisito n. 17
Enunciato: Garantire che le funzionalità e le informazioni veicolate per mezzo
di oggetti di programmazione, oggetti che utilizzino tecnologie non definite
da grammatiche formali pubblicate, script e applet siano direttamente
accessibili.
Studio sulle linee guida per l'accessibilità e le
metodologie tecniche per la verifica dell'accessibilità
Requisito n. 18
Enunciato: Qualora un filmato o una presentazione multimediale siano indispensabili per
la completezza dell’informazione fornita o del servizio erogato, predisporre una
alternativa testuale equivalente sincronizzata in forma di sotto-titolazione e/o di
descrizione vocale, oppure predisporre un riassunto o una semplice etichetta per
ciascun elemento video o multimediale, tenendo conto del livello di importanza e delle
difficoltà di realizzazione nel caso di presentazioni in tempo reale.
Requisito n. 19
Enunciato: Rendere chiara la destinazione di ciascun collegamento ipertestuale (link)
con testi significativi anche se letti indipendentemente dal proprio contesto oppure
associare ai collegamenti testi alternativi che possiedano analoghe caratteristiche
esplicative. Prevedere meccanismi che consentano di evitare la lettura ripetitiva di
sequenze di collegamenti comuni a più pagine.
Requisito n. 20
Enunciato: Se per la fruizione del servizio erogato in una pagina è previsto un intervallo
di tempo predefinito entro il quale eseguire determinate azioni, è necessario avvisare
esplicitamente l’utente, indicando il tempo massimo utile e fornendo eventuali
alternative per fruire del servizio stesso.
Studio sulle linee guida per l'accessibilità e le
metodologie tecniche per la verifica dell'accessibilità
Requisito n. 21
Enunciato: : I collegamenti presenti in una pagina devono essere selezionabili e attivabili



tramite comandi da tastiera, tecnologia in emulazione di tastiera o tramite sistemi di
puntamento diversi dal mouse. Per facilitare la selezione e l’attivazione dei
collegamenti con queste tecnologie assistive è anche necessario garantire che:
la distanza verticale di liste di link e la spaziatura orizzontale tra link consecutivi sia di
almeno 1 em;
le distanze orizzontale e verticale tra i pulsanti di un modulo (form) sia di almeno 1 em;
le dimensioni dei pulsanti in un modulo (form) siano tali da rendere chiaramente
leggibile l'etichetta in essi contenuta, per esempio utilizzando opportunamente il
margine tra l'etichetta e i bordi del pulsante.
Requisito n. 22
Enunciato: In sede di prima applicazione, per i siti esistenti, in ogni pagina che non
possa essere ricondotta al rispetto dei presenti requisiti, fornire un collegamento a una
pagina che li rispetti, contenga informazioni e funzionalità equivalenti e sia aggiornata
con la stessa frequenza della pagina originale, evitando la creazione di pagine di solo
testo. Il collegamento alla pagina accessibile deve essere proposto in modo evidente
all’inizio della pagina non accessibile
Comune di Macerata






















Requisito 1
I contenuti pubblicati risultano essere conformi sia alla raccomandazione W3C XHTML 1.1 che alla
raccomandazione W3C CSS 2.0. Il sistema CMS consente la pubblicazione di contenuti e del layout di
pagina conformi a tale DTD. La validazione tramite i validatori del W3C per linguaggio di marcatura e fogli di
stile ha dato risultati positivi per tutti i contenuti. I referenti saranno formati sul corretto utilizzo degli
elementi di intestazione (HX), per i quali non è previsto controllo automatico.
Requisito 2
La struttura del sito non prevede l'uso di frames.
Requisito 3
Gli oggetti non testuali di tipo informativo contenuti nelle pagine contengono un equivalente testuale. Gli
oggetti di tipo decorativo contengono tale attributo, così come le immagini.
Requisito 4
I contenuti pubblicati corrispondono al requisito. I referenti sono formati, in fase di pubblicazione dei
contenuti, al corretto uso del colore non delegandogli caratteristiche di tipo informativo (sia per testi che
per immagini).
Requisito 5
I contenuti corrispondono al requisito. I referenti sono formati, in fase di pubblicazione dei contenuti, al fine
di non utilizzare tali caratteristiche.
Requisito 6
Il foglio di stile è stato valutato con il sistema di valutazione ad esempio: www.webaccessibile.org/css . Il
sistema di gestione contenuti consente l'uso degli stili predefiniti nel foglio di stile e ciò rende impossibile
causare contrasti di colore non conformi. Per le immagini, in fase di pubblicazione dei contenuti i referenti
sono formati alla valutazione del contrasto.
Requisito 7
I contenuti pubblicati non contengono mappe immagine.
Requisito 8
I contenuti pubblicati non contengono mappe immagine.
Requisito 9
Il CMS utilizzato non genera tabelle ma usa il tag <div> </div> per la suddivisone degli spazi.
Requisito 10
Il CMS utilizzato non genera tabelle ma usa il tag <div> </div> per la suddivisone degli spazi.
Requisito 11
I contenuti risultano conformi. Il sistema di pubblicazione e la scelta della raccomandazione XHTML 1.1
consente l'uso esclusivo dei fogli di stile per l'impaginazione dei contenuti rendendo impossibile l'uso di
elementi ed attributi deprecati.
Comune di Macerata






















Requisito 12
I contenuti pubblicati risultano parzialmente conformi. Il layout grafico predisposto consente un
ridimensionamento che non sempre consente una corretta visibilità, in particolare su dispositivi di
tipo mobile.
Requisito 13
I contenuti pubblicati non contengono tabelle di impaginazione. Il sistema di pubblicazione contenuti
consente comunque l'uso di tabelle di impaginazione impedendo l'uso di elementi ed attributi dedicati
alle tabelle dati.
Requisito 14
I moduli associano in maniera esplicita i contenuti.
Requisito 15
I contenuti pubblicati non sembrano contenere script, applet o altri oggetti di programmazione.
Requisito 16
I contenuti pubblicati non sembrano contenere script, applet o altri oggetti di programmazione.
Requisito 17
I contenuti pubblicati non sembrano contenere script, applet o altri oggetti di programmazione.
Requisito 18
I contenuti pubblicati non contengono contenuti multimediali.
Requisito 19
I contenuti pubblicati risultano conformi. Il sistema di gestione contenuti utilizza degli appositi testi
descrittivi predisposti come attributo title.
Requisito 20
I contenuti pubblicati non contengono tali caratteristiche
Requisito 21
I contenuti pubblicati risultano conformi grazie alla voce tasti di accesso.
Requisito 22
Rispettando i suddetti requisiti, il sito web non necessita di pagine alternative.