# GNOME:s utvecklarguide för hjälpmedelsteknik

GNOME:s guide för hjälpmedelsteknik är för utvecklare som vill säkerställa att deras programmeringssträvanden är tillgängliga för största möjliga användarpublik. Denna guide täcker också många av kraven i avsnitt 508 i USA:s Rehabilitation Act.

2008
Vincent Alexander
2001, 2002
Calum Benson, Brian Cameron, Bill Haneman, Padraig O'Briain, Sharon Snider
Dokumentationsprojektet för GNOME

Tillstånd att kopiera, distribuera och/eller modifiera detta dokument ges under villkoren i GNU Free Documentation License (GFDL), version 1.1 eller senare, utgivet av Free Software Foundation utan standardavsnitt och omslagstexter. Du kan hitta en kopia av GFDL här eller i filen COPYING-DOCS som medföljer denna handbok.

Denna handbok utgör en av flera GNOME-handböcker som distribueras under villkoren i GFDL. Om du vill distribuera denna handbok separat från övriga handböcker kan du göra detta genom att lägga till en kopia av licensavtalet i handboken enligt instruktionerna i avsnitt 6 i licensavtalet.

Många av namnen som används av företag för att särskilja deras produkter och tjänster är registrerade varumärken. I de fall dessa namn förekommer i GNOME-dokumentation - och medlemmarna i GNOME-dokumentationsprojektet är medvetna om dessa varumärken - är de skrivna med versaler eller med inledande versal.

DOKUMENTET OCH MODIFIERADE VERSIONER AV DOKUMENTET TILLHANDAHÅLLS UNDER VILLKOREN I GNU FREE DOCUMENTATION LICENSE ENDAST UNDER FÖLJANDE FÖRUTSÄTTNINGAR:

1. DOKUMENTET TILLHANDAHÅLLS I "BEFINTLIGT SKICK" UTAN NÅGRA SOM HELST GARANTIER, VARE SIG UTTRYCKLIGA ELLER UNDERFÖRSTÅDDA, INKLUSIVE, MEN INTE BEGRÄNSAT TILL, GARANTIER ATT DOKUMENTET ELLER EN MODIFIERAD VERSION AV DOKUMENTET INTE INNEHÅLLER NÅGRA FELAKTIGHETER, ÄR SÄLJBART, ÄR LÄMPLIGT FÖR ETT VISST ÄNDAMÅL ELLER INTE STRIDER MOT LAG. HELA RISKEN VAD GÄLLER KVALITET, EXAKTHET OCH UTFÖRANDE AV DOKUMENTET OCH MODIFIERADE VERSIONER AV DOKUMENTET LIGGER HELT OCH HÅLLET PÅ DIG. OM ETT DOKUMENT ELLER EN MODIFIERAD VERSION AV ETT DOKUMENT SKULLE VISA SIG INNEHÅLLA FELAKTIGHETER I NÅGOT HÄNSEENDE ÄR DET DU (INTE DEN URSPRUNGLIGA SKRIBENTEN, FÖRFATTAREN ELLER NÅGON ANNAN MEDARBETARE) SOM FÅR STÅ FÖR ALLA EVENTUELLA KOSTNADER FÖR SERVICE, REPARATIONER ELLER KORRIGERINGAR. DENNA GARANTIFRISKRIVNING UTGÖR EN VÄSENTLIG DEL AV DETTA LICENSAVTAL. DETTA INNEBÄR ATT ALL ANVÄNDNING AV ETT DOKUMENT ELLER EN MODIFIERAD VERSION AV ETT DOKUMENT BEVILJAS ENDAST UNDER DENNA ANSVARSFRISKRIVNING;

2. UNDER INGA OMSTÄNDIGHETER ELLER INOM RAMEN FÖR NÅGON LAGSTIFTNING, OAVSETT OM DET GÄLLER KRÄNKNING (INKLUSIVE VÅRDSLÖSHET), KONTRAKT ELLER DYLIKT, SKA FÖRFATTAREN, DEN URSPRUNGLIGA SKRIBENTEN ELLER ANNAN MEDARBETARE ELLER ÅTERFÖRSÄLJARE AV DOKUMENTET ELLER AV EN MODIFIERAD VERSION AV DOKUMENTET ELLER NÅGON LEVERANTÖR TILL NÅGON AV NÄMNDA PARTER STÄLLAS ANSVARIG GENTEMOT NÅGON FÖR NÅGRA DIREKTA, INDIREKTA, SÄRSKILDA ELLER OFÖRUTSEDDA SKADOR ELLER FÖLJDSKADOR AV NÅGOT SLAG, INKLUSIVE, MEN INTE BEGRÄNSAT TILL, SKADOR BETRÄFFANDE FÖRLORAD GOODWILL, HINDER I ARBETET, DATORHAVERI ELLER NÅGRA ANDRA TÄNKBARA SKADOR ELLER FÖRLUSTER SOM KAN UPPKOMMA PÅ GRUND AV ELLER RELATERAT TILL ANVÄNDNINGEN AV DOKUMENTET ELLER MODIFIERADE VERSIONER AV DOKUMENTET, ÄVEN OM PART SKA HA BLIVIT INFORMERAD OM MÖJLIGHETEN TILL SÅDANA SKADOR.

Vincent
Alexander
Dokumentationsprojektet för GNOME
Calum
Benson
Dokumentationsprojektet för GNOME
Brian
Cameron
Dokumentationsprojektet för GNOME
Bill
Haneman
Dokumentationsprojektet för GNOME
Padraig
O'Briain
Dokumentationsprojektet för GNOME
Sharon
Snider
Dokumentationsprojektet för GNOME
GNOME 2.24 Utvecklarguide för hjälpmedelsteknik v2.24.0
September 2008

Dokumentationsprojektet för GNOME

Dokumentationsprojektet för GNOME

GNOME 2.24 Utvecklarguide för hjälpmedelsteknik v2.24.0
September 2008

Dokumentationsprojektet för GNOME

Dokumentationsprojektet för GNOME

Den här handboken beskriver version 2.24 av GNOME-skrivbordet.

## Återkoppling

För att rapportera ett fel eller komma med ett förslag för GNOME-skrivbordet eller denna handbok, följ instruktionerna på återkopplingssidan för GNOME.

Anders Jonsson
anders.jonsson@norsjovallen.se
2017
2018
Anders Jonsson

## Vad är tillgänglighet?

Tillgänglighet betyder att hjälpa personer som har funktionsnedsättningar med att delta i viktiga aktiviteter i livet. Detta inkluderar arbete samt utnyttjandet av tjänster, produkter och information. GNOME inkluderar bibliotek och ett stödramverk som låter personer med funktionsnedsättningar utnyttja all funktionalitet i GNOME:s användarmiljö.

Tillsammans med hjälpmedelsteknologier om så krävs - röstgränssnitt, skärmläsare, alternativa inmatningsenheter och så vidare - kan personer med bestående eller tillfälliga funktionsnedsättningar därför använda GNOME-skrivbordet samt dess program. Hjälpmedelsteknologier är också användbara för personer som använder datorer utanför hemmet eller kontoret. Om du till exempel sitter fast i trafiken skulle du kunna använda röstinmatning och uppläsning för att kontrollera din e-post.

Hjälpmedelsteknologier tar emot information från program genom Accessibility Toolkit-API:t (ATK), vilket du kan hitta i atk-modulen i GNOME-arkiven. Eftersom stöd för tillgänglighets-API:t är inbyggt i GNOME-komponenterna så bör ditt GNOME-program fungera hyfsat bra med hjälpmedelsteknologier utan något extra arbete från din sida. Till exempel kan hjälpmedelsteknologierna automatiskt läsa komponentetiketterna som du normalt skulle ställa in i ditt program i vilket fall (t.ex. med GTK-funktionsanrop så som `gtk_label_set_text()` eller `gtk_button_new_with_label()`). De kan också se om det finns någon text för en inforuta associerad med en komponent, och använda den för att beskriva komponenten för användaren.

Med lite extra ansträngning kan du dock få ditt program att fungera ännu smidigare med hjälpmedelsteknologier. Förutom att hjälpa enskilda användare så kommer det också att göra din produkt mer attraktiv för myndighets- och utbildningsmarknader, av vilka många enligt lag nu kräver att deras program ska vara tillgängliga.

### Typer av funktionsnedsättning

Enbart i USA finns det uppskattningsvis 30 000 000 personer vars förmåga att använda datorer begränsas av design som inte är tillgänglig. Globalt har omkring 8% av personerna som använder internet något slags funktionshinder. Funktionshinder delas upp i dessa kategorier:

- Synnedsättningar - dessa kan variera från dålig syn (inklusive dunkel eller suddig syn, extrem när- eller översynthet, färgblindhet, tunnelseende med flera) till fullständigt blindhet. Ett dåligt val av storlek och färg på text, samt uppgifter som kräver god öga-handkoordination (så som att flytta på musen) kan orsaka problem för dessa användare.

- Rörelsenedsättningar - användare med dålig muskelkontroll eller muskelsvaghet kan ha svårt att använda ett vanligt tangentbord eller en mus. Till exempel kan de kanske inte hålla ned två knappar samtidigt, eller så kan de ha större risk att trycka ned tangenter oavsiktligt.

- Hörselnedsättningar - dessa kan variera från att kunna höra vissa ljud men inte kunna särskilja talade ord, till dövhet. Program som uttrycker viktig information enbart genom ljud kommer att orsaka problem för dessa användare.

- Kognitiva nedsättningar och språknedsättningar - dessa kan variera från dyslexi till att ha svårigheter att komma ihåg saker, lösa problem eller att förstå och använda talat eller skrivet språk. Komplex eller inkonsekvent visning, eller olämpliga ordval kan göra datoranvändning svår för dessa användare.

- Krampsjukdomar - vissa ljus- eller ljudmönster kan orsaka epileptiska krampanfall hos mottagliga användare.

### Hur tillgänglighet fungerar i GNOME

Tillgänglighetsverktygslådan ATK (Accessibility Toolkit) beskriver en uppsättning gränssnitt som måste implementeras av grafiska användargränssnittskomponenter för att göra dem tillgängliga. Gränssnitten är oberoende av verktygslåda - implementationer kan skrivas för valfri komponentuppsättning, så som GTK, Motif eller Qt.

