Tip:
Highlight text to annotate it
X
AEGIS har pågått i ganska precis 4 år nu,
och på de åren har vi, förutom att utveckla Open Accessibility Framework
- den teoretiska stödet för vårt arbete -
också visat hur det fungerar i skrivbordsmiljöer, på webben och för mobila enheter.
När vi utvecklade Open Accessibility Framework tittade vi på hur man bär sig åt för att bygga hus.
När man bygger krävs det många steg för att skapa någonting som är tillgängligt,
och många steg för att använda någonting som är tillgängligt.
I AEGIS överförde vi dessa steg för att skapa och använda till IKT.
Första steget till att skapa någonting som är tillgängligt i den fysiska världen
är att definiera vad "tillgängligt" betyder.
Hur bred måste en dörr vara för att en rullstol ska kunna komma igenom?
Vilken vinkel på rampen behöver du
för att någon ska kunna komma upp för den i rullstol?
Om vi har en hiss, när och hur ska den plinga?
Var någonstans ska vi ha Braille-information?
Vilka ytterligare taktila symboler borde vi använda
för att markera entreplanet i en hiss?
På samma sätt måste vi definiera vad "tillgänglighet" betyder inom IKT.
Vilket typ av tangentbord fungerar med det här användargränssnittet?
Är detta ett gränssnitt som kan visa höga kontraster eller stor stil?
Och vilket API eller tillgänglighetstjänst
tillåter hjälpmedel
att samverka med olika program?
Nästa steg för att skapa en fysiskt tillgänglig värld
är byggnadsmaterialet
När någon ska bygga ett hus, köper de dörrar.
Dörrarna måste uppfylla definitionen av tillgänglighet
De måste vara breda nog för en rullstol.
När jag vill köpa en hiss att sätta in i mitt hus
borde hissen redan vara utformad
för att plinga vid varje våning.
När jag köper ett plakat att sätta upp i hissen
har tillverkaren av plakatet redan
satt dit symboler för entreplan.
I datorernas värld och inom IKT kan man tänka på samma sätt.
Om jag skapar ett användargränssnitt med menyer och dialogrutor,
och element som checkrutor och reglage,
ska de kunna användas med tangentbordet.
De ska redan använda sig av API:er för tillgänglighet.
Jag ska kunna ställa in gränssnittet på höga kontraster eller stor stil
och det ska automatiskt ändra sig.
Med andra ord, gränssnitten borde använda sig av och stödja tillgänglighet från steg ett.
Det tredje steget är till för utvecklarna.
De verktyg som utvecklare använder för att bygga sina program
ska göra det väldigt enkelt att skapa tillgänglighet.
När man bygger hus finns det manualer och standarder för uppbyggnad,
som ingår i specifikationerna byggnadsarbetarna får.
Det finns till och med fysiska verktyg som kan mäta rullstolsrampen,
eller avgöra hur mycket kraft som behövs för att öppna en dörr
för att det ska kunna kallas tillgängligt.
På samma sätt ska verktygen som används av programutvecklare göra det enkelt
att dra och släppa tillgängliga komponenter i ett program
De ska låta mig i förväg kunna simulera hur olika teman ser ut,
och hur mitt program ser ut för en användare med funktionsnedsättning
genom höga kontraster eller stor stil.
Verktygen skulle också kunna markera och fixa till brister i tillgänglighet.
Det där handlade om att skapa. Vi ska också titta på hur det ser ut att använda.
I den fysiska världen vill vi se till så att vår tillgängliga byggnad ligger
nära bra kommunikationer med lokaltrafiken.
Vi vill se till så att den
har en rullstolsramp fram till entrén.
Om vi är vid en tillgänglig byggnad
vill vi också att övergångsställena ska vara tillgängliga
med knappar som är lätta att hitta,
och kanske med signaler eller ljudutrop för att hjälpa folk
att ta sig till den i övrigt tillgängliga byggnaden.
Inom IKT vill vi se till så att våra program kan köras på en tillgänglig plattform.
Är API:er för tillgänglighet synligt för hjälpmedel
på plattformen - operativsystemet?
Finns det stöd för att ansluta hjälpmedel?
Vi har säkerhetsspärrar i våra mobiltelefoner och andra apparater som vi måste
hantera när vi ska ansluta hjälpmedel,
så att de inte tas för virus.
Är det möjligt för användaren att välja
en anpassning med hög kontrast som används på hela plattformen?
Finns det stöd för talsyntes eller Braille,
eller annat som hjälpmedel kan behöva.
Det femte användarsteget är... att den där tillgängliga byggnaden behöver byggas.
Det tillgängliga programmet behöver byggas.
Det sjätte och sista steget är att få ut de hjälpmedel som används av personer med
funktionsnedsättning när de befinner sig i publika miljöer, i de tillgängliga byggnaderna.
Rullstolsramper är inte så användbara om ingen har en rullstol.
Så vi måste få ut fler rullstolar. Vi måste få fler att använda hörselhjälpmedel.
Få ut fler blindhundar och käppar för personer med synnedsättning,
och ge personer träning i att använda dem.
På samma sätt måste vi inom IKT
se till att hjälpmedel
finns för de personer som behöver dem.
Att det finns skärmläsare och skärmförstoringsverktyg,
att det finns skärmtangentbord, och att användare får lära sig hur de ska användas.
För att börja med webben, så har vi märkbart förbättrat
specifikationen för tillgängliga interaktiva webbapplikationer
och implementerat ARIA
tillsammans med IBM, våra kollegor inom öppen källkod, och även
implementerat det direkt i webbläsaren Firefox som är öppen källkod.
Den implementationen gör det också möjligt att använda ARIA
på Windows genom IAccessible2
och på Unix genom AT-SPI-gränssnittet i GNOME-miljö.
Det arbete vi har gjort i Firefox
har kopierats av Internet Explorer och av Apple Safari...
Det finns nu också i WebKitGTK i GNOME-miljö,
och det håller på att inkluderas i webbläsaren Opera.
Så det stöd som vi lade in i ARIA, och byggde in i Firefox,
är nu ledande inom industrin när det gäller ARIA.
Vi har också implementerat stöd för ARIA
i tre olika komponentuppsättningar: jQuery UI,
Fluid – Infusion,
och MooTools.
- Projekt.
Webbsidor.
Webbsida 1.
N, 3 typer av automatisk komplettering, Holland, Nya Zeeland...
- Vi har tagit dessa gränssnittskomponenter,
och vi har gjort det enkelt att bygga program med dessa komponenter genom ett öppen källkods-plugin
som vi utvecklade för NetBeans,
så att NetBeans-utvecklare mycket enklare kan skapa tillgängliga webbapplikationer.
Vi har sedan byggt ett antal exempel på tillgängliga webbapplikationer,
till exempel en tillgänglig kalender och en tillgänglig kartapplikation som använder SVG-kartor
för att hjälpa blinda användare att få en förståelse av en plats innan de ska dit.
För bloggförfattare eller CMS-utvecklare
tog vi dessa komponentuppsättningar
och lade in dem i WordPress,
så att vem som helst som använder WordPress nu har en uppsättning av tillgängliga komponenter
som de kan bygga WordPress-baserade CMS:er eller bloggar runt.
Vi har gjort någonting liknande inom JAVA-mobiler,
där vi först har först definierat API:et för AEGIS mobiltillgänglighet: AMIA.
Sedan använde vi AMIA på gränssnittsverktyget LWUIT
på LCD användargränssnitt och på AWT för JAVA ME-miljöer.
Vi definierade och implementerade stöd för anpassningar och teman för LWUIT.
Vi lade till stöd i redigeringsverktyget,
och i NetBeans som tar hand om den färdiga texten,
så att det blir enkelt för utvecklare att skapa tillgängliga LWUIT-applikationer för Java-mobiler.
För Android-applikationer med DroidDraw, som är öppen källkod,
lade vi till ytterligare tillgänglighetsstöd.
Vi har också skapat ett antal tillgängliga mobilapplikationer
som en tillgänglig webbläsare,
en mediaspelare som använder LWUIT, en tillgänglig telefonapplikation
och en kontaktbok för LCD UI LWUIT och Android.
Dessutom en tillgänglig realtidschatt för döva för Java-mobiler.
Förutom dessa heltäckande OAF-implementationer
har vi också byggt ett antal tredje generationens hjälpmedel
som använder det teoretiska ramverket och implementationen av det ramverket.
Så i Android-miljö har vi byggt ett väldigt innovativt hjälpmedel
för personer med stora rörelsehinder, som vi kallar för Tecla.
Tecla kan användas av en person i elrullstol som styr sin stol
t.ex. genom en joystick som de kontrollerar med hakan, eller en switch som de kan hantera med sin axel.
Hur de än styr sin rullstol kan vi använda detta sätt
för att styra en Androidtelefon trådlöst över Tecla.
Genom Tecla kan vi skriva in text, vi kan skicka och ta emot meddelanden, e-post, surfa på nätet...
Helt enkelt allt du kan göra med en telefon kan du också göra med Tecla.
Vi har också byggt en avancerad AKK-applikation som tillåter användare
att skapa konceptkodade AKK-gränssnitt
som sedan kan användas av någon på en Android-telefon för att kommunicera.
Och eftersom symboluppsättningarna som vi använder är symboler som har gjorts om till typsnitt
så kan vi nu använda dessa symboler för symbol-till-symbol-kommunikation via SMS
eller e-post eller på något annat sätt som man normalt kommunicerar på.
Du kan nu kommunicera med symboler genom att använda CCF-Droid.
Vi har gjort viktiga framsteg för författare genom att bygga ett plugin för
OpenOffice och LibreOffice som kallas för AccessODF.
Detta plugin går igenom dina dokument och markerar och hjälper dig fixa till brister i tillgängligheten,
t.ex. titlar som inte är rätt ifyllda,
rubriker som inte används rätt, eller om det inte finns beskrivningar till dina bilder.
När du väl har skapat ett tillgängligt dokument
kan du både exportera det som en vanlig PDF
och även genom ett plugin vi kallar för odt2Daisy, ett plugin utvecklat i AEGIS.
Genom detta kan du direkt skapa en digital ljudbok,
och med odt2Braille-pluginet
kan du skapa en taktil Braille-bok.
Vi har också konceptkodat stöd inbyggt genom ett annat plugin till OpenOffice och LibreOffice,
som låter personer med språkliga och kognitiva funktionsnedsättningar att använda symbolstöd
när de skapar dokument.
De kan antingen skapa text genom att välja symboler från ett tangentbord med symboler,
eller genom att använda bokstäver om de skriver text från det vanliga tangentbordet.
Symboler visas varje gång ett ord är färdigskrivet
för att ge ett visuellt stöd åt vad ordet betyder.
Detta är också väldigt användbart för personal som vill skapa symboler för personer de arbetar med.
De kan skriva på svenska eller engelska och programmet fyller automatiskt i symbolerna
så att de kan till exempel kan skapa ett spel med symboler
Vi har också bidragit på ett antal andra sätt.
Vi har på många sätt förbättrat
skrivbordsmiljön på Linux och Solaris med GNOME.
Vi har förbättrat de underliggande mekanismerna
som GNOME använder för tillgänglighet
och det är nu inbyggt i GNOME 3.
Det gör att tillgängliga miljöer som baseras på Linux nu kan köras på mycket mindre enheter
med mycket mindre minne och processorkapacitet jämfört med förut.
Vi skapade ett riktigt bra ramverk för förstoring i GNOME-miljön som är öppen källkod
och använde sedan detta för att bygga ett förstoringsverktyg.
Nu ändrar jag inställningarna här.
Just nu är förstoringsverktyget avstängt.
Så vi sätter på det, och då får nedre delen här en förstoring med en faktor av 2.
Nu kan vi göra det här fönstret till en flyttbar lins,
så det blir ungefär som att flytta ett förstoringsglas över skärmen.
Det här förstoringsverktyget är nu en del av GNOME 3.
Det har funnits ute i över ett år nu,
och används av personer med synnedsättning i hela Europa.
Vi har på många sätt gjort talsynteserna bättre i eSpeak, som också är öppen källkod,
genom att förbättra uttalet på spanska, grekiska
och på många andra europeiska språk.
Vi har byggt en infrastruktur för GNOME där det ingår en regressionstestningsfunktion
så att man ska kunna hitta ställen
där tillgängligheten kanske har blivit sämre än vad den var förut,
eller testa nya GNOME-applikationer för att vara säker på
att de använder sig av API:erna och ramverket för tillgänglighet på rätt sätt.
Vi skapade en uppsättning av många olika personas, licensierade under Creative Commons,
och de används nu för att lära ut tillgänglighet
och av utvecklare som vill få en förståelse för
användarfall och exempel på personer med olika typer av funktionsnedsättningar
för att lättare kunna skapa tillgängliga applikationer.
Och många, många fler saker