Middleware è il componente principale di Linux 4D, per quanto riguarda l'interfaccia per disabilità visive. Esso si occupa di intercettare l'input utente, ed in base ad un Rule File associato all'applicazione correntemente attiva, crea l'output per il sintetizzatore vocale e il gestore della barra Braille.
Middleware estende la classica interfaccia di uscita, permettendo di avere una descrizione ad alto livello delle applicazioni, sulle quali creare il nuovo output. Vengono così aggiunte nuove funzionalità al sistema, senza dover modificare alcuna linea di codice delle applicazioni. L'intelligenza, in questo caso, è stato spostata "in alto", in un File di Regole associato all'applicazione stessa. È possibile estendere l'interfaccia stessa, aggiungendo a Middleware nuovi moduli. Questi contengono nuove azioni che possono essere eseguite dal sistema, aggiungendole ai Rule File.
Essendo difficile "imporre" stili di progettazione "accessibili", che come si è già visto per i documenti web non vengono recepite, si è pensato di spostare "l'intelligenza" che rende accessibile un'applicativo, dalla fase di progettazione ad una fase successiva al completamento dell'applicazione. Si procede infatti con la creazione di una "descrizione" dell'applicativo, da utilizzare per estendere le normali capacità di output dell'applicazione stessa, nella direzione di una maggiore accessibilità. Il fatto di spostare l'intelligenza ad un livello successivo, permette una migliore personalizzazione dell'ausilio. Il fatto che il formato della descrizione dell'applicazione da rendere accessibile, sia aperto, consente virtualmente a chiunque di personalizzare gli applicativi. Ciò non toglie che gli stili di progettazione delle applicazioni debbano essere orientate ad una maggiore accessibilità, ma rende più agevole l'uso di un computer, nel periodo di transizione verso questa fase, la cui lunghezza è determinata da fattori non solo tecnici, ma economici, sociali e di informazione.
Middleware mette a disposizione un completo ambiente di lavoro, realizzando un "framework" in cui, a servizi standard vengono affiancate applicazioni eseguibili "on-demand". Tra i servizi standard troviamo un browser internet, un programma per la gestione della posta elettronica, ed un file manager. Il passaggio da un servizio all'altro è segnalato da un messaggio vocale. Un servizio è un'applicazione gestita da Middleware, e quindi con la possibilità di usufruire di tutte le estensione dell'interfaccia di output. Ad ogni console viene associata un'applicazione (e quindi un servizio). È possibile spostarsi tra le varie console usando i tasti CTRL - ALT - Tasti Funzione, e CTRL - ALT GR - Tasti Funzione. Al cambio console, resta associato il cambio di servizio attivo, di cui ci informerà la voce di sistema. Un seconda voce, di utente, è utilizzata per l'output delle applicazioni.
Middleware, al suo interno, contiene vari componenti:
Figura 1. Architettura di Middleware
Nella figura 1, con la dicitura "kernel", si è inteso il key handler che dal kernel passa a Middleware i tasti premuti dall'utente. Access gestisce il caricamento in modo "accessibile" dei vari servizi. Per questo passa a Middleware le informazioni sull'applicazione, che si occuperà di caricare i Rule File corrispondenti all'applicazione stessa. Nel caso in cui non sia presente nel sistema alcun Rule File per il servizio desiderato, Middleware contatta via web un Repository (Rule File Server). Nel caso di risposta positiva dal Repository, il Rule File viene scaricato in locale ed aggiunto a quelli già presenti nel sistema.
Altro componente è lo Screen Reader (Krim), integrato in Middleware. Questo permette di leggere la riga, la parola o il carattere corrente. Essendo integrato in Middleware ha il vantaggio di avere il suo cursore sempre sincronizzato con quello di Middleware stesso. Il fatto di avere il cursore dello Screen Reader sempre sincronizzato con quello di Middleware aumenta l'efficacia del sistema stesso, in tutte quelle situazioni in cui il sistema non da una risposta soddisfacente o in cui si vogliono delle informazioni ulteriori a quelle fornite dal sistema.
L'engine di Middleware (Agni), si occupa di ricevere l'input utente, e nel caso lo passa allo Screen Reader, altrimenti cerca nel Rule File dell'applicazione attiva, l'azione corrispondente al tasto premuto. Le azioni sono presenti come moduli. In questo modo si ha possibilità di aggiungere nuove azioni ogni volta sia necessario. Ad esempio nel caso in cui si scarichi dal Repository un nuovo Rule File, e questo contenga nuove azioni. In questo caso Middleware chiede al Repository stesso di passargli anche i moduli corrispondenti alle azioni di cui mancano i moduli in locale.
Il sottosistema di buffering consente di avere un output più "umano". Permette infatti di evitare la ripetizione successiva dello stesso messaggio, avvisando però che l'ultimo messaggio è ripetuto n volte. Permette anche di ascoltare soltanto l'ultimo messaggio, saltando quelli precedenti, quando siano successivi. Permette così di sapere sempre "istantaneamente" quello che succede, evitando fastidiosi ritardi nell'ascolto dei messaggi.
Per la sintesi vocale vengono utilizzati Festival [FEST03] con il supporto per l'italiano [FestIT03] e MBrola [MBRL03]. Per il supporto ai dispositivi Braille viene utilizzato BRLTTY [BRLTTY]. Questi componenti vengono descritti più nel dettaglio in Appendice. Su Festival, MBrola e BRLTTY, si possono trovare ulteriori informazioni in Appendice.