Implementationen för GTK-komponenterna är i en modul som kallas GAIL (GNOME Accessibility Implementation Library), vilken är dynamiskt inläsbar vid körtid av ett GTK-program. Då den är inläst kommer de delar av ditt program som använder GTK-standardkomponenter att ha en grundläggande tillgänglighetsnivå, utan att du behöver modifiera ditt program över huvud taget. Om GAIL inte är inläst kommer GTK-komponenter att ha en standardimplementation för tillgänglighet som i praktiken inte returnerar någon information, även om den formellt sett följer ATK-API:t. Program som använder Bonobo-kontroller, speciellt utanför processen, läser även in stödkod för tillgänglighet från modulen libgail-gnome. Huruvida program i GNOME-skrivbordet läser in dessa stödbibliotek för tillgänglighet eller inte beror på värdet av en gconf-nyckel, ”/desktop/gnome/interface/accessibility”; det booleska värdet ”true” (sant) aktiverar stöd för hjälpmedelsteknologier och program som anropar gnome_program_init kommer automatiskt att läsa in lämpliga tillgänglighetsbibliotek vid körtid. ”Rena GTK+-program”, exempelvis de som använder gtk+ men inte länkar till libgnome, förlitar sig på värdet av GTK_MODULES-miljövariabeln, vilken måste sättas till ”gail:atk-bridge” för att aktivera stöd för hjälpmedelsteknologier.

De flesta hjälpmedelsteknologier som körs på andra skrivbord har historiskt funnit det nödvändigt att bibehålla en komplex modell vid sidan om skärmen av skrivbordsprogrammen, baserat på tjuvlyssnande på händelser i operativsystemet, användning av funktioner och API:er som inte har stöd i operativsystem och program, och andra tekniker som är ytterst oporterbara. Detta har gjort stöd för hjälpmedelsteknologier något ”sköra” samt högst beroende på operativsystem och program, till och med beroende på programversion. I kontrast till detta tillhandahålls på GNOME-skrivbordet all information som hjälpmedelsteknologier behöver av de körande programmen, via GNOME:s tillgänglighetsramverk, till ett verktygslådeoberoende tjänsteleverantörsgränssnitt (Service Provider Interface, SPI). SPI tillhandahåller ett sätt för UNIX-baserade hjälpmedelsteknologier, så som skärmläsare och skärmförstorare, att erhålla tillgänglighetsinformation från körande program via ett konsekvent, stabilt API, och kan eliminera behovet av en modell vid sidan om skärmen i många fall. Tillgänglighetsstöd för program är ”inbyggt” för programverktygslådor via verktygslådelämpliga API:er (till exempel, ATK för de flesta inhemska C-program och Java-tillgänglighets-API:t för Java-program), och exporteras till det allmänna ”AT-SPI”-gränssnittet via den relevanta ”bryggan” (se diagram nedan).

#### GNOME:s tillgänglighetsarkitektur

Diagram över GNOME:s tillgänglighetsarkitektur

GNOME:s inbyggda tillgänglighetsstöd innebär att program som skapats med GNOME:s standardkomponenter får stöd för hjälpmedelsteknologier ”gratis”, under förutsättning att komponenterna inte används på ovanliga sätt som strider mot detta inbyggda stöd.

En gtk+/GNOME-komponent är tillgänglig om dess användning följer de allmänna tillgänglighetsriktlinjerna i resten av detta dokument, och implementerar de ATK-gränssnitt som är lämpliga för dess roll i användargränssnittet. ATK-implementationer tillhandahålls för ”standard”-komponenterna i GNOME-verktygslådan (d.v.s. gtk+- och GNOME-komponenter som inte är föråldrade), och i många fall kommer även nya komponenter som härletts trivialt från befintliga GTK+- eller GNOME-komponenter att ärva lämpligt tillgänglighetsstöd.

Även om GNOME:s inbyggda stöd för tillgänglighet tillhandahåller betydande funktionalitet utan några tillgänglighetsspecifika kodändringar från programmets sida, så kan program ofta förbättra standardbeskrivningarna som tillhandahålls för vissa av komponenterna, och skräddarsy dem efter komponentens specifika syfte i ditt program, via enkla anrop till ATK-metoder i programmet. Till exempel bör program för det mesta lägga till eller ändra textbeskrivningarna för dessa komponenter med lämpligt ATK-funktionsanrop, så att en hjälpmedelsteknologi kan beskriva deras syfte eller tillstånd för användaren. Se Kodriktlinjer för att stödja tillgänglighet för mer information.

Om ditt program använder anpassade komponenter kan du behöva utföra lite arbete för att exponera dessa komponenters egenskaper för hjälpmedelsteknologier. Se Göra anpassade komponenter tillgängliga och Exempel som använder tillgänglighets-API:t för mer information.

För ytterligare, djupgående information om GTK/GTK+, se referenshandboken för GTK+, GTK-avsnittet i ATK-Guiden, GTK+ 2.0-guiden på GNOME:s webbplats och den officiella frågor och svar-sidan för GTK+.

### Snabbstart för utvecklare

Här är några vanliga startpunkter:

#### Hur kontrollerar jag om mitt program är tillgängligt eller inte?

För att börja direkt, se Göra ett GNOME-program tillgängligt - Överblick. För att få ett perspektiv innan kodningen, se Riktlinjer för användargränssnitt som stöder tillgänglighet eller Kodriktlinjer för att stödja tillgänglighet. För en kontrollista över testposter efter designen, se Kontrollista för användargränssnitt.

#### Vad är de vanligaste fallgroparna?

Kontrollistan för användargränssnitt täcker alla områden som ibland förbises i designfasen.

#### Hur gör jag vanliga ATK-saker?

En förkortad lista över vanliga ATK-anrop kan hittas här.

#### Hur gör jag mer komplexa ATK-saker?

Se Göra anpassade komponenter tillgängliga och Exempel som använder tillgänglighets-API:t för mer information.

#### Introduktion av ATK, AT-SPI, GAIL och GTK+

GNOME:s tillgänglighetsarkitektur

ATK är verktygslådan som GNOME använder för att möjliggöra tillgänglighet för användare som behöver extra stöd för att använda sina datorer till fullo. ATK används av verktyg så som skärmläsare, skärmförstorare och inmatningsenheter för att tillåta en rik interaktion med skrivbordet på alternativa sätt. Se ATK:s SourceForge-projekt och ATK-biblioteket för mer information.

AT-SPI är det primära tjänstegränssnittets enligt vilket hjälpmedelsteknologier efterfrågar och tar emot aviseringar från körande program. Det fullständiga API:t kan utforskas här. Ytterligare material finns tillgängligt från KDE:s utvecklingsgemenskap för tillgänglighet.

GAIL (GNOME Accessibility Implementation Library) är en implementation av tillgänglighetsgränssnitten som definieras av ATK. GTK är en verktygslåda som redan är mappad till ATK av GAIL-modulen. Licens, hur den kan hämtas och annan information kan hittas här. Källkoden för GAIL tjänar också som en utmärkt guide för avancerad ATK-användning. Du kan dessutom vara intresserad av referenshandboken för GAIL.

GTK+ är ett bibliotek för att skapa grafiska användargränssnitt. Det fungerar på många UNIX-liknande plattformar, Windows, och på rambuffertenheter. GTK+ är släppt under GNU Library General Public License (GNU LGPL), vilken tillåter flexibel licensiering av klientprogram. GTK+ har en C-baserad objektorienterad arkitektur som tillåter maximal flexibilitet. Bindningar för andra språk har skrivits, bland annat C++, Objective-C, Guile/Scheme, Perl, Python, TOM, Ada95, Free Pascal och Eiffel.

För ytterligare, djupgående information om GTK/GTK+, se referenshandboken för GTK+, GTK-avsnittet i ATK-Guiden, GTK+ 2.0-guiden på GNOME:s webbplats och den officiella frågor och svar-sidan för GTK+.

### Göra ett GNOME-program tillgängligt - Överblick

Om ditt program endast använder GTK-standardkomponenter behöver du troligen göra lite eller ingenting för att få ditt program (någorlunda) tillgängligt. Men se upp för objekt i ditt grafiska användargränssnitt som inte har en textbeskrivning associerad med sig, så som grafiska knappar eller statusindikatorer som inte har etiketter eller inforutor.

Du kan troligen också förbättra standardbeskrivningarna som tillhandahålls för några av komponenterna, och skräddarsy dem efter komponentens specifika syfte i ditt program. Du bör lägga till eller ändra textbeskrivningarna för dessa komponenter med lämpligt ATK-funktionsanrop, så att en hjälpmedelsteknologi kan beskriva deras syfte eller tillstånd för användaren. Se Kodriktlinjer för att stödja tillgänglighet för mer information.

Om ditt program använder anpassade komponenter kan du behöva utföra lite arbete för att exponera dessa komponenters egenskaper för hjälpmedelsteknologier. Se Göra anpassade komponenter tillgängliga och Exempel som använder tillgänglighets-API:t för mer information. Vidare kan detaljerad information hittas i Marc Mulcahys GUADEC-presentation från 2002: ”Making GNOME Applications Accessible”.

### Kodriktlinjer för att stödja tillgänglighet

Här är några saker du kan göra i din kod för att få ditt program att fungera så bra som möjligt med hjälpmedelsteknologier. (Du kan hitta en lista över saker att överväga då du designar ditt grafiska användargränssnitt i avsnittet Riktlinjer för användargränssnitt som stöder tillgänglighet senare i detta dokument):

- För komponenter som inte visar en kort sträng (så som en grafisk knapp), ange ett namn för den med `atk_object_set_name()`. Du kan vilja göra detta för knappar med bara bilder, paneler som tillhandahåller logiska grupperingar, textområden och så vidare.

- Om du inte kan tillhandahålla en inforuta för en komponent, använd istället `atk_object_set_description()` för att tillhandahålla en beskrivning som hjälpmedelsteknologier kan ge användaren. För att till exempel tillhandahålla en tillgänglig beskrivning för en Stäng-knapp:

  #### Tillhandahålla en tillgänglighetsbeskrivning för en GtkButton

      {
        AtkObject *obj;
        obj = gtk_widget_get_accessible(button);
        atk_object_set_description(obj,_("Stänger fönstret"));
      }

- Använd `atk_image_set_description()` för att tillhandahålla en textbeskrivning för alla bilder och ikoner i ditt program.

- Om flera komponenter formar en logisk grupp, försök placera dem i en behållare.

