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.

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 görs via klassen GtkAccessible. Den är basklassen för hjälpmedelsimplementationer för underklasser till GtkWidget. Den är ett tunt omslag kring AtkObject, vilket lägger till funktionalitet för att associera en komponent med sitt tillgängliga objekt. De delar av ditt program som använder GTK-standardkomponenter kommer ha en grundläggande nivå av tillgänglighet, utan att du behöver ändra på ditt program alls.
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 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+, den förlegade GTK+ 2.0-guiden 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 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.
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. Dess GtkAccessible-klass är basklassen för hjälpmedelsimplementationer för underklasser till GtkWidget. Den är ett tunt omslag kring AtkObject, vilket lägger till funktionalitet för att associera en komponent med sitt tillgängliga objekt.
För ytterligare, djupgående information om GTK/GTK+, se referenshandboken för GTK+, GTK-avsnittet i ATK-Guiden, den förlegade 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.

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.

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:
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);

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.
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:
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.
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

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:
Kom åt standardregistret:

default_registry = atk_get_default_registry();

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.

Klass-/Instansinitierare
Du kommer behöva konfigurera en klassinitierare för ditt GObject om din AtkObject-implementation antingen:
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.
Kräver en parent->init-, parent->notify_gtk- eller parent->finalize-funktion.
parent->init
En parent->init()-funktion kan behövas om ATK-implementationen behöver göra något av följande:
Cacha alla data som erhålls från en bakomliggande GTK-komponent.
Lyssna på alla signaler från bakomliggande GTK-komponent.
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); 
   } 
}

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.

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. GTK 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.