Gentile sviluppatore,
Si sta avvicinando la WWDC 2015 con le sue novità riguardanti iOS, OSX, Watch OS e probabilmente anche nuovi prodotti o servizi di Apple.
NvApple.it e Macitynet.it seguiranno in diretta streaming il keynote di apertura della WWDC, divulgando tutte le novità ai propri lettori italiani, ma vorremmo porre l’attenzione su un settore dello sviluppo di applicazioni che spesso non viene considerato come invece meriterebbe: rendere accessibili alle persone con disabilità le applicazioni per dispositivi desktop e mobile, specialmente per quanto concerne la disabilità visiva e uditiva.
Apple ha sempre sviluppato molte tecnologie che permettono un utilizzo dei suoi prodotti, in totale autonomia, a persone con problemi di udito, di vista o di comunicazione verbale; sta di fatto che, per permettere a queste tecnologie di funzionare correttamente anche con la Sua applicazione, sarebbe opportuno che questa fosse accessibile!
Apple fornisce diversi modi per raggiungere tale obiettivo, ma è Lei l’unica persona che ha la facoltà di decidere se l’applicazione sia accessibile o no!
Per esempio, non dimentichi di assegnare un’etichetta testuale ai pulsanti della piacevole interfaccia grafica che Lei ha costruito, spiegando la reale funzione per la quale tali pulsanti sono stati progettati.
Inoltre, cerchi di usare controlli standard il più possibile: gli screen reader rilevano gli oggetti dell’interfaccia sulla base del loro ruolo semantico. Per esempio, sarebbe preferibile non utilizzare un oggetto cliccabile che semanticamente è un elemento testuale statico, ma che visivamente appare come un pulsante, effetto ottenuto tramite elementi non standard: lo screen reader rileverà quell’elemento come testo statico. Se per qualsiasi motivo non si può fare a meno di impiegare controlli personalizzati fuori standard, per favore si prenda il tempo di implementare il supporto alle API di accessibilità relative alla piattaforma per la quale sta sviluppando.
Siamo consapevoli che nell’era dello sviluppo multipiattaforma è molto difficile utilizzare soltanto i controlli nativi specifici di ogni interfaccia grafica, ma se si vuole avantaggiare dei controlli forniti da qualsiasi framework, si assicuri che in tale framework sia implementata anche l’accessibilità; se così non fosse, per favore prenda in considerazione l’utilizzo di un altro framework o di rendere accessibili i controlli di cui intende usufruire: nel caso di impiego di sistemi open source, può prendere in considerazione anche l’idea di contribuire inviando il codice da lei implementato alla relativa comunità di sviluppo, in modo che esso venga incluso in una prossima versione del framework. E’ possibile anche implementare controlli accessibili utilizzando tecnologie JavaScript e HTML.
Nel contesto dell’HTML e delle web app, si assicuri che il codice da Lei prodotto abbia un doctype esistente e validato W3C. la specifica Nelle applicazioni complesse, La invitiamo a utilizzare WAI-ARIA – http://www.w3.org/TR/WAI-ARIA – il più possibile.
Nei controlli personalizzati non conformi agli standard, se non è possibile utilizzare un’alternativa conforme, utilizzi un’etichetta dinamica. Esempio: se il controllo è “luce” e facendo tap la luce cambia stato da accesa a spenta, la invitiamo a etichettare il pulsante di conseguenza: “luce accesa”, e “luce spenta” quando si preme una volta. In altre parole, il valore dell’etichetta cambia al cambiare del valore booleano del controllo.
Non manchi di seguire gli eventi di WWDC15 dedicati all’accessibilità, ci saranno probabilmente diverse novità che siamo tutti ansiosi di vedere nelle sue app.
Ovviamente, avrà dei vantaggi dagli sforzi compiuti:
– la Sua applicazione avrà un pubblico più vasto;
– la Sua applicazione Le permetterà di guadagnare di più;
– soddisferà le esigenze di più persone.
Spett.le Apple
Apprezziamo gli sforzi per migliorare e rendere accessibili i vostri prodotti e il vostro impegno per permettere agli sviluppatori nuove modalità di comunicazione ma vorremmo fornirvi alcuni umili suggerimenti in più.
Per favore considerate l’idea di dare la visibilità che meritano, agli sviluppatori di terze parti che producono applicazioni accessibili.
Inserite un tag specifico nella descrizione in app store in modo che possiamo non solo riconoscere le applicazioni specificamente dedicate alle persone con disabilità, ma possiamo facilmente trovare applicazioni mainstream create sfruttando il design universale e progettate considerando anche l’accessibilità.
Vi invitiamo a considerare anche l’idea di integrare una funzione di app store disponibile se nel dispositivo in uso sono attivate tecnologie assistive come VoiceOver e/o Zoom, in modo che un utente possa:
– votare l’accessibilità di un’applicazione: “5 stelle generiche, una stella per l’accessibilità”, per esempio, votazione basata sul fatto che lo sviluppatore abbia o meno testato l’app per l’accessibilità, o se l’esperienza si basa sul giudizio degli utenti;
– richiedere un rimborso specificamente per questioni di inaccessibilità;
– sapere in anticipo se un’app è stata testata per l’accessibilità.
L’utente può ovviamente contribuire per aumentare o diminuire il valore della votazione, con i propri test e recensioni;
Abbiamo anche dei suggerimenti sulla lettura in Braille, soprattutto su OSX: l’output Braille può essere migliorato, in quanto alcune informazioni sono mostrate estese anziché abbreviate (“pulsante” potrebbe essere abbreviato per esempio con btn”). Quando si porta il cursore VoiceOver su un testo, per esempio in una pagina web, risulta faticoso leggere in quanto il cursore copre tutte le celle, rendendo difficile la comprensione specie se si stanno leggendo righe di codice.
Lettura dei PDF:
VoiceOver, nell’applicazione Anteprima, non interpreta laformattazione del testo PDF: niente link, niente intestazioni, impossibilità ad evidenziare il testo per prendere appunti, tutte funzioni utili per gli studenti. Vi invitiamo a prendere questi feedback in considerazione, per la prossima versione di Anteprima e di OSX.