- Närhelst du har en etikett som beskriver en annan komponent, använd `atk_relation_set_add_relation()` så att hjälpmedelsteknologier kan hitta komponenten som etiketten är associerad med. (Om du associerar etiketten med komponenten med hjälp av `gtk_label_set_mnemonic_widget()` så genereras `ATK_RELATION_LABEL_FOR`-relationen automatiskt, så följande kod skulle inte vara nödvändig):

  #### Relatera en GtkLabel till en GtkWidget

      {
        GtkWidget *widget;
        GtkLabel *label;

        AtkObject *atk_widget, *atk_label;
        AtkRelationSet *relation_set;
        AtkRelation *relation;
        AtkObject *targets[1];

        atk_widget = gtk_widget_get_accessible(widget);
        atk_label = gtk_widget_get_accessible (GTK_WIDGET(label));

        relation_set = atk_object_ref_relation_set (atk_label);
        targets[0] = atk_widget;

        relation = atk_relation_new(targets,1, ATK_RELATION_LABEL_FOR);
        atk_relation_set_add(relation_set,relation);
        g_object_unref(G_OBJECT(relation));
      }

- Om du skapar en anpassad komponent, säkerställ att den stöder tillgänglighet. Anpassade komponenter som är ättlingar till andra GTK-komponenter bör åsidosätta ärvd tillgänglighetsinformation där så är lämpligt. För mer information, se Göra anpassade komponenter tillgängliga.

- Förstör inte det som du får gratis! Om ditt grafiska användargränssnitt har en otillgänglig behållare så kan det hända att alla komponenter i den behållaren blir otillgängliga.

### Tillgänglighets-API:t

Här är några av de grundläggande API-anrop du kan behöva använda i ditt program för att säkerställa att det fungerar bra med hjälpmedelsteknologier. Det fullständiga tillgänglighets-API:t är omfattande, för att exempelvis låta dig skriva dina egna anpassade tillgängliga komponenter.

#### Ofta använda ATK-API-anrop

API | Beskrivning
--- | ---
`AtkObject* gtk_widget_get_accessible (GtkWidget*)` | Returnerar det tillgängliga objektet som beskriver den angivna GTK-komponenten till en hjälpmedelsteknologi.
`void atk_object_set_name (AtkObject*, const gchar*)` | Ställer in namnet för det tillgängliga objektet. Om objektet till exempel är en grafisk knapp som avslutar programmet då den trycks ned så kan namnet vara ”Avsluta”.
`void atk_object_set_description (AtkObject*, const gchar*)` | Ställer in textbeskrivningen för det tillgängliga objektet. Om objektet till exempel är en grafisk ”Stäng”-knapp så kan beskrivningen vara ”Stänger fönstret”.
`AtkRelation* atk_relation_new (AtkObject**, gint, AtkRelationType)` | Skapar en ny relation mellan den angivna nyckeln och den angivna listan över målobjekt. En relation indikerar vanligen till hjälpmedelsteknologin att en komponent är relaterad till en annan på något sätt. Till exempel att en viss GtkLabel-komponent är texten för en GtkTreeView i samma fönster.
`void atk_image_set_description (AtkImage*, const gchar*)` | Ställer in textbeskrivningen för det tillgängliga bildobjektet. Om objektet till exempel är en miniatyrbild av ett virtuellt skrivbord i ett panelminiprogram så kan beskrivningen vara ”Bild som visar fönsterplacering på skrivbord 1”.

### Exempel som använder tillgänglighets-API:t

Som nämnts tidigare bör det kräva liten eller ingen ansträngning för att göra ditt program tillgängligt om du använder GTK-komponentuppsättningen, eller något annat komponentbibliotek som implementerar ATK-gränssnitten. De två vanligaste sakerna som du kan behöva göra i detta fall är:

- tillhandahålla beskrivningar av några kontroller och bilder med `atk_object_set_description()` eller `atk_image_set_description():`

  #### Ställa in tillgänglighetsbeskrivningen för en knapp

      {
         AtkObject *obj;
         obj = gtk_widget_get_accessible(button);
         atk_object_set_description(obj,_("Öppnar dialogrutan Inställningar"));
      }

- Ange relationer mellan ovanliga grupperingar av komponenter med `atk_relation_new()` och `atk_relation_set_add()`:

  #### Ange en tillgänglig relation mellan två kontroller

      {
        GtkWidget *widget;
        GtkLabel *label;

        AtkObject *atk_widget, *atk_label;
        AtkRelationSet *relation_set;
        AtkRelation *relation;
        AtkObject *targets[1];

        atk_widget = gtk_widget_get_accessible (widget);
        atk_label = gtk_widget_get_accessible (GTK_WIDGET(label));

        relation_set = atk_object_ref_relation_set (atk_label);
        targets[0] = atk_widget;

        relation = atk_relation_new(targets,1, ATK_RELATION_LABEL_FOR);
        atk_relation_set_add(relation_set,relation);
        g_object_unref(G_OBJECT(relation));
      }

Exemplen i resten av detta avsnitt är mest till för att ge dig en försmak av omfånget av ATK. De täcker tekniker som du kanske aldrig kommer behöva använda som en programutvecklare, men de kan vara av intresse om du skriver egna anpassade komponenter (se Göra anpassade komponenter tillgängliga) eller om du vill skriva ett hjälpmedelsteknologiprogram. Vad än syftet är så tjänar källkoden för GAIL som en utmärkt guide för avancerad ATK-användning. Observera att sedan GTK+ 3.1.10 så har Gail sammanfogats in i GTK+ och är inte längre en fristående modul.

#### GTK-moduler

Program som använder GAIL (tillgänglighetsimplementationsbiblioteket för GTK-komponenter) skrivs som GTK-moduler. GTK-moduler läses in i programrymden om miljövariabeln `GTK_MODULES` anger namn på ett eller flera modulbibliotek. Om det finns flera modulbibliotek, separera dem med kolon. Till exempel:

`setenv GTK_MODULES "libgail:libtestprops"`

Alla GTK-moduler har en `gtk_module_init()`-funktion.

#### Erhålla tillgänglighetsinformation från ett program

Ett program som önskar använda ATK-anrop kommer troligen behöva göra en (eller flera) av följande saker:

1. Skapa en händelseövervakare, till exempel med `atk_add_focus_tracker()`-funktionen:

       atk_add_focus_tracker (_my_focus_tracker);

   där `_my_focus_tracker()` är en funktion med denna prototyp:

       void _my_focus_tracker (AtkObject *aobject);

2. Konfigurera en global händelselyssnare med atk_add_global_event_listener():

       mouse_watcher_focus_id =   atk_add_global_event_listener(_my_global_listener,"Gtk:GtkWidget:enter_notify_event");

   där `_my_global_listener` har prototypen av en GSignalEmissionHook i Glib. Detta exempel skulle få `_my_global_listener()` att anropas närhelst en enter_notify_event-signal inträffar på ett GtkWidget-objekt.

3. Kom åt ATK-toppnivåobjektet med följande funktionsanrop.

       AtkObject *root_obj = atk_get_root();

   Detta returnerar ett AtkObject som innehåller alla toppnivåfönster i programmet som för närvarande körs. Användaren skulle sedan kunna navigera genom objekthierarkin genom att komma åt rotobjektets underordnade objekt, vilket motsvarar toppnivåfönstren.

#### Efterfråga ett AtkObjects gränssnitt

Då du har hittat det AtkObject som är associerat med ett objekt i programmet (t.ex. genom att använda `gtk_widget_get_accessible()`) så kan du få reda på vilka gränssnitt som det implementerar på olika sätt:

1. Använd de tillhandahållna `ATK_IS_…`-makrona, till exempel:

   - `ATK_IS_ACTION(atkobj)`

   - `ATK_IS_COMPONENT(atkobj)`

   - o.s.v. (det finns en för varje gränssnitt)

   Om makrot returnerar `TRUE` kan gränssnittsanropen utan risk göras på det ATK-objektet.

2. Testar rollen för ett AtkObject genom att anropa `atk_object_get_role()`. Alla givna roller implementerar ett specifikt antal ATK-API:er.

#### Konfigurera en ATK-signalhanterare

Med signalen `column_inserted` som ett exempel:

    table_column_inserted_id = g_signal_connect_closure_by_id (my_atk_obj,
    g_signal_lookup("column_inserted", G_OBJECT_TYPE(my_atk_obj)), 0,
    g_cclosure_new(G_CALLBACK (_my_table_column_inserted_func), NULL, NULL), FALSE);

Detta kommer att få `_my_table_column_inserted_func()` att anropas närhelst en column_inserted-signal sänds på AtkObjectet `my_atk_object`.

Att ansluta till en signal är något annorlunda om signalen stöder detaljer. Signalen `children_changed` stöder detaljen `add`. För att ansluta till en signal då detaljen `add` också är angiven används denna teknik:

    child_added_id = g_signal_connect_closure (my_atk_obj,"children_changed::add",
    g_cclosure_new (G_CALLBACK(_my_children_changed_func), NULL, NULL), FALSE);

Detta kommer att få `_my_children_changed_func()` att anropas närhelst en `children_changed`-signal med detaljen `add` sänds på AtkObjectet `my_atk_obj`.

#### Implementera ett ATK-objekt

Du kommer behöva implementera dina egna ATK-objekt för komponenter som inte redan har en tillgänglig implementation i GAIL (eller motsvarande bibliotek för andra komponentuppsättningar). Detta bör implementeras som en GTK-modul, vilken som tidigare bör inkluderas i miljövariabeln `GTK_MODULES` så att den läses in vid körtid.

##### Register

För detta exempel kommer vi att anta att det finns ett objekt kallat GTK_TYPE_MYTYPE. ATK-implementationen kommer att kallas MYATKIMP_TYPE_MYTYPE. En fabrik kommer att behövas vilken kommer att kallas MYATKIMP_TYPE_MYTYPE_FACTORY.

För att registrera en ATK-implementation för ett GTK-objekt måste dessa steg följas i modulens `gtk_module_init()`-funktion:

1. Kom åt standardregistret:

       default_registry = atk_get_default_registry();

2. Registrera ATK-objektet i `gtk_module_init()`-funktionen för denna modul genom att göra detta funktionsanrop:

       atk_registry_set_factory_type (default_registry, GTK_TYPE_MYTYPE,
       MYATKIMP_TYPE_MYTYPE_FACTORY);

Detta kommer att registrera AtkObject-implementationen av GTK_TYPE_MYTYPE till MYATKIMP_TYPE_MYTYPE_FACTORY. Denna fabrik kommer att implementeras så att den vet hur objekt av typen MYATKIMP_TYPE_MYTYPE ska byggas.

##### Fabrik

Fabriken måste implementeras som underordnad klasstypen ATK_TYPE_OBJECT_FACTORY och måste implementera funktionen `create_accessible()`. Denna funktion måste skapa ett lämpligt AtkObject. En fabrik kan användas för att skapa mer än en typ av objekt, i vilket fall dess `create_accessible()`-funktion kommer behöva vara smart nog för att bygga och returnera rätt AtkObject.

##### ATK-implementation för ett specifikt objekt

Alla GObject implementerar en `get_type()`-funktion. Om vi använder exemplet ovan så skulle namnkonventionen för detta funktionsnamn vara `myatkimp_mytype_get_type()`.

I denna funktion anger du vilka gränssnitt som ditt objekt implementerar. Om följande logik skulle inkluderas i denna `get_type()`-funktion så skulle detta objekt implementera ATK_TEXT-gränssnittet:

###### Exempel på en `get_type()`-funktion

    static const GInterfaceInfo atk_text_info =
    {
       (GInterfaceInitFunc) atk_text_interface_init,
       (GInterfaceFinalizeFunc) NULL,
       NULL
    };

    g_type_add_interface_static (type, ATK_TYPE_TEXT,
                                 &atk_text_info);

Funktionen `atk_text_interface_init()`, som har följande prototyp, skulle behöva implementeras:

    void atk_text_interface_init (AtkTextIface *iface);

Denna funktion skulle ansluta gränssnittets funktionsanrop till den specifika implementationen enligt följande:

###### Ansluta anpassade gränssnittsanrop till en AtkObject-implementation

    void
    atk_text_interface_init (AtkTextIface *iface)
    {
       g_return_if_fail (iface != NULL);
       iface->get_text = myatkimp_mytype_get_text;
       iface->get_character_at_offset = myatkimp_mytype_get_character_at_offset;
       ...
    }

Då skulle funktionerna `myatkimp_mytype_get_text()`, `myatkimp_mytype_get_character_at_offset()` och resten av ATK_TEXT-gränssnittsfunktionerna behöva implementeras.

##### AtkObject-implementation

Alla AtkObject är GObject, och alla GObject behöver ange `get_type()`-funktionen. Här är ett exempel som konfigurerar en klass- och instansinitierare. Denna `get_type()`-funktion anger också att objektet implementerar ATK_TEXT och anger att det överordnade objektet är MYATKIMP_MYPARENTTYPE.

###### Exempel på en `get_type()`-implementation

    GType
    myatkimp_mytype_get_type (void)
    {
       static GType type = 0;

       if (!type)
       {
          static const GTypeInfo tinfo =
          {
             sizeof (GailLabelClass),
             (GBaseInitFunc) NULL,                              /* base init */
             (GBaseFinalizeFunc) NULL,                          /* base finalize */
             (GClassInitFunc) myatkimp_mytype_class_init,       /* class init */
             (GClassFinalizeFunc) NULL,                         /* class finalize */
             NULL,                                              /* class data */
             sizeof (GailLabel),                                /* instance size */
             0,                                                 /* nb preallocs */
             (GInstanceInitFunc) myatkimp_mytype_instance_init, /* instance init */
             NULL                                               /* value table */
          };

          /* Konfigurera atk_text_info-struktur använd nedan */
          static const GInterfaceInfo atk_text_info =
          {
             (GInterfaceInitFunc) atk_text_interface_init,
             (GInterfaceFinalizeFunc) NULL,
             NULL
          };

          /* Konfigurera typnamn och ange överordnad typ */
          type = g_type_register_static (MYATKIMP_MYPARENTTYPE,
                "MyatkimpMytype", &tinfo, 0);

          /* Denna klass implementerar gränssnittet ATK_TYPE_TEXT */
          g_type_add_interface_static (type, ATK_TYPE_TEXT,
                                       &atk_text_info);
       }
       return type;
    }

##### Klass-/Instansinitierare

Du kommer behöva konfigurera en klassinitierare för ditt GObject om din AtkObject-implementation antingen:

1. Omdefinierar funktionsanrop som definierats av objektets överordnade objekt. Detta är typiskt nödvändigt då ett objekt behöver implementera en funktion som `atk_object_get_n_accessible_children()`. Detta är nödvändigt om objektet har underordnade objekt, men de inte är representerade av komponenter.

   Om till exempel din ATK-implementation behöver åsidosätta AtkObject-funktionen `get_name()` så skulle klassinitieraren se ut som:

   ###### Klassinitierare som åsidosätter överordnad `get_name()`-funktion

       myatkimp_mytype_class_init (GailLabelClass *klass)
       {
         AtkObjectClass *class = ATK_OBJECT_CLASS (klass);
         class->get_name = myatkimp_mytype_get_name;
       }

2. Kräver en `parent->init`-, `parent->notify_gtk`- eller `parent->finalize`-funktion. Detta exempel definierar alla tre:

   ###### Klassinitierare som definierar sina egna `init()`-, `notify_gtk()`- och `finalize()`-funktioner

       static ParentObjectType *parent_class = NULL;

       myatkimp_mytype_class_init (GailLabelClass *klass)
       {
          ParentObjectType *parent_class = (ParentObjectType*)klass;

          /*
           * Att cacha parent_class är nödvändigt om funktionerna
           * init, notify_gtk eller finalize är konfigurerade.
           */
           parent_class = g_type_class_ref (MYATKIMP_TYPE_PARENT);

           parent_class->init = myatkimp_mytype_widget_init;
           parent_class->notify_gtk = myatkimp_mytype_real_notify_gtk;
           parent_class->finalize = myatkimp_mytype_finalize;
       }

   1. parent->init

      En `parent->init()`-funktion kan behövas om ATK-implementationen behöver göra något av följande:

      1. Cacha alla data som erhålls från en bakomliggande GTK-komponent.

      2. Lyssna på alla signaler från bakomliggande GTK-komponent.

      Här kommer ett exempel på båda:

      ###### En anpassad `init()`-funktion

          void
          gail_tree_view_widget_init (MyatkimpMytype  *mytype,
                                      GtkWidget       *gtk_widget)
          {
             /* Säkerställ att anropa överordnad init-funktion */
             parent_class->init (widget, gtk_widget);

             /* Cacha ett värde i ATK-implementationen */
             mytype->cached_value = gtk_widget_function_call();

             /* Lyssna på en signal */
             gtk_signal_connect (GTK_OBJECT (gtk_widget),
                                 "signal-type",
                                 GTK_SIGNAL_FUNC (_myatkimp_mytype_signal_type),
                                 NULL);
          }

      I detta exempel skulle, om den angivna signal-type-signalen genererades på bakomliggande `gtk_widget`, i så fall funktionen `_myatkimp_mytype_signal_type()` anropas.

   2. parent->notify_gtk

      Om ATK-implementationen behöver lyssna på några egenskapsaviseringar på det bakomliggande GTK-objektet, så kan en `parent->notify_gtk()`-funktion vara nödvändig. Till exempel:

      ###### En anpassad `notify_gtk()`-funktion

          void
          myatkimp_mytype_real_notify_gtk (GObject    *obj,
                                           GParamSpec *pspec)
          {
             GtkWidget *widget = GTK_WIDGET (obj);
             AtkObject* atk_obj = gtk_widget_get_accessible (widget);

             if (strcmp (pspec->name, "property-of-interest") == 0)
             {
                /* Hantera egenskapsändringen. */
             }
             else
             {
                parent_class->notify_gtk (obj, pspec);
             }
          }

   3. parent->finalize

      Om det är nödvändigt att frigöra data när en GObject-instans förstörs så behövs en `finalize()`-funktion för att frigöra minnet. Till exempel:

      ###### En anpassad `finalize()`-funktion

          void
          myatkimp_mytype_finalize (GObject *object)
          {
             MyAtkimpMyType *my_type = MYATKIMP_MYTYPE (object);

             g_object_unref (my_type->cached_value);
             G_OBJECT_CLASS (parent_class)->finalize (object);
          }

### Göra anpassade komponenter tillgängliga

Att lägga till ATK-stöd till din anpassade komponent kommer att säkerställa dess samarbete med tillgänglighetsinfrastrukturen. Detta är de allmänna steg som krävs:

- bedöm en anpassad komponent enligt de riktlinjer för användargränssnitt som är tillämpliga;

- avgör vilka ATK-gränssnitt som en anpassad komponent ska implementera enligt komponentens funktionsuppsättning och funktionalitet;

- bedöm vilka ATK-gränssnitt som kan ärvas från den överordnade komponentklassen;

- implementera de lämpliga ATK-gränssnitten för komponentklassen på ett av två sätt:

  - direkt av den anpassade komponenten, eller

  - i en AtkObject-undertyp skapad av en ny AtkObjectFactory-underklass

  Om den andra metoden används måste den lämpliga fabrikstypen registreras med AtkObjectFactoryRegistry vid körtid.

Källkoden för GAIL tjänar som en utmärkt guide för avancerad ATK-användning.

### Riktlinjer för användargränssnitt som stöder tillgänglighet

Då du designar ditt programs grafiska användargränssnitt finns det ett antal enkla riktlinjer som du bör följa för att säkerställa att det kan användas av en så bred publik som möjligt, vare sig detta är i kombination med hjälpmedelsteknologier eller inte. Bli inte lurad att tänka att detta bara är ett fall av att ”göra ditt grafiska användargränssnitt användbart för personer med funktionsnedsättningar”, och att du inte skulle behöva bry dig om du vet att ingen person med funktionsnedsättningar någonsin kommer att använda ditt program. Om du följer dessa riktlinjer kommer det förbättra den allmänna användbarheten för ditt program för alla som använder det - inklusive dig!

#### Allmänt

Vi blir alla frustrerade om vi inte kan hitta en funktion i ett program, eller gör ett misstag som det tar ett par minuter att återställa, om det är möjligt att återställa över huvud taget. Om du har någon typ av funktionsnedsättning är risken att förlusterna i form av ansträngning och tid kommer vara flera gånger värre. Att följa några få grundläggande riktlinjer kan hjälpa till att förhindra dessa sorters situationer för alla användare.

- Tillhandahåll Ångra för varje åtgärd som ändrar användarens data eller programmets inställningar. Tillhandahåll om möjligt mer än en nivå av Ångra och Gör om, och en historiklista för att tillåta förhandsgranskning av vilka åtgärder som kommer att ångras.

- Tillhandahåll kommandon för att återställa standardinställningar. Om en specifik inställning skulle kunna göra programmet helt obrukbart för en person, t.ex. genom att göra typsnitten väldigt små, så vore det användbart att tillhandahålla ett alternativ för att återställa standardinställningarna utanför programmet självt. Detta skulle exempelvis kunna göras med en kommandoradsflagga.

- Hjälp till att förhindra användare från att göra fel sak. Detta är särskilt viktigt för åtgärder som skulle kunna göras av misstag (t.ex musåtgärder) eller som inte lätt kan återställas (t.ex. att skriva över en fil). Överväg att använda bekräftelsedialoger eller att tvinga användaren att gå in i ett särskilt läge för att utföra potentiellt destruktiva åtgärder.

- Minimera användares minnesbelastning. Låt till exempel användaren visa flera dokument samtidigt, och säkerställ att hjälp på nätet eller andra instruktioner kan förbli synliga medan de fortsätter med proceduren som beskrivs. Tillåt dem att kopiera all information som visas och att klistra in den var som helst där data kan matas in.

- Tvinga inte användare att mata in skivor. Beroende på en användares specifika funktionsnedsättning kan de finna det svårt att fysiskt mata in eller byta ut en skiva, eller så kan de ha svårt att identifiera rätt skiva till att börja med. Om ditt program installeras från cd-rom, tillhandahåll ett alternativ för att kopiera alla filer som kommer att krävas till användarens hårddisk.

- Placera inte ofta använda funktioner djupt nere i en menystruktur. Vare sig du använder en mus, tangentbord eller någon annan inmatningsenhet så är det bäst att undvika djupt nästlade menyobjekt. Förutom bördan av att komma ihåg var man kan hitta dem är de alltid svårare och mer tidsödande att komma åt.

- Led inte användare genom onödiga steg. Till exempel är guider användbara för användare som har problem att hantera ett stort antal alternativ på en gång, men andra användare kan behöva minimera mängden tid eller tangenttryckningar de använder. Sådana användare tjänar på att kunna hoppa över onödiga steg eller gå direkt till det som de behöver. Överväg att tillhandahålla en Färdigställ-knapp i guider som hoppar direkt till slutet och antar standardsvar för de mellanliggande stegen. Om processen har många steg, överväg att fråga användarna i början om de vill gå igenom alla steg, eller bara de mest använda stegen.

#### Tangentbordsnavigering

Ett väldesignat tangentbordsanvändargränssnitt spelar en nyckelroll när du designar tillgänglig programvara. Blinda användare kan navigera programvara mer effektivt med tangentbordet eftersom att använda musen beror på visuell återkoppling om muspekarens placering. Rörelsenedsättningar kan också förhindra en användare från att lyckas navigera med musen på grund av de finmotoriska färdigheter som krävs.

Det är därför viktigt att göra alla musåtgärder tillgängliga från tangentbordet, och inkludera tangentbordsåtkomst till alla verktygsfält, menyer, länkar och knappar. Varje funktion som ditt program tillhandahåller bör kunna kommas åt med bara tangentbordet. Göm din mus medan du testar ditt program om du behöver det!

Den mesta funktionaliteten bör vara enkel att göra tillgänglig genom att använda tangentbordsgenvägar, snabbtangenter och verktygslådans inbyggda navigeringsfunktioner. Åtgärder som exempelvis förlitar sig på dra och släpp kan dock kräva mer eftertanke.

- Tillhandahåll effektiv tangentbordsåtkomst till alla programfunktioner. Vissa användare kan kanske inte använda en mus, och många avancerade användare föredrar i vilket fall att använda tangentbordet. Vissa hjälpmedelsteknologiers inmatningsenheter kan även simulera tangentbordshändelser snarare än mushändelser. Då det är svårt eller rent av smärtsamt för vissa användare att skriva så är det viktigt att tillhandahålla ett tangentbordsgränssnitt som minimerar antalet tangenttryckningar som krävs för varje given uppgift.

- Använd en logisk ordning för tangentbordsnavigering. När man navigerar runt i ett fönster med Tabb-tangenten bör tangentbordsfokus flytta mellan komponenterna enligt en förutsägbar ordning. I västerländska lokaler är detta normalt från vänster till höger samt uppifrån och ner.

- Säkerställ en korrekt tabbordning för kontroller vars aktiverade tillstånd är beroende på tillstånd hos kryssrutor, radioknappar eller växlingsknappar. Då en sådan knapp är vald ska alla dess beroende kontroller aktiveras, och alla de beroende kontrollerna i andra knappar i gruppen ska inaktiveras. Då användaren väljer en kryssruta, radioknapp eller växlingsknapp som har beroende kontroller, ge inte automatiskt fokus till den första beroende kontrollen, utan lämna istället fokus på knappen.

- Åsidosätt inte befintliga systemomfattande tillgänglighetsfunktioner. AccessX är till exempel en Xserver-utökning som har stöd sedan X11R6. Funktionen MouseKeys i denna utökning tillåter musrörelser och knapptryckningar att simuleras med det numeriska tangentbordet. Därför bör du inte lägga till funktioner till ditt program som endast kan kommas åt genom att trycka ned tangenter på det numeriska tangentbordet, då användare som förlitar sig på MouseKeys-funktionen inte kommer kunna använda dem.

- Tillhandahåll mer än en metod för att utföra tangentbordsuppgifter där möjligt. Några användare kan finna vissa tangenter och tangentkombinationer lättare att använda än andra.

- Tillhandahåll både tangentbords- och musåtkomst till funktioner där möjligt. Vissa användare kan kanske använda antingen musen eller tangentbordet, men inte båda.

- Tilldela inte tangentkombinationer som är svåra att nå för vanligen använda tangentbordsåtgärder. Vissa personer kanske bara kan använda en hand på tangentbordet, så genvägar som enkelt kan användas med en hand är att föredra för vanliga åtgärder. I vilket fall kan att ofta behöva utföra långa eller svåra sträckningar öka muskelbelastningen för alla användare, vilket ökar risken för smärta eller skada.

- Kräv inte upprepad användning av samtidiga knapptryckningar. Vissa användare kan bara trycka och hålla ner en tangent åt gången. Hjälpmedelsteknologier som AccessX kan tillåta användare att trycka ned knapparna en efter en snarare än samtidigt, men detta innebär förstås att åtgärden kommer ta längre tid för dem.

- Säkerställ att all text som kan markeras med musen också kan markeras med tangentbordet. Detta är bekvämt för alla användare, men särskilt för dem som har problem med precisionskontroll av musen.

- Säkerställ att objekt som kan storleksändras eller flyttas med ”dra och släpp” även kan storleksändras eller flyttas med tangentbordet. Exempelvis ikoner och fönster på skrivbordet. Där precisionsanpassning av storlek och placering är potentiellt viktigt, exempelvis former i ett diagram, kan du också överväga en dialogruta som du kan skriva in koordinater i, eller ett sätt att fästa fast objekt på ett användardefinierbart rutnät.

- Använd inte allmänna navigeringsfunktioner för att utlösa åtgärder. Använd till exempel inte grundläggande tangentbordsnavigering med Tabb i en dialogruta för att aktivera några åtgärder som är associerade med en kontroll.

- Visa tangentbordsstartade menyer, fönster och inforutor nära objektet de är relaterade till. I GNOME 2.0 kan användare anropa poppuppmenyer med Skift F10, och inforutor med Skift F1. Skym eller dölj dock inte fullständigt objektet som menyn eller inforutan hänvisar till.

#### Musinteraktion

Kom ihåg att inte alla kan använda en mus med samma skicklighet, och att vissa användare kan ha svårighet att se eller följa muspekaren.

- Var inte beroende av inmatning från musknapp 2 eller 3. Så väl som att vara fysiskt svårare att klicka på så stöder vissa pekdon och många hjälpmedelsteknologier bara knapp 1. Vissa hjälpmedelsteknologier kanske inte emulerar musen över huvud taget, utan genererar tangentbordshändelser istället.

- Tillåt alla musåtgärder att avbrytas. Att trycka ned Esc-tangenten bör avbryta alla pågående musåtgärder, så som att dra och släppa en fil i en filhanterare, eller att rita en form i ett ritprogram.

- Tillhandahåll visuell återkoppling hela tiden under en dra och släpp-operation. Då musen passerar giltiga mål, färgmarkera dem och ändra muspekaren. Använd ”Inget släpp”-muspekaren då ogiltiga släppmål passeras. Se Musinteraktionsexempel.

- Teleportera inte muspekaren, och begränsa inte musrörelse till en del av skärmen. Detta kan störa hjälpmedelsteknologier, och är vanligen förvirrande även för användare som inte förlitar sig på hjälpmedelsteknologier.

- Gör inte mål för musen för små. Allmänt bör musens mål vara minst storleken på det ”heta området” kring den storleksändringsbara fönsterkanten i den aktuella fönsterhanteraren/temat - tag i beaktande att en användare med nedsatt fingerfärdighet eller syn kan använda en fönsterhanterare med större områden än standardvärdet.

##### Musinteraktionsexempel

###### Exempel på ”inget släpp”-pekare från CDE/Motif

Exempel på en ”ogiltigt släppmål”-pekarform

#### Grafiska element

Tillhandahåll alternativ för att anpassa presentationen av alla viktiga grafiska element i ditt program. Detta kommer göra det lättare för personer med visuella eller kognitiva nedsättningar att använda det.

- Hårdkoda inte grafiska attribut så som tjocklek för linjer, kanter och skuggor. Dessa element bör idealiskt läsas från GTK- eller fönsterhanterartemat. Om detta inte är möjligt, tillhandahåll alternativ inuti ditt program för att ändra dem.

- Tillhandahåll beskrivande namn för alla gränssnittskomponenter. GAIL-biblioteket tillhandahåller standardtillgänglighetsbeskrivningar för många GTK-komponenter, men du kommer fortfarande att behöva lägga till egna i vissa fall, så som för komponenter som använder grafik istället för text (exempelvis en färgruta i en färgpalett, eller en ikon utan en etikett). Överväg att åsidosätta standardvärdena med mer hjälpsamma eller programspecifika beskrivningar då det är möjligt.

- Tillåt grafiska element med flera färger (t.ex verktygsfältsikoner) att visas bara monokromt om möjligt. Dessa monokroma bilder bör visas i systemets förgrunds- och bakgrundsfärger, vilka användaren har valt själv (genom deras val av GTK-tema) för maximal läsbarhet.

- Gör interaktiva grafiska användargränssnittselement lätta att identifiera. Tvinga exempelvis inte användaren att hovra över ett objekt för att avgöra om det är klickbart eller inte. Lämna tillräckligt utrymme mellan objekt och avgränsa tydligt objektkanter. Visa inte grafiska användargränssnittselement som är vackra men inte tillför något, om du inte också tillhandahåller ett alternativ för att slå av dem.

- Tillhandahåll ett alternativ för att dölja grafik som inte meddelar väsentlig information. Grafiska bilder kan vara distraherande för användare med vissa kognitiva nedsättningar. Ikonerna i GNOME-fotmenyn kan till exempel slås av medan menyerna förblir fullt funktionella.

#### Typsnitt och text

Även för en användare med full syn så tillhandahåller textutmatning majoriteten av information och återkoppling i de flesta program. Det är därför avgörande att välja och placera text noggrant på skärmen, och lämna valet av typsnitt och storlek till användaren för att säkerställa att personer med synnedsättningar också kan använda ditt program effektivt.

- Hårdkoda inte stilar och storlekar för typsnitt. Användaren bör kunna justera alla storlekar och typsnitt. Om du av någon anledning inte kan erbjuda denna funktionalitet så bör du ändå aldrig hårdkoda typsnittsstorlekar mindre är 10 punkter.

- Tillhandahåll alternativ för att slå av grafiska bakgrunder och ”vattenstämplar” bakom text. Sådana bilder stör kontrasten mellan texten och dess bakgrund, vilket kan orsaka svårighet för användare med synnedsättningar.

- Ge objekt etiketter med namn som är förståeliga då de ses utan sammanhang. Användare som förlitar sig på skärmläsare eller liknande hjälpmedelsteknologier kommer inte nödvändigtvis att omedelbart förstå relationen mellan en kontroll och de som finns omkring den.

- Använd inte samma etikett mer än en gång i samma fönster. Om du använder samma etikett i olika fönster är det till hjälp om det betyder samma sak i båda fönstren. Använd inte heller etiketter som stavas olika men låter likadant, t.ex. ”Read” och ”Red” då detta kan vara förvirrande för användare som förlitar sig på skärmläsare.

- Placera etiketter konsekvent i hela ditt program. Detta betyder vanligen direkt under stora ikoner, direkt till höger om små ikoner, och direkt ovanför eller till vänster om andra kontroller. Se Exempel på typsnitt och text.

- Då du använder statisk text för att etikettera en kontroll, avsluta etiketten med ett kolon. Till exempel Användarnamn: för att etikettera ett textfält som användaren ska skriva sitt användarnamn i. Detta hjälper till att identifiera det som en kontrolls etikett snarare än ett oberoende textobjekt.

- Då du använder statisk text för att etikettera en kontroll, säkerställ att etiketten är direkt före kontrollen i tabbordningen. Detta kommer säkerställa att snabbtangenten (det understrukna tecknet) du tilldelar till etiketten kommer att flytta fokus till eller aktivera rätt kontroll när den trycks ned.

- Tillhandahåll alternativ till WYSIWYG (What you see is what you get, d.v.s. att det slutgiltiga resultatet hela tiden ses under redigering). Vissa användare kan exempelvis behöva skriva ut text med ett litet typsnitt men redigera den med ett större skärmtypsnitt. Möjliga alternativ inkluderar att visa all text med samma typsnitt och storlek (båda valda av användaren); ett ”radbryt-till-fönster”-alternativ som låter dig läsa all text i ett fönster utan att rulla horisontellt; en enkolumnsvy som visar fönstrets innehåll i en enda kolumn även om det kommer skrivas ut i flera kolumner; och en textvy, där grafik visas som platshållare eller textbeskrivningar. Om programmet har paneler med underordnade kontroller, överväg att tillåta panelerna att storleksändras tillsammans med det överordnade fönstret.

##### Exempel på typsnitt och text

###### Korrekt etikettplacering för diverse grafiska gränssnittselement

List control with label above Listkontroll med etikett ovanför | Large file manager icon with label underneath Stor filhanterarikon med etikett under | Small toolbar icon with label to its right Liten verktygsfältsikon med etikett till höger | Spinbox control with label to its left Stegningsruta med etikett till vänster

#### Färg och kontrast

Dåligt färgval på skärmen kan orsaka problem för användare med färgblindhet (för vilka nyans är viktigt) eller med nedsatt syn (för vilka ljusstyrka/kontrast är viktigt). Allmänt bör du tillåta användaren att anpassa färgerna i alla delar av ditt program som meddelar viktig information.

Användare med synnedsättningar behöver ofta en hög kontrastnivå mellan bakgrunden och textfärger. Ofta används en svart bakgrund och vit text för att förhindra bakgrunden från att ”blöda”. Dessa inställningar är avgörande för användare med synnedsättningar.

- Hårdkoda inte programfärger. Vissa användare behöver använda vissa färgkombinationer och kontrastnivåer för att bekvämt kunna läsa skärmen. Därför bör alla huvudfärger du använder i ditt GNOME-program tas från GTK-temat, så att användaren kan ställa in temat för alla sina program till något läsbart bara genom att ändra temat. Om du av någon anledning behöver använda färger som inte är tillgängliga i temat, säkerställ att de går att anpassa i programmet självt.

- Använd inte färg som det enda sättet för att skilja informationsobjekt åt. All sådan information bör tillhandahållas med minst en annan metod, så som form, position eller textbeskrivning. Se Exempel på färg och kontrast.

- Stöd alla GNOME-temana för hög kontrast. Säkerställ att då ett av dessa teman väljs så dyker all text i ditt program upp med hög kontrast i de förgrunds- och bakgrundsfärger som angivits av temat.

- Säkerställ att ditt program inte är beroende av ett specifikt högkontrasttema. Testa det med olika högkontrastteman för att säkerställa att ditt program respekterar inställningarna.

##### Exempel på färg och kontrast

###### Exempel som illustrerar onödig användning av färg

Exempel som visar ändringar i aktiekurs bara med färg | Denna visning skulle kunna orsaka problem för en användare med röd-grön färgblindhet (färgblindhet drabbar så många som 1 av 7 män i vissa delar av världen). Avsaknaden av kontrast mellan den röda texten och den svarta bakgrunden skulle också göra det svårt att läsa för en användare med nedsatt syn, till och med om en skärmförstorare används.

Exempel som visar ändringar i aktiekurs både med färg och pilar

Denna visning färstärker färgkodningen med pilar för att visa hur aktiepriset ändras, och använder mörkare nyanser av grön och röd på en ljusare bakgrund för att tillhandahålla högre kontrast. Detta behöver inte vara standardfärgschemat om tester har visat att det var för distraherande för de flesta användarna, men det borde vara möjligt att anpassa det på detta sätt antingen genom teman eller programmets dialogruta för Inställningar.

#### Förstoring

Många användare, även de som inte har synsvårigheter, drar nytta av förstoring av text och grafik. Utan förstoring kan dock en användare med synsvårigheter kanske inte få tillgång till och använda programmet över huvud taget.

- Tillhandahåll förmågan för användaren att förstora arbetsytan.

- Tillhandahåll alternativ i programmet för att skala arbetsytan. Användare behöver ett alternativ för att förstora arbetsytan 150% till 400% eller mer. Testa programmet för att bekräfta att objektet du visar inte påverkas av att ändra förstoringsinställningarna.

#### Ljud

Personer som hör dåligt, samt de som arbetar med sin dators ljud avslaget, kommer att ha en nackdel om ditt program förlitar sig på ljud för att meddela information. Se i allmänhet till att användaren kan få hörbar information meddelad på andra sätt.

- Anta inte att en användare kommer att höra ljudinformation. Detta gäller lika mycket användare med trasiga ljudkort som det gör de som har hörselnedsättningar!

- Använd inte ljud som det enda sättet för att meddela information. Ge användaren alternativet att få all ljudinformation tillhandahållen även på ett visuellt sätt. Detta inkluderar att tillhandahålla undertexter eller transkription för alla viktiga talade ljudklipp.

- Tillåt användare att konfigurera frekvens och volym på alla varningspip och andra ljud. Detta inkluderar att kunna slå av ljud fullständigt.

#### Animering

Använt sparsamt kan animering vara användbart för att dra uppmärksamheten till viktig information i ditt program - och det kan även se coolt ut. Det kan dock vara problematiskt för vissa användare, så till att de kan slå av det.

- Använd inte blixtrande eller blinkande element som har en frekvens högre än 2 Hz och lägre än 55 Hz. Detta inkluderar text så väl som grafiska objekt. Allt i detta frekvensintervall kan orsaka specifika problem för användare som är mottagliga för visuellt inducerade kramper. Observera dock att det inte finns någon ”säker” frekvens. Om blixtrande är nödvändigt bör du använda systemets blinkfrekvens för markören (vilken själv bör vara anpassningsbar), eller tillåta användare att konfigurera frekvensen själva.

- Blixtra eller blinka inte stora områden på skärmen. Små områden har mycket mindre risk att utlösa kramper hos de som är mottagliga för sådana.

- Gör all animering valfri. Den animerade informationen bör vara tillgänglig i åtminstone ett icke animerat format, då användaren så önskar.

#### Tangentbordsfokus

Att visa platsen för tangentbordsfokus tydligt vid varje tidpunkt är viktigt, både för användare med synnedsättningar såväl som för avancerade användare som föredrar att använda tangentbordet snarare än musen. Det ska aldrig finnas någon förvirring över vilken kontroll på skrivbordet som har fokus vid ett givet tillfälle. Du borde kunna lämna din dator med fokus på vilken komponent som helst i ditt program, sedan gå bort och ringa din partner eller rasta hunden tills du har glömt vilken komponent du lämnade den på. När du återvänder bör du direkt kunna säga vilken komponent det var.

En indikator för visuellt fokus är en ljudrepresentation av markörpositionen relativt till de andra objekten på skrivbordet. Denna låter användaren gå runt bland objekt interaktivt medan fokus ändras. Det visuella fokuset måste exponeras programmatiskt till hjälpmedelsteknologier. Observera att i de flesta fall hanteras detta automatiskt av ATK, utan att du behöver göra något extra arbete. Du kommer dock behöva vara medveten om detta krav när du exempelvis skriver dina egna anpassade komponenter.

- Börja fokus vid den mest använda kontrollen. Om ingen kontroll i ett fönster kan bedömas vara ”mest” användbar, börja med fokus på den första kontrollen i fönstret då det fönstret öppnas. Fokus bör inte startas på knapparna OK eller Avbryt för en dialogruta även om det är de mest använda kontrollerna, då de alltid kan aktiveras omedelbart genom att trycka ned Retur eller Escape.

- Visa aktuellt inmatningsfokus tydligt hela tiden. Kom ihåg att det i kontroller som inkluderar ett rullningselement inte alltid är tillräckligt att färgmarkera bara det markerade elementet i rullningsområdet, då det kanske inte är synligt. Se Tangentbordsfokusexempel.

- Visa inmatningsfokus bara i det aktiva fönstret. Dölj alla primära indikatorer för visuellt fokus i fönster som inte har fokus och aktivering. Om ett enda fönster har separata paneler bör bara en panel ha fokusindikatorn, och fokusindikatorer bör vara dolda i alla andra paneler. Om det är viktigt att fortsätta visa vilket objekt som exempelvis är markerat i en ofokuserad lista, använd en sekundär fokusindikator. Se Tangentbordsfokusexempel.

- Tillhandahåll lämplig återkoppling då användaren försöker navigera förbi slutet av en grupp med relaterade objekt. Vid navigering i en lista är det ofta att föredra att avbryta med ljudåterkoppling över att flytta fokus tillbaka till det första objektet i listan. I annat fall kanske användare som är blinda eller har nedsatt syn inte inser att de har återvänt till början. I fallet med en textsökning i ett dokument kan en dialogruta poppa upp för att indikera att dokumentets slut har nåtts, och fråga om du vill återuppta sökningen i början på dokumentet.

- Spela systemets standardvarningssignal (ljud eller visuell) då användaren trycker ned en olämplig knapp, eller då en navigeringstangent inte kan flytta fokus. Exempelvis då fokus är på det första tecknet i ett textfält och användaren trycker ned vänsterpil, eller då användaren försöker utföra flera markeringar i en enmarkeringsdialog. Observera att användare med hörselnedsättningar bör kunna konfigurera en systemomfattande visuell motsvarighet till standardvarningsljudet.)

##### Tangentbordsfokusexempel

###### Exempel som illustrerar behovet av att tydligt visa fokus

Det fokuserade objektet i detta fönster kan inte ses för att det har rullats utanför skärmen | En av kontrollerna i detta fönster har fokus, men det är omöjligt att avgöra vilken…
Det fokuserade objektet i listan har blivit synligt genom att rulla genom listan | …till du rullar i listan vilket avslöjar det av dess objekt som för närvarande är markerat.
Listkontrollen i detta exempel har en enfärgad kant som indikerar fokus, oavsett om dess markerade post är synlig för tillfället eller inte | Om listkontrollen själv ges en ”fokuserad” kant, så är det lätt att avgöra att den har fokus även då det för närvarande markerade objektet inte är synligt.

###### Exempel som illustrerar användning av sekundärt fokus

Fönster med delad panel i vilket båda panelerna verkar ha fokus | I detta exempel är det omöjligt att avgöra vilken av de två panelerna som har tangentbordsfokus bara genom att titta på dem.
Fönster med delad panel i vilket sekundär färgmarkering används för att visa vilken panel som har fokus | Genom att använda en sekundär färg för färgmarkering i den inaktiva panelen är det omedelbart uppenbart att trädkontrollen har fokus här…
Fönster med delad panel i vilket sekundär färgmarkering används för att visa vilken panel som har fokus | …och att listkontrollen har fokus här.

#### Timing

Gränssnitt i vilka saker dyker upp, försvinner eller inträffar enligt någon hårdkodad tidsgräns är ofta ett hinder för tillgänglighet. Vissa användare kan läsa, skriva eller reagera väldigt långsamt i jämförelse med andra. Om information som de behöver har försvunnit innan de är klara med den, eller döljs av att annan information poppar upp vilket de inte uttryckligen efterfrågat, så kommer ditt program att bli väldigt frustrerande eller till och med omöjligt att använda.

- Hårdkoda inte tidsgränser eller andra tidsbaserade funktioner. Exempel inkluderar automatisk rullning då ett objekt dras mot kanten av ett fönster, att hålla ned en knapp i en rullningslist, eller att automatiskt expandera en trädnod då ett objekt dras över den och hålls där ett kort tag. Dessa bör antingen vara anpassningsbara i programmet, GNOME-kontrollpanelen, eller i värsta fall, manuellt redigerbara från kommandoraden genom en konfigurationsfil eller GConf-post.

- Visa eller dölj inte information tillfälligt beroende på muspekarens rörelse. (Undantag: funktioner som systemet tillhandahåller, så som inforutor, vilka användaren kan konfigurera på en systemomfattande nivå). om du måste tillhandahålla sådana funktioner, gör dem valfria så att användare kan slå av dem då ett skärmgranskningsverktyg finns installerat.

#### Dokumentation

Personer med funktionsnedsättningar kan inte använda programmet effektivt om de inte har tillgång till de handböcker och hjälpfiler som krävs. Av särskild vikt är tangentbordsnavigering då detta är det enda sätt på vilket många användare kan navigera programmet.

- Tillhandahåll all dokumentation i ett tillgängligt format. ASCII-text och HTML är båda utmärkta format för hjälpmedelsteknologier.

- Tillhandahåll alternativa textbeskrivningar för all grafik i dokumentationen.

- Dokumentera alla ditt programs tillgänglighetsfunktioner. Tangentbordsnavigering och genvägar är särskilt viktiga att dokumentera. Inkludera ett tillgänglighetsavsnitt i din dokumentation, där information om alla tillgänglighetsfunktionerna kan hittas.

## Test

Det finns flera granskningspunkter att ta i beaktande innan ett program kan förklaras vara tillgängligt. Under utvecklandet kan du vilja överväga automatiserade testtekniker. Exempelvis kan LDTP komplementera din plan för automatiserade tester.

Detta avsnitt beskriver ett antal test du kan utföra manuellt på ett program för att testa dess tillgänglighet. Att få godkänt på alla tester betyder inte nödvändigtvis att programmet är fullständigt tillgängligt, men om programmet misslyckas med något av dessa tester så kan mer arbete behövas för att förbättra den aspekten av dess tillgänglighet.

### Tangentbordsnavigering

Följande tangentbordsoperationer bör testas. Använd inte musen i någon del av detta test.

- Flytta fokus genom alla menyrader i programmet med enbart tangentbordskommandon.

- Bekräfta att:

  - Sammanhangskänsliga menyer visas korrekt.

  - Alla funktioner som listas i verktygsfältet kan utföras med tangentbordet.

  - Du kan styra varje kontroll i programmets klientområde och dialogrutor.

  - Text och objekt i klientområdet kan markeras.

  - Alla tangentbordsgenvägar eller snabbtangenter fungerar som det är tänkt.

### Grafiska element

Testa programmet med en skärmläsare och bekräfta att:

- Etiketter och text läses upp korrekt, inklusive menyer och verktygsfält.

- Objektsinformation läses upp korrekt.

### Indikator för visuellt fokus

- Bekräfta att då du rör dig mellan objekt så är indikatorn för visuellt fokus lätt att identifiera.

- Tangentbordsnavigering genom programvaran och menyer bör vara klar och tydlig om när fokus förflyttas.

- Bekräfta att skärmläsaren spårar indikatorn för visuellt fokus medan du navigerar med ett tangentbord.

- Kör ett skärmförstorarprogram (om tillgängligt) och bekräfta att förstoraren kan spåra indikatorn för visuellt fokus medan du navigerar med tangentbord och mus.

### Typsnitt och text

- Ändra typsnittet i programmet och bekräfta att inställningarna bevaras.

- Testa programmet genom att ändra färger och bekräfta att alla inställningar bevaras.

- Om förstoring finns tillgänglig, testa typsnitt, färg och storlek med förstoringsalternativet.

### Färg och kontrast

- Skriv ut skärmbilder till en svartvit skrivare och bekräfta att all information är synlig.

- Testa program med bara svartvita högkontrastinställningar och bekräfta att all information förmedlas korrekt.

- Testa att programmet tillhandahåller minst tre kombinationer av färgscheman samt att högkontrastscheman finns tillgängliga (t.ex. vitt på svart eller gult på blått).

- Slå på inställningar för hög kontrast i GNOME-kontrollpanelen och bekräfta att programmet respekterar dessa inställningar.

- Testa olika teman för att säkerställa att programvaran fungerar med alla inställningar som finns.

### Ljud

Det bör finnas ett alternativ i programmet för att visa ljudlarm visuellt.

Testa att ljudet fungerar som det ska genom att aktivera ljud i GNOME-kontrollpanelen och sedan utföra följande åtgärder:

- Utför en åtgärd som skulle generera ett ljudlarm och bekräfta att programmet fungerar som det är tänkt.

- Bekräfta att programmet fungerar korrekt då volymen ökas eller sänks.

- Bekräfta att varningsmeddelanden och larm kan höras i en bullrig arbetsmiljö.

### Animering

Bekräfta att det finns ett alternativ för att stoppa animering och att det fungerar som det är tänkt.

Slå av animeringen. Bekräfta att all information fortfarande förmedlas korrekt.

### Tangentbordsfokus

- Testa alla meddelanden för att bekräfta att användaren får en avisering innan ett meddelandes tidsgräns går ut och ges möjlighet att indikera att mer tid behövs.

- Säkerställ att ett alternativ har inkluderats för att justera svarstiden och bekräfta att det fungerar som det är tänkt.

### Dokumentation

Testa ASCII-textdokumentation med en skärmläsare för att bekräfta att den är tydlig och exakt och kan läsas av hjälpmedelsteknologier.

Testa HTML-program med en webbläsare och skärmläsare för att bekräfta att dokumentationen är tillgänglig för hjälpmedelsteknologier.

Observera: Det finns riktlinjer för webbtillgänglighet på http://www.w3.org/TR/WAI-WEBCONTENT/.

Bekräfta att följande information finns med i dokumentationen:

- Ange om programmet inte stöder standardtangentbordsåtkomsten som används av operativsystemet.

- Identifiera om det finns unika tangentbordskommandon.

- Identifiera alla unika tillgänglighetsfunktioner.

- Om en åtgärd är dokumenterad för musen, säkerställ då att det finns ett alternativ som använder tangentbordet.

### Kontrollista för användargränssnitt

Detta avsnitt sammanfattar riktlinjerna som ges i Riktlinjer för användargränssnitt som stöder tillgänglighet. Se det avsnittet i guiden för mer detaljerad information om de objekt i kontrollistan som anges här.

Då du testar ett programs tillgänglighet bör du gå igenom var och en av punkterna i listan. Notera om programmet på varje test har Godkänt eller Icke Godkänt, eller om testet ej är tillämpligt för det programmet.

#### Kontrollista för generella principer

GP | Generella principer | G/IG/-
--- | --- | ---
GP.1 | Varje åtgärd som ändrar användarens data eller programmets inställningar kan göras ogjord.
GP.2 | Alla programinställningar kan återställas till sina standardvärden utan att användaren behöver komma ihåg vad de standardvärdena var.
GP.3 | Efter installationen kan programmet användas utan att användaren behöver mata in en diskett eller cd vid något tillfälle.
GP.4 | De vanligast använda funktionerna hittas på menystrukturens toppnivå.

#### Kontrollista för tangentbordsnavigering

TN | Tangentbordsnavigering | G/IG/-
--- | --- | ---
TN.1 | Effektiv tangentbordsåtkomst tillhandahålls till alla programfunktioner.
TN.2 | Alla fönster har en logisk ordning för tangentbordsnavigering.
TN.3 | Den korrekta tabbordningen används för kontroller vars aktiverade tillstånd beror på kryssrutor, radioknappar eller växlingsknappar.
TN.4 | Tangentbordsåtkomst till programspecifika funktioner åsidosätter inte systemets befintliga hjälpmedelsfunktioner.
TN.5 | Programmet tillhandahåller mer än ett sätt att utföra tangentbordsuppgifter närhelst det är möjligt.
TN.6 | Det finns alternativa tangentkombinationer närhelst det är möjligt.
TN.7 | Det används inga tangentkombinationer som är svåra att nå för ofta utförda tangentbordsåtgärder.
TN.8 | Programmet använder inte upprepade samtidiga tangenttryckningar.
TN.9 | Programmet tillhandahåller tangentbordsekvivalenter för alla musfunktioner.
TN.10 | Text eller objekt som kan markeras med musen kan också markeras med bara tangentbordet.
TN.11 | Ett objekt som kan storleksändras eller flyttas med musen kan också storleksändras eller flyttas med bara tangentbordet.
TN.12 | Programmet använder inga allmänna navigeringsfunktioner för att utlösa åtgärder.
TN.13 | Alla tangentbordsstartade menyer, fönster och inforutor dyker upp nära objektet som de är relaterade till.

#### Kontrollista för musinteraktion

MI | Musinteraktion | G/IG/-
--- | --- | ---
MI.1 | Inga operationer beror på inmatning från de högra eller mittersta musknapparna.
MI.2 | Alla musoperationer kan avbrytas innan de har slutförts.
MI.3 | Visuell återkoppling tillhandahålls under dra och släpp-operationer
MI.4 | Muspekaren teleporteras aldrig av programkontroll, och får inte sin rörelse begränsad till en del av skärmen av programmet.

#### Kontrollista för grafiska element

GE | Grafiska element | G/IG/-
--- | --- | ---
GE.1 | Det finns inga hårdkodade grafiska attribut så som tjocklek på rad, kant eller skugga.
GE.2 | Alla flerfärgade grafiska element kan visas monokromt när så är möjligt.
GE.3 | Alla interaktiva grafiska användargränssnittselement är lätta att åtskilja från statiska grafiska användargränssnittselement.
GE.4 | Ett alternativ för att dölja mindre viktig grafik tillhandahålls.

#### Kontrollista för typsnitt och text

TT | Typsnitt och text | G/IG/-
--- | --- | ---
TT.1 | Inga storlekar eller stilar för typsnitt är hårdkodade.
TT.2 | Ett alternativ för att slå av grafiska bakgrunder bakom text tillhandahålls.
TT.3 | Alla etiketter har namn som är förståeliga då de läses utan sammanhang.
TT.4 | Inga etikettnamn används mer än en gång i samma fönster.
TT.5 | Etikettplacering är konsekvent i hela programmet.
TT.6 | Alla statiska textetiketter som identifierar andra kontroller avslutas med ett kolon (:).
TT.7 | Statiska textetiketter som identifierar andra kontroller kommer omedelbart före dessa kontroller i tabbordningen.
TT.8 | Ett alternativ till WYSIWYG tillhandahålls. Till exempel förmågan att ange olika typsnitt för skärm och skrivare i en textredigerare.

#### Kontrollista för färg och kontrast

FK | Färg och kontrast | G/IG/-
--- | --- | ---
FK.1 | Programfärger är inte hårdkodade, utan tas antingen från aktuellt skrivbordstema eller en programinställning.
FK.2 | Färg används bara som en förstärkning, och inte som det enda sättet för att uttrycka information eller åtgärder.
FK.3 | Programmet stöder alla teman och inställningar för hög kontrast som finns tillgängliga.
FK.4 | Programmet är inte beroende av något specifikt tema eller inställning för hög kontrast.

#### Kontrollista för förstoring

FÖ | Förstoring | G/IG/-
--- | --- | ---
FÖ.1 | Programmet tillhandahåller förmågan att förstora arbetsytan.
FÖ.2 | Programmet tillhandahåller alternativet att skala arbetsytan.
FÖ.3 | Programmets funktionalitet påverkas inte av att ändra inställningarna för förstoring eller skala.

#### Kontrollista för ljud

LJ | Ljud | G/IG/-
--- | --- | ---
LJ.1 | Ljud används inte som det enda sättet att uttrycka någon slags information.
LJ.2 | Användaren kan konfigurera frekvensen och volymen för alla ljud och varningspip.

#### Kontrollista för animering

AN | Animering | G/IG/-
--- | --- | ---
AN.1 | Det finns inga blixtrande eller blinkande element med en frekvens större än 2Hz eller lägre än 55Hz.
AN.2 | Allt blixtrande eller blinkande är begränsat till små delar av skärmen.
AN.3 | Om animering används finns ett alternativ för att slå av den innan den först visas.

#### Kontrollista för tangentbordsfokus

TF | Tangentbordsfokus | G/IG/-
--- | --- | ---
TF.1 | När ett fönster öppnas startar fokus på den mest använda kontrollen.
TF.2 | Aktuell position för inmatningsfokus visas tydligt vid varje tidpunkt.
TF.3 | Inmatningsfokus visas hela tiden i exakt ett fönster.
TF.4 | Lämplig återkoppling, visuell eller med ljud, tillhandahålls när användaren försöker navigera förbi endera ände av en grupp med relaterade objekt.
TF.5 | Standardvarningssignalen (visuell eller ljud) spelas då användaren trycker ner en olämplig tangent.
TF.6 | Det finns tillräcklig ljudinformation för visuellt fokus så att användaren kan lista ut vad som ska göras härnäst.
TF.7 | Då hjälpmedelsfunktioner så som en skärmläsare eller punktskriftsenhet används indikerar det aktuella programmet positionen och innehållet som indikatorn för visuellt fokus har.

#### Kontrollista för timing

TM | Timing | G/IG/-
--- | --- | ---
TM.1 | Det finns inga hårdkodade tidsgränser eller tidsbaserade funktioner i programmet.
TM.2 | Visande eller döljande av viktig information utlöses inte bara av muspekarens rörelse.

#### Kontrollista för dokumentation

DK | Dokumentation | G/IG/-
--- | --- | ---
DK.1 | All dokumentation finns i ett tillgängligt format, med textbaserade alternativa beskrivningar för alla figurer och diagram.
DK.2 | Dokumentationen innehåller ett avsnitt som täcker alla programmets hjälpmedelsfunktioner.

### GOK (GNOME Onscreen Keyboard)

Informationen på denna sida är delvis förlegad: GNOME 3:s Caribou har ersatt GNOME 2:s gok.

Ditt program bör vara användbart via gok; tangentinmatning bör genereras fullständigt av gok, inte tangentbordet. Målet här skulle vara att arbeta med ditt program och skrivbordet i allmänhet, och säkerställa att all sorts tangentinmatning kan utföras med skärmtangentbordet.

Programmet gok kommer med GNOME-skrivbordet, så det bör redan finnas tillgängligt. För fullständig dokumentation, se den officiella webbplatsen för gok.

Följ dessa steg för att bekräfta att gok fungerar korrekt med ditt program:

1. Logga in i GNOME-skrivbordet

2. Kör gok

3. Starta ditt program

4. Tillhandahåll inmatning till ditt program med ett pekdon (t.ex. mus eller huvudspårare) och gok.

5. Arbeta genom att använda funktionerna för automatisk komplettering och ordprediktion i gok.

6. Bekräfta att gok aktiverar och inaktiverar knapparna Menyer och Verktygsfält beroende på typen av program som körs; till exempel inaktiveras knapparna Menyer och Verktygsfält för programmet ”Typsnittsegenskaper”, men samma knappar är aktiverade för programmet Gedit.

7. Bekräfta att gok-skärmtangentbordet som tillhandahålls av knappen Sammansätt kan användas för att skriva in all text för det valda programmet; kör Gedit, klicka på textområdet, och klicka sedan på knappen Sammansätt i gok. Välj tangenterna som behövs från skärmtangentbordet. Tecknen bör dyka upp i Gedits textområde.

8. Bekräfta att knappen Startare låter användaren starta alla programmen Terminal, Webbläsare och Textredigerare.

9. Bekräfta att knappen Aktivera låter användaren aktivera alla de för närvarande körande programfönstren på användarens skrivbord, inklusive GNOME-paneler och GNOME-skrivbordet.

10. Bekräfta att knappen Menyer listar alla menyer som finns i det aktuella programmet. Bekräfta att ett klick på en menyknapp visar undermenyn och menyobjekten som finns i undermenyn. Bekräfta slutligen att ett klick på ett menyobjekt aktiverar menyobjektet. Klicka till exempel på programmet Hjälpläsare och klicka på knappen Menyer. GOK-fönstret visar nu knapparna Arkiv, Gå och Hjälp (menyerna för Hjälpläsare). Klicka på knappen Arkiv så visar den knapparna Nytt fönster och Stäng fönster (menyobjekt).

11. Säkerställ att knappen Verktygsfält listar alla knappar som finns i programmets verktygsfält. Klicka till exempel på programmet Hjälpläsare och klicka sedan på knappen Verktygsfält. GOK-fönstret visar nu knapparna Bakåt, Framåt och Hem.

12. Bekräfta att knappen Fångst av användargränssnitt visar alla knappobjekt för det markerade programfönstret. Öppna till exempel programmet ”Typsnittsegenskaper” och klicka på knappen Fångst av användargränssnitt i GOK-fönstret. GOK-fönstret bör nu visa namnet på knapparna i programmet - Sans, Sans-serif, Stäng och Hjälp.

### Accerciser

Accerciser och GNOME:s tillgänglighetsarkitektur

Accerciser är en interaktiv tillgänglighetsutforskare för GNOME-skrivbordet skriven i Python. Den använder AT-SPI för att inspektera och styra komponenter, vilket låter dig se om ett program tillhandahåller korrekt information till hjälpmedelsteknologier och automatiska testramverk. Accerciser har ett enkelt ramverk för insticksmoduler som du kan använda för att skapa anpassade vyer av tillgänglighetsinformation. Fullständig dokumentation kan hittas i den officiella handboken för Accerciser. För en demonstration av Accerciser och PyATSPI (Python-omslagen åtkomst och användning av AT-SPI), se denna artikel. För en utmärkt genomgång från författaren, se artikeln med titeln Make Your Application Accessible with Accerciser.

Accerciser har ersatt det äldre verktyget at-poke.