# Guia de accessibilidade para desenvolvedores GNOME

## O que é acessibilidade?

Acessibilidade significa ajudar pessoas com deficiências a participar em atividades substanciais da vida. Isso inclui trabalho, e o uso de serviços, produtos e informações. GNOME inclui bibliotecas e uma infraestrutura de apoio que permitem que pessoas com deficiências utilizem todas as funcionalidades do ambiente de usuário GNOME.

Em conjunto com tecnologias assistivas se necessário - interfaces de vozes, leitores de tela, dispositivos de entrada alternativos, e por aí vai - pessoas com deficiências permanentes ou temporárias podem, portanto, usar o ambiente e aplicativos do GNOME. Tecnologias assistivas também são úteis para pessoas usando computadores fora de casa ou escritório. Por exemplo, se você estiver preso no tráfego, você pode usar entrada e saída de voz para verificar seus e-mails.

Tecnologias assistivas recebem informações de aplicativos via a API do Accessibility Toolkit (ATK), ou kit de ferramenta de acessibilidade, a qual pode ser encontrada no módulo atk nos repositórios do GNOME. Por o suporte à API de acessibilidade ser compilado nos widgets do GNOME, seus programas GNOME deve funcionar razoavelmente bem com tecnologias assistivas com nenhum esforço extra de sua parte. Por exemplo, tecnologias assistivas podem ler automaticamente os rótulos dos widgets que você normalmente definiria em seu programa (ex.: com chamadas de função do GTK, tais como `gtk_label_set_text()` ou `gtk_button_new_with_label()`). Elas também podem descobrir se há algum texto de dica de ferramenta associada com um widget e usá-la para descrever o widget para o usuário.

Com um pouco de esforço extra, porém, você pode fazer seu programa funcionar ainda mais suave com tecnologias assistivas. Além de ajudar usuários individuais, isso também tornará seu produto mais atrativo para os mercados governamental e educacional, muitos dos quais agora exigem em lei que seus aplicativos seja acessíveis.

### Tipos de deficiências

Só nos EUA, estima-se que haja 30.000.000 pessoas cuja habilidade de usar computadores possa ser comprometida por um design inacessível. Globalmente, cerca de 8% de pessoas que usam a “world wide web” têm algum tipo de deficiência. Deficiências recaem em um desses dessas categorias:

- Deficiências visuais - essas podem variar desde baixa visão (incluindo visão embaçada ou nebulosa, hipermetropia ou miopia extremas, daltonismo e visão em túnel, dentre outras) até cegueira completa. Uma escolha ruim de tamanho e color do texto, e tarefas que envolvam boa coordenação olho/mão (tal como mover o mouse) podem causar problemas para esses usuários.

- Deficiências motoras - usuários com controle ruim dos músculos ou fraquezas musculares podem ter dificuldade para usar um teclado ou um mouse comuns. Por exemplo, eles podem não ser capazes de segurar duas teclas simultaneamente, ou eles podem ser mais propensos a pressionar teclas acidentalmente.

- Deficiências auditivas - essas podem variar entre ser capaz de ouvir alguns sons, mas não distinguir palavras faladas, até surdez profunda. Aplicativos que transportam informações importantes apenas por som causarão problemas para esses usuários.

- Deficiência cognitiva e de linguagem - essas podem variar entre dislexia até dificuldades em se lembrar de coisas, resolver problemas ou compreensão e usar linguagens faladas ou escritas. Telas complexas ou inconsistentes, ou escolha ruim de palavras, podem dificultar o uso de computadores para esses usuários.

- Transtornos convulsivos - alguns padrões de luz e som podem causar convulsões epilépticas em alguns usuários suscetíveis.

### Como a acessibilidade funciona no GNOME

O Accessibility Toolkit (ATK) descreve um conjunto de interfaces que precisam ser implementadas por componentes de GUI para torná-las acessíveis. As interfaces independem de kit de ferramentas - implementações poderiam ser escritas para qualquer conjunto de widget, tais como GTK, Motif ou Qt.

A implementação para os widgets GTK está em um módulo chamado GAIL (GNOME Accessibility Implementation Library, ou biblioteca de implementação de acessibilidade do GNOME), o que é carregável dinamicamente em tempo de execução por um aplicativo GTK. Uma vez carregado, aquelas partes de seu aplicativo que usam widgets padrões do GTK terão um nível básico de acessibilidade, sem que você tenha que modificar seu aplicativo. Se GAIL não for carregável, widgets GTK terão uma implementação de acessibilidade padrão que essencialmente retorna nenhuma informação, apesar dele, nominalmente, estar em conformidade com a API do ATK. Aplicativos que usam controles do Bonobo, especialmente aqueles fora de processo, também carregam código com suporte a acessibilidade do módulo libgail-gnome. Se aplicativos no ambiente do GNOME carregam automaticamente essas bibliotecas de suporte a acessibilidade dependem do valor de uma chave gconf, “/desktop/gnome/interface/accessibility”; um valor booleano de “verdadeiro” habilita suporte a tecnologias assistivas, e aplicativos que chamam gnome_program_init carregarão automaticamente as bibliotecas de acessibilidade apropriadas em tempo de execução. “Aplicativos GTK+ puros”, como aqueles que usam gtk+ sem se vincular a libgnome, dependem do valor da variável de ambiente GTK_MODULES, que deve ser definida para “gail:atk-bridge” para habilitar suporte a tecnologia assistiva.

A maioria das tecnologias assistivas funcionando em outros ambientes tem, historicamente, achado necessário manter um modelo off-screen (ou fora da tela) complexo dos aplicativos, baseado em monitoramento de eventos do SO, uso de recursos de SO e aplicativo sem suporte e API, e outras técnicas altamente não-portáveis. Isso criou suporte a recursos de tecnologia assistiva de alguma forma “frágeis” e altamente específicos para cada SO e aplicativo, até mesmo específico por versão de aplicativo. Em contraste, no ambiente GNOME, toda informação exigida pelas ATs (tecnologias assistivas) é fornecida pelos aplicativos em execução, via GNOME Accessibility Framework, para o Service Provider Interface (SPI) independente do kit de ferramentas. O SPI fornece uma forma para ATs baseadas em UNIX, tais como leitores de tela e lupas de aumento de tela e, em muitos casos, pode eliminar a necessidade por um modelo off-screen. Suporte a acessibilidade para aplicativos é “embarcado” em kits de ferramenta de aplicativos via APIs de kit de ferramentas adequados (por exemplo, ATK para a maioria dos aplicativos nativos em C e a Java Accessibility API para aplicativos em Java), e exportados para uma interface comum “AT-SPI” via a “ponte” relevante (veja o diagrama abaixo).

#### Arquitetura de acessibilidade do GNOME

Diagrama da arquitetura de acessibilidade do GNOME

O suporte de acessibilidade embutida do GNOME significa que os aplicativos criados usando os widgets pré-definidos do GNOME recebem suporte para tecnologias assistivas “gratuitas”, contanto que os componentes não sejam usados de formas não-usuais que possam entrar em conflito com o apoio embutido.

Um widget gtk+/GNOME é acessível se seu uso segue as diretrizes gerais de acessibilidade em outro lugar neste documento, e ele implementa as interfaces ATK apropriadas para seu papel na interface de usuário. Implementações ATK são fornecidas para os widgets de kit de ferramentas pré-definidos do GNOME (ex.: widgets gtk+ e GNOME não obsoletos), e em muitos casos novos widgets que trivialmente derivam de widgets GTK+ e GNOME existentes também herdarão suporte de acessibilidade adequado.

Embora o suporte a acessibilidade embutido do GNOME forneça funcionalidade significante sem qualquer alterações de código específicas para acessibilidade dos aplicativos, eles podem geralmente melhorar as descrições padrões fornecidas para alguns dos widgets, e adaptá-las ao propósito específico daquele widget em seu aplicativo, via chamadas diretas aos métodos ATK no aplicativo. Por exemplo, em muitos casos, aplicativos devem adicionar ou alterar as descrições textuais para esses widgets com a chamada de função ATK apropriada, de forma que uma tecnologia assistiva possa descrever seu propósito ou declará-lo para o usuário. Veja Diretrizes de codificação para suporte a acessibilidade para mais informações.

Se seu aplicativo usa widgets personalizados, você pode ter que fazer algum trabalho para expor as propriedades dos widgets para as tecnologias assistivas. Veja Criando componentes acessíveis personalizados e Exemplos que usam a API de acessibilidade para mais informações.

Para informações adicionais e aprofundadas sobre GTK/GTK+, veja o manual de referência do GTK+, a seção do GTK no guia do ATK, o tutorial do GTK+ 2.0 hospedado pelo GNOME e as perguntas frequentes do GTK+.

### Início rápido para desenvolvedores

Aqui estão alguns pontos comuns de início:

#### Como eu faço para verificar se meu aplicativo é acessível ou não?

Para começar bem, veja Criando um aplicativo acessível para o GNOME - Visão geral. Para uma perspectiva de pré-codificação, veja Diretrizes de interface de usuário para suporte a acessibilidade ou Diretrizes de codificação para suporte a acessibilidade. Para uma lista de verificação de itens para teste pós-design, veja Lista de verificação de interface de usuário.

#### Quais são as armadilhas comuns?

A Lista de verificação de interface de usuário cobre todas as áreas que algumas vezes acabam esquecidos no estágio de design.

#### Como eu faço as coisas comuns do ATK?

Uma listagem abreviada de chamados ATK comuns pode ser localizada aqui.

#### Como eu faço as coisas mais complexas do ATK?

Veja Criando componentes acessíveis personalizados e Exemplos que usam a API de acessibilidade para mais informações.

#### Introdução ao ATK, AT-SPI, GAIL e GTK+

Arquitetura de acessibilidade do GNOME

ATK é o kit de ferramenta que o GNOME usa para habilitar acessibilidade para usuários precisando de suporte extra para fazer a maioria de sua computação. ATK é usado por ferramentas tais como leitores de tela, ampliadores e dispositivos de entrada para permitir uma interação rica com o ambiente por meio de alternativos. Veja o projeto SourceForge do ATK e a biblioteca ATK para mais informações.

AT-SPI é a interface de serviço principal pela qual as tecnologias assistivas consulta ou recebem notificações de aplicativos em execução. A API completa pode ser explorada aqui. Material adicional está disponível na comunidade de desenvolvimento de acessibilidade do KDE.

GAIL (GNOME Accessibility Implementation Library) é uma implementação das interfaces de acessibilidade definidas pelo ATK. GTK é um kit de ferramentas que já é mapeado para ATK pelo módulo GAIL. Licença, download e outras informações podem ser encontradas aqui. O código-fonte do GAIL também serve como um excelente tutorial para usado avançado do ATK. Além disso, você pode estar interessado no manual de referência do GAIL.

GTK+ é uma biblioteca para criação de interfaces gráficas de usuário. Ela funciona em várias plataformas do tipo UNIX, Windows e em dispositivos de framebuffer. GTK+ é lançado sob a Licença Pública Geral de Biblioteca GNU (GNU LGPL), a qual permite licenciamento flexível de aplicativos de cliente. GTK+ possui uma arquitetura orientada a objeto baseada no C que permite uma flexibilidade máxima. Bindings para outras linguagens foram escritas, incluindo C++, Objective-C, Guile/Scheme, Perl, Python, TOM, Ada95, Free Pascal e Eiffel.

Para informações adicionais e aprofundadas sobre GTK/GTK+, veja o manual de referência do GTK+, a seção do GTK no guia do ATK, o tutorial do GTK+ 2.0 hospedado pelo GNOME e as perguntas frequentes do GTK+.

### Criando um aplicativo acessível para o GNOME - Visão geral

Se seu aplicativo usa apenas widgets GTK padrão, você provavelmente terá que fazer um pouco ou nada para criar seu aplicativo (razoavelmente) acessível. Mas cuidado com objetos em sua GUI que não possuem descrição textual associada a eles, tais como botões gráficos ou indicadores de estado que não possuem rótulos ou dicas.

Provavelmente, você também pode melhorar nas descrições padrões fornecidas por alguns widgets, e adaptá-las para aquele propósito específico em seu aplicativo. Você deve adicionar ou alterar as descrições textuais para esses widgets com a chamada de função ATK adequada, de forma que uma tecnologia assistiva possa descrever seu propósito ou estado para o usuário. Veja Diretrizes de codificação para suporte a acessibilidade para mais informações.

Se seu aplicativo usa widgets personalizados, você pode ter que fazer algum trabalho para expor as propriedades dos widgets para as tecnologias assistivas. Veja Criando componentes acessíveis personalizados e Exemplos que usam a API de acessibilidade para mais informações. Informações detalhadas adicionais podem ser localizadas na apresentação de Marc Mulcahy no GUADEC 2002, "Tornando aplicativos do GNOME acessíveis" (em inglês).

### Diretrizes de codificação para suporte a acessibilidade

Aqui estão algumas coisas que você pode fazer em seu código para fazer seu programa funcionar o melhor possível com tecnologias assistivas. (Você pode encontrar uma lista de coisas para considerar ao projetar sua GUI na seção Diretrizes de interface de usuário para suporte a acessibilidade afrente do seu documento):

- Para componentes que não exibem um texto curto (tal como um botão gráfico), especifique um nome para ele com `atk_object_set_name()`. Você pode se interessar em fazer isso para botões com apenas imagens, painéis que fornecem agrupamentos lógicos, áreas de texto e por aí vai.

- Se você não conseguir fornecer uma dica de ferramenta para um componente, use `atk_object_set_description()` para fornecer uma descrição que tecnologias assistivas possam fornecer ao usuário. Por exemplo, para fornecer uma descrição de acessibilidade para um botão de fechar, com rótulo Close:

  #### Fornecendo uma descrição de acessibilidade para um GtkButton

      {
        AtkObject *obj;
        obj = gtk_widget_get_accessible(button);
        atk_object_set_description(obj,_("Closes the window"));
      }

- Use `atk_image_set_description()` para fornecer uma descrição para todas as imagens e ícones em seu programa.

- Se vários componentes formam um grupo lógico, tente colocá-los em um contêiner.

- Quando você tiver um rótulo que descreve outro componente, use `atk_relation_set_add_relation()` de forma que as tecnologias assistivas possam localizar o componente com o qual o rótulo está associado. (Se você associar o rótulo com o componente usando `gtk_label_set_mnemonic_widget()`, a relação `ATK_RELATION_LABEL_FOR` é gerada automaticamente, então o seguinte código não mais seria necessário):

  #### Relacionando um GtkLabel a um 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));
      }

- Se você criou um widget personalizado, certifique-se de que ele ofereça suporte a acessibilidade. Componentes personalizados que são descendentes de outros widgets GTK devem sobrescrever as informações de acessibilidade conformidade necessário. Para mais informações, veja Criando componentes acessíveis personalizados.

- Não quebre o que você consegue de graça! Se sua GUI tiver um contêiner inacessível, quaisquer componentes dentro daquele contêiner podem ficar inacessível.

### A API de acessibilidade

Aqui estão algumas das chamadas básicas de API que você pode precisar usar em seu aplicativo para se certificar de que ele funcione bem com tecnologias assistivas. A API de acessibilidade completa é extensível, para permitir que você escreva seus widgets personalizados de acessibilidade, por exemplo.

### Chamadas de API do ATK comumente usadas

API | Descrição
`AtkObject* gtk_widget_get_accessible (GtkWidget*)` | Retorna o objeto acessível que descreve o widget GTK especificado para uma tecnologia assistiva.
`void atk_object_set_name (AtkObject*, const gchar*)` | Define o nome do objeto acessível. Por exemplo, se o objeto é um botão gráfico que sai do aplicativo quando pressionado, o nome pode ser “Quit”.
`void atk_object_set_description (AtkObject*, const gchar*)` | Define a descrição textual do objeto acessível. Por exemplo, se o objeto é um botão gráfico “Close”, a descrição pode ser “Closes the window”.
`AtkRelation* atk_relation_new (AtkObject**, gint, AtkRelationType)` | Cria uma nova relação entre a chave especificada e a lista especificada de objetos alvos. Uma relação geralmente indica à tecnologia assistiva que um widget está, de alguma forma, relacionado. Por exemplo, que um widget GtkLabel em particular é o texto para um GtkTreeView na mesma janela.
`void atk_image_set_description (AtkImage*, const gchar*)` | Define a descrição textual do objeto imagem acessível. Por exemplo, se o objeto for uma miniatura de uma ambiente virtual em um applet do painel, a descrição pode ser “Image showing window arrangement on desktop 1”.

### Exemplos que usam a API de acessibilidade

Como notado anteriormente, você pode ter um pouco ou nenhum trabalho para tornar o aplicativo acessível se você usar o conjunto de widgets do GTK, ou qualquer outra biblioteca de widgets que implementa as interfaces do ATK. As duas coisas mais comuns que você pode ter que fazer neste caso são:

- fornece descrições de alguns controles e imagem usando `atk_object_set_description()` ou `atk_image_set_description():`

  #### Configurar a descrição de acessibilidade para um botão

      {
         AtkObject *obj;
         obj = gtk_widget_get_accessible(button);
         atk_object_set_description(obj,_("Opens Preferences dialog"));
      }

- Especificar relações entre quaisquer agrupamentos incomuns de widgets usando `atk_relation_new()` and `atk_relation_set_add()`:

  #### Especificar relações acessíveis entre dois controles

      {
        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));
      }

Os exemplos no resto desta seção são, em sua maioria, para dar a você o sabor do escopo do ATK. Eles cobrem as técnicas que você pode nunca precisar usar como um desenvolvedor de aplicativos, apesar de que eles podem ser interessantes se você está escrevendo seus próprios widets personalizados (veja Criando componentes acessíveis personalizados) ou se você deseja escrever um aplicativo de tecnologia assistiva. Seja qual for o propósito, o código-fonte do GAIL serve como um tutorial excelente para uso avançado do ATK. Por favor, note que desde o GTK+ 3.1.10, Gail foi mesclado com GTK+ e deixou de ser um módulo autônomo.

#### Módulos do Gtk

Programas que fazem uso do GAIL (a biblioteca de implementação de acessibilidade para widgets GTK) são escritos como módulos GTK. Módulos GTK são carregados no espaço do programa se a variável de ambiente `GTK_MODULES` especifica o módulo do(s) nome(s) da biblioteca do módulo. Se há múltiplas bibliotecas de módulo, separe-os com caractere de dois pontos. Por exemplo:

`setenv GTK_MODULES "libgail:libtestprops"`

Todos os módulos GTK possuem uma função `gtk_module_init()`.

#### Juntando informações de acessibilidade de um aplicativo

Um programa que deseja fazer uso de chamadas de ATK provavelmente precisaria de uma (ou mais) das seguintes coisas:

1. Criar um monitorador de evento, por exemplo com a função `atk_add_focus_tracker()`:

       atk_add_focus_tracker (_my_focus_tracker);

   sendo `_my_focus_tracker()` uma função com esse protótipo:

       void _my_focus_tracker (AtkObject *aobject);

2. Configurar um listener de eventos globais, com atk_add_global_event_listener():

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

   sendo que `_my_global_listener` tem o protótipo de um Glib `GSignalEmissionHook`. Esse exemplo faria com que `_my_global_listener()` fosse chamado sempre que um sinal enter_notify_even ocorrer em um objeto `GtkWidget`.

3. Acessar o objeto de nível superior do ATK com a chamada de função a seguir.

       AtkObject *root_obj = atk_get_root();

   Isso retorna um `AtkObject` que contém todas as janelas de nível superior no programa atualmente em execução. O usuário poderia, então, navegar pela hierarquia de objeto acessando o filho do objeto raiz, o qual corresponde às janelas de nível superior.

#### Consultando as interfaces de um `AtkObject`

Tendo localizado o `AtkObject` associado com um objeto no aplicativo (ex.: usando `gtk_widget_get_accessible()`), você pode descobrir quais interfaces ele implementa de várias formas:

1. Use as macros `ATK_IS_...` fornecidas, por exemplo:

   - `ATK_IS_ACTION(atkobj)`

   - `ATK_IS_COMPONENT(atkobj)`

   - etc. (há um para cada interface)

   Se a macro retorna `TRUE`, as chamadas de interface podem ser feitas com segurança naquele objeto ATK.

2. Teste a função do `AtkObject` chamando `atk_object_get_role()`. Qualquer papel dado implementa um número específico de APIs ATK.

#### Configurando uma manipulador de signal ATK

Usando o sinal `column_inserted` como um exemplo:

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

Isso fará com que `_my_table_column_inserted_func()` seja chamado sempre que um sinal column_inserted seja emitido no `AtkObject` `my_atk_object`

A conexão com um sinal é um pouco diferente se o sinal oferece suporte a detalhes. O sinal `children_changed` oferece suporte o detalhe `add`. Para conectar com um sinal quando o detalhe `add` também é especificado, essa técnica é usada:

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

Isso fará com que `_my_children_changed_func()` seja chamada sempre que um sinal `children_changed` com o detalhe `add` seja emitido no `AtkObject` `my_atk_obj`.

#### Implementando um objeto ATK

Você precisará implementar seus próprios objetos ATK para quaisquer widgets que não tenham uma implementação acessível no GAIL (ou a biblioteca equivalente para outros conjuntos de widgets). Isso deve ser implementado como um módulo, o que, assim como anteriormente, deve ser incluído na variável de ambiente `GTK_MODULES` de forma que seja carregada em tempo de execução.

##### Registro

Para esse exemplo nós presumiremos que haja um objeto chamado GTK_TYPE_MYTYPE. A implementação ATK será chamada de `MYATKIMP_TYPE_MYTYPE`. Uma fábrica será necessária, a qual será chamada de `MYATKIMP_TYPE_MYTYPE_FACTORY`.

Para registrar uma implementação ATK de um objeto GTK, essas etapas devem ser seguidas na função `gtk_module_init()` do módulo:

1. Acesse o registro padrão:

       default_registry = atk_get_default_registry();

2. Registre o objeto ATK na função `gtk_module_init()` deste módulo fazendo essa chamada de função:

       atk_registry_set_factory_type (default_registry, GTK_TYPE_MYTYPE,
       MYATKIMP_TYPE_MYTYPE_FACTORY);

Isso vai registrar a implementação AtkObject de `GTK_TYPE_MYTYPE` para `MYATKIMP_TYPE_MYTYPE_FACTORY`. Essa fábrica será implementada de forma que saiba como construir objetos do tipo `MYATKIMP_TYPE_MYTYPE`.

##### Fábrica

A fábrica deve ser implementada como uma filha da classe tipo `ATK_TYPE_OBJECT_FACTORY` e deve implementar a função `create_accessible()`. Essa função deve criar um `AtkObject` apropriado. Uma fábrica pode ser usada para criar mais do que um tipo de objeto, caso em que sua função `create_accessible()` precisará ser inteligente o suficiente para construir e retornar o `AtkObject` correto.

##### Implementação ATK para um objeto específico

Todos `GObject`s implementam uma função `get_type()`. Usando o exemplo acima, a convenção de nome para esse nome de função seria `myatkimp_mytype_get_type()`.

Nesta função, você especificaria quais interfaces seu objeto implementa. Se a seguinte lógica estivesse incluída nesta função `get_type()`, esse objeto implementaria a interface `ATK_TEXT`:

###### Exemplo de função `get_type()`

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

A função `atk_text_interface_init()`, que possui o protótipo a seguir, precisaria ser implementado:

    void atk_text_interface_init (AtkTextIface *iface);

Essa função conectaria as chamadas de função de interface com a implementação específica a seguir:

###### Conectando chamadas personalizadas de interface a uma implementação AtkObject

    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;
       ...
    }

Então, as funções `myatkimp_mytype_get_text()`, `myatkimp_mytype_get_character_at_offset()` e o resto das funções de interface `ATK_TEXT` precisariam ser implementadas.

##### Implementação de `AtkObject`

`AtkObject`s são `GObject`s e todos `GObject`s precisam especificar a função `get_type()`. Aqui está um exemplo que configura uma classe e inicializador de instância. Essa função `get_type()` também especifica que o objeto implementa `ATK_TEXT` e especifica o objeto pai para ser `MYATKIMP_MYPARENTTYPE`.

###### Exemplo de implementação `get_type()`

    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 */
          };

          /* Configura a estrutura atk_text_info usada abaixo */
          static const GInterfaceInfo atk_text_info =
          {
             (GInterfaceInitFunc) atk_text_interface_init,
             (GInterfaceFinalizeFunc) NULL,
             NULL
          };

          /* Configura o nome de tipo e especifica o pai do tipo */
          type = g_type_register_static (MYATKIMP_MYPARENTTYPE,
                "MyatkimpMytype", &tinfo, 0);

          /* Essa classe implementa uma interface ATK_TYPE_TEXT */
          g_type_add_interface_static (type, ATK_TYPE_TEXT,
                                       &atk_text_info);
       }
       return type;
    }

##### Inicializadores de classe/instância

Você precisará configurar um inicializador de classe para o `GObject` se sua implementação `AtkObject`:

1. Redefine quaisquer chamadas de função definidas pelo pai do objeto. Isso geralmente é necessário quando um objeto precisa implementar uma função como `atk_object_get_n_accessible_children()`. Isso é necessário se o objeto possui um filho, mas eles não são representados com widgets.

   Por exemplo, se sua implementação ATK precisa substituir a função `AtkObject` `get_name()` então o inicializador de classe seria algo como:

   ###### Inicializador de classe que substitui a função `get_name?()` do pai

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

2. Requer uma função `parent->init`, `parent->notify_gtk` ou `parent->finalize`. Esse exemplo define todas as três:

   ###### Inicializador de classe que define suas próprias `init()`, `notify_gtk()` e `finalize()`

       static ParentObjectType *parent_class = NULL;

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

          /*
           * Pegar a classe pai é necessária se as funções
           * init, notify_gtk ou finalize estiverem definidas.
           */
           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

      Uma função `parent->init()` pode ser necessária se a implementação ATK precisar sfazer uma das duas coisas:

      1. Fazer cache de quaisquer dados obtidos do widget GTK backup.

      2. Ouve quaisquer sinais do widget GTK backup.

      Aqui está um exemplo de ambos:

      ###### Uma função `init()` personalizada

          void
          gail_tree_view_widget_init (MyatkimpMytype  *mytype,
                                      GtkWidget       *gtk_widget)
          {
             /* Certifica-se de chamar a função init do pai */
             parent_class->init (widget, gtk_widget);

             /* Fazer cache de um valor na implementação ATK */
             mytype->cached_value = gtk_widget_function_call();

             /* Ouve um sinal */
             gtk_signal_connect (GTK_OBJECT (gtk_widget),
                                 "signal-type",
                                 GTK_SIGNAL_FUNC (_myatkimp_mytype_signal_type),
                                 NULL);
          }

      Neste exemplo, se o sinal `signal-type` especificado foi gerado no `gtk_widget` backup, então a função `_myatkimp_mytype_signal_type()` seria chamada.

   2. parent->notify_gtk

      Se a implementação ATK precisa ouvir a quaisquer notificações de propriedade no objeto GTK backup, uma função `parent->notify_gtk()` pode ser necessário. Por exemplo:

      ###### Uma função `notify_gtk()` personalizada

          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)
             {
                /* Lida com a alteração de propósito. */
             }
             else
             {
                parent_class->notify_gtk (obj, pspec);
             }
          }

   3. parent->finalize

      Se for necessário liberar quaisquer dados quando uma instância `GObject` é destruída, então uma função `finalize()` é necessária para liberar a memória. Por exemplo:

      ###### Uma função `finalize()` personalizada

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

### Criando componentes acessíveis personalizados

Adicionar suporte ATK ao seu widget personalizado vai garantir que sua cooperação com a infraestrutura de acessibilidade. Esses são os passos gerais que são necessários:

- avaliar um widget personalizado de acordo com as Diretrizes de interface de usuário;

- determine which ATK interfaces a custom widget should implement, according to the widget's feature set and function;

- assess which ATK interfaces can be inherited from the parent widget class;

- implementar as interfaces ATK adequadas para a classe widget em uma das duas formas:

  - diretamente pelo widget personalizado, ou

  - em um subtipo de `AtkObject` criado por uma nova subclasse de `AtkObjectFactory`

  Se o segundo método for usado, o tipo de fábrica adequada deve ser registrada com o `AtkObjectFactoryRegistry` em tempo de execução.

O código-fonte do GAIL serve como um excelente tutorial para uso avançado do ATK.

### Diretrizes de interface de usuário para suporte a acessibilidade

Ao projetar a interface gráfica do aplicativo, há várias diretrizes simples que você deve seguir para garantir que ele possa ser usado pela maior audiência possível, seja em conjunto com tecnologias assistivas ou não. Porém, não se engane em achar que isso é apenas um caso de “tornar sua interface gráfica usável por pessoas com deficiências” e que você não deveria ser incomodar se você conhece uma pessoa com deficiência que nunca vai usar seu aplicativo. Seguir essas diretrizes via melhorar a usabilidade geral de seu aplicativo para todo muito que o usa - incluindo você!

#### Geral

Todos nós ficamos frustrados se não pudermos encontrar um recurso em um aplicativo ou se cometermos um erros dos quais leva alguns minutos para recuperar, se for possível recuperar. Se você tem algum tipo de deficiência, as chances são de que as penalidades de esforço e tempo envolvidas serão muitas vezes pior. Seguir umas diretrizes básicas pode ser útil para evitar esses tipos de situações para todos os usuários.

- Forneça “Desfazer” para toda ação que altera os dados do usuário ou as configurações do aplicativo. Se possível, forneça mais de um nível de desfazimento e refazimento, e uma lista de histórico para permitir pré-visualização de quais ações serão desfeitas.

- Forneça comandos para restaurar configurações padrões. Se uma configuração em particular poderia tornar o aplicativo completamente não usável para um indivíduo (ex.: tornando as fontes pequenas demais), seria útil fornecer uma opção para restaurar as configurações padrões fora do aplicativo em si. Isso poderia ser feito usando uma opção de linha de comando, por exemplo.

- Ajude a evitar que os usuários façam coisas erradas. Isso é particularmente importante para ações que poderiam ser feitas por acidente (ex.: ações com o mouse) ou que não podem ser facilmente desfeitas (ex.: sobrescrever um arquivo). Considere usar diálogos de confirmação ou forçar o usuário a ir para um modo em particular para realizar ações potencialmente destrutivas.

- Minimize a carga de memória dos usuários. Por exemplo, deixe o usuário ver múltiplos documentos de uma só vez e assegure-se de que ajuda on-line e outras instruções possa permanecer visíveis enquanto elas carregarem o procedimento sendo descrito. Permita-os copiar qualquer informação que é exibida, cole-a em qualquer lugar em que dados podem ser inseridos.

- Não faça usuários inserirem discos. Dependendo de uma deficiência específica do usuário, ele pode achar difícil inserir ou alterar fisicamente um disco ou identificar o disco correto em primeiro lugar. Se seu aplicativo é instalado a partir do CD-ROM, forneça uma opção de copiar todos os arquivos que serão exigidos para o disco rígido do usuário.

- Não coloque funções frequentemente usadas muito adentro em uma estrutura de menu. Esteja você usando um mouse, teclado ou algum outro dispositivo de entrada, itens de menu profundamente aninhados devem ser evitados. Assim como o esforço de lembrar onde localizá-los, eles são sempre muito difíceis e gastam tempo para acessar.

- Não leve usuários por meio de etapas desnecessárias. Por exemplo, assistentes são úteis para usuários que tem dificuldade em lidar com grande quantidade de opções de uma só vez, mas outros usuários podem precisar minimizar a quantidade de tempo ou teclas pressionadas que eles usam. Tais usuários se beneficiam de serem capaz de pular etapas desnecessárias ou de irem diretamente à etapa que eles desejam. Considere fornecer um botão Finalizar em assistentes que pula direto para o fim e presume as respostas padrões para as etapas intermediárias. Se o processo possui muitas etapas, considere perguntar ao usuário no começo se ele deseja seguir por todos as etapas, apenas aquelas mais comumente usadas.

#### Navegação do teclado

Uma interface de usuário de teclado bem projetada representa um papel chave quando você está projetando um software acessível. Usuários cegos podem navegar no software com muito mais eficiência usando o teclado porque o uso do mouse depende de um feedback visual da localização do ponteiro do mouse. Além disso, o comprometimento de mobilidades pode impedir que o usuário navegue com sucesso usando o mouse por causa da precisa habilidade de controle motor fino que é necessário.

Portanto, é importante disponibilizar todas as ações de mouse a partir do teclado e incluir o acesso do teclado às barras de ferramentas, menus, links e botões. Toda função que seu aplicativo fornecer deve estar disponível usando apenas o teclado. Oculte seu mouse enquanto você está testando seu aplicativo, se necessário!

A maioria das funcionalidades deve ser fácil de tornar acessível usando aceleradores e mnemônicos de teclado e usando os recursos de navegação embarcados do kit de ferramentas. Porém, as operações que dependem de arrastar e soltar, por exemplo, podem exigir mais esforço.

- Forneça acesso eficiente de teclado a todos os recursos de aplicativo. Alguns usuários podem não ser capazes de usar um mouse e muitos “usuários avançados” preferem usar o teclado mesmo assim. Também, alguns dispositivos de entrada especializados para tecnologia assistiva podem simular eventos de teclado em vez de eventos de mouse. Já que digitar é difícil ou até mesmo doloroso para alguns usuários, é importante fornecer uma interface de teclado que minimiza o número de pressionamentos de tecla exigidos para quaisquer tarefas dadas.

- Use uma ordem lógica de navegação de teclado. Ao navegar por uma janela com a tecla Tab, o foco do teclado deve mover entre controles em uma ordem previsível. Em localidades ocidentais, isso normalmente é da esquerda para direita e de cima para baixo.

- Garanta a ordem correta de tabulações para controles cujo estado habilitado é dependente de caixa de seleção, botão de opção ou botão de alternância que possui controles dependentes, não dê foco automaticamente ao primeiro controle dependente; em vez disso, deixe o foco no botão.

- Não sobrescreva recursos existentes de acessibilidade em nível de sistema. Por exemplo, AccessX é uma extensão do Xserver que tem suporte desde o X11R6. Os recursos de MouseKeys (teclas de mouse) desta extensão permite movimento e cliques de botão de mouse serem simulados usando o teclado numérico. Portanto, você não deve adicionar recursos a seu aplicativo que possam ser acessados apenas pressionando teclas no teclado numérico, já que usuários que dependem do recurso MouseKeys não poderão usá-los.

- Forneça mais do que um método para realizar tarefas de teclado quando possível. Alguns usuários podem achar algumas teclas ou combinações de teclas mais fáceis para usar do que outras.

- Forneça ambos acessos de teclado e mouse para funções quando possível. Alguns usuários podem apenas ser capazes de usar mouse ou teclado, mas não ambos.

- Não atribua distâncias estranhas para operações de teclado frequentemente realizadas. Algumas pessoas podem apenas ser capazes de usar uma mão no teclado, então atalhos que possam ser usados com uma mão são preferíveis para operações comuns. De qualquer forma, ter que frequentemente alcançar teclas longes ou de difícil acesso no teclado pode aumentar tensão muscular para todos usuários, aumentando o risco de dor ou dano.

- Não exija uso repetitivo de pressionamentos de teclas simultâneos. Alguns usuários só são capazes de pressionar e manter pressionada uma tecla por vez. Tecnologias assistivas tal como AccessX pode permitir que usuários pressionar teclas sequencialmente em vez de simultaneamente, mas isso significa, é claro, que a operação levará mais tempo para concluir.

- Certifique-se de que qualquer texto que possa ser selecionado com o mouse também possa ser selecionado com o teclado. Isso é uma conveniência para todos usuários, mas especialmente para aqueles cujo controle fino do mouse é difícil.

- Certifique-se de que objetos que possam ser redimensionados ou movidos usando arrastar e soltar também possam ser movidos com o teclado. Por exemplo, ícones e janelas na área de trabalho. Onde a precisão de redimensionamento ou colocação for potencialmente importante, como, por exemplo, formas em um diagrama, considere também fornecer um diálogo no qual você possa digitar coordenadas, ou uma forma de anexar objetos a uma grade definível pelo usuário.

- Não use funções de navegação geral para disparar operações. Por exemplo, não use navegação básica de teclado com Tab em um diálogo para ativar quaisquer ações associadas com um controle.

- Mostre menus, janelas e dicas chamáveis por teclado próximo ao objeto aos quais eles estão relacionados. No GNOME 2.0, usuários pode chamar menus suspensos com Shift F10 e dicas de ferramentas com Shift F1. Porém, não oculte ou obscureça completamente o objeto ao qual o menu ou a dica se refere.

#### Interação do mouse

Lembre-se que nem todo mundo pode usar um mouse com igual dexteridade e que alguns usuários podem ter dificuldade em ver ou seguir o ponteiro do mouse.

- Não dependa da entrada dos botões 2 ou 3 do mouse. Além de ser fisicamente mais difícil de clicar, alguns dispositivos de apontamento e muitos dispositivos de tecnologia assistiva oferecem suporte apenas ao botão 1. Algumas tecnologias assistivas podem até nem emular o mouse, mas geram eventos de teclado.

- Permita que todas as operações sejam canceladas. O pressionamento da tecla Esc deve cancelar qualquer operação do mouse em progresso, tal como arrastar e soltar um arquivo em um gerenciador de arquivos, ou desenhar uma forma em um programa de desenho.

- Forneça um feedback visual por toda uma operação de arrastar e soltar. Na medida em que o mouse passa por alvos válidos, realce-os e altere o ponteiro do mouse. Use o ponteiro de mouse “não soltar” ao passar por cima de alvos inválidos para soltar. Veja Exemplos de interação do mouse.

- Não altere o ponteiro do mouse, nem restrinja o movimento do mouse a uma parte da tela. Isso pode interferir com tecnologias assistivas, e é geralmente confuso mesmo para usuários que não dependem delas.

- Não faça dos alvos de mouse pequenas demais. Em geral, alvos de mouse devem pelo menos do tamanho da “área quente” em volta da borda redimensionável da janela no atual tema/gerenciador de janelas - tenha em mente que um usuário com destreza ou visão prejudicada pode estar usando um gerenciador de janelas com áreas maiores do que o padrão.

##### Exemplos de interação do mouse

###### Exemplo de ponteiro “não soltar” do CDE/Motif

Exemplo de uma forma de ponteiro de “alvos inválidos para soltar”

#### Elementos gráficos

Forneça opções para personalizar a apresentação de todos os elementos gráficos importantes em seu aplicativo. Isso facilitará para pessoas com dificuldades visuais ou cognitivas para suar.

- Não codifique os atributos gráficos, tal como espessura de linha, borda ou sombra. Esses elementos idealmente devem ser lidos a partir do tema de gerenciador de janelas ou GTK. Se isso não for possível, forneça opções dentro de seu aplicativo para alterá-los.

- Forneça nomes descritivos para todos os componentes da interface. A biblioteca GAIL fornece descrições acessíveis padrões para muitos widgets GTK, mas você ainda precisará adicionar suas próprias em alguns casos, como para widgets que usam gráficos em vez de textos (ex.: um poço em uma paleta de cores, ou um ícone sem um rótulo). Considere sobrepôr os padrões com descrições mais úteis e específicas para seu aplicativos, onde possível.

- Permita que elementos gráficos multicores (ex.: ícones de barra de tarefas) sejam mostrados em monocromáticos, se possível. Essas imagens monocromáticas devem ser mostradas nas cores de primeiro plano e de plano de fundo do sistema, as quais os usuários terão escolhidos para eles mesmos (por suas escolhas de tema GTK) para máxima legibilidade.

- Torne os elementos interativos da GUI facilmente identificáveis. Por exemplo, não faça o usuário flutuar o mouse sobre um objeto para determinar se ele é clicável ou não. Deixe espaço suficiente entre objetos e delineie claramente os limites do objeto. Não mostre elementos da GUI que parecem bonitos, mas que não servem para nada, a menos que você também forneça uma opção para desligá-los.

- Forneça uma opção para ocultar gráficos que não transmitam informações essenciais. Imagens gráficas podem ser distrativas para usuários com algumas deficiências cognitivas. Os ícones no menu de pé do GNOME, por exemplo, podem ser desligados enquanto deixa os menus completamente funcionais.

#### Fontes e texto

Até mesmo para um usuário com visão normal, a saída textual fornece a maioria de informações e feedback na maioria dos aplicativos. É, portanto, crítico escolher e posicionar o texto cuidadosamente na tela, e deixar a escolha da fonte e tamanho par ao usuário, para garantir que as pessoas com dificuldades visuais também possam usar seu aplicativos efetivamente.

- Não defina por código os estilos e tamanhos da fonte. O usuário deve ser capaz de ajustar todos os tamanhos e tipos de fonte. Se por algum motivo você não puder disponibilizar esta funcionalidade, nunca defina no código qualquer tamanho de fonte menor que 10 pontos.

- Forneça opções para desligar quaisquer “backdrops” gráficos ou “marcas d'água” atrás do texto. Tais imagens interferem com o contraste entre o texto e seu plano de fundo, que podem causar dificuldade para usuários com dificuldades visuais.

- Rotule objetos com nomes que farão sentido quando retirados do contexto. Usuários que dependam de leitores de tela ou tecnologias assistivas similares não necessariamente serão capazes de entender imediatamente a relação entre um controle e o que está em volta dele.

- Não use o mesmo rótulo mais de uma vez na mesma janela. Se você usa o mesmo rótulo em janelas diferentes, ajudará se significarem a mesma coisa em ambas janelas. Além disso, não use rótulos que são escritos diferentemente, mas tem o mesmo fonética, como “acento” e “assento”, pois isso poderia ser confuso para usuários que dependam de leitores de tela.

- Posicione rótulos de forma consistente por todo seu aplicativo. Isso normalmente significa imediatamente abaixo de ícones grandes, imediatamente à direita de ícones pequenos, e imediatamente acima ou para a esquerda de outros controles. Veja Exemplos de fontes e texto.

- Quando você usar texto estático para rotular um controle, termine o rótulo com um caractere de dois pontos. Por exemplo, Nome de usuário: para rotular um texto no qual o usuário deve digitar seu nome de usuário. Isso ajuda a identificá-lo como um rótulo do controle em vez de um item de texto independente.

- Quando você usar texto estático para rotular um controle, certifique-se que o rótulo preceda imediatamente aquele controle na ordem de Tab. Isso vai garantir que o mnemônico (caractere sublinhado) que você atribui ao rótulo vai mover o foco ou ativar o controle correto quando pressionado.

- Forneça alternativas a WYSIWYG. Alguns usuários podem precisar imprimir texto em uma fonte pequena, mas editar em uma fonte de tela maior, por exemplo. Alternativas possíveis incluem exibir todo texto na mesma fonte e tamanho (ambos os quais são escolhidos pelo usuário); uma opção “quebra-de-texto” que permite que você leia todo o texto em uma janela sem ter que rolar horizontalmente; uma visão de única coluna que mostra o conteúdo da janela em uma única coluna mesmo se for imprimido em múltiplas colunas; e uma visão somente texto, na qual gráficos são mostrados como marcadores de lugar e descrições de texto. Se o aplicativo possuir painéis com controles internos, considere permitir que os painéis sejam redimensionados junto com a janela pai.

##### Exemplos de fontes e texto

###### Posicionamento correto de rótulo para vários elementos da GUI

List control with label above Controle de lista com rótulo em cima | Large file manager icon with label underneath Ícone grande do gerenciador de arquivos com rótulo embaixo | Small toolbar icon with label to its right Ícone pequeno da barra de ferramentas com rótulo a sua direita | Spinbox control with label to its left Controle de caixa giratória com rótulo a sua esquerda

#### Cor e contraste

Poor choice of colors on the screen can cause problems for users with color blindness (for whom hue is important) or low-vision (for whom brightness/contrast is important). Generally, you should allow the user to customize the colors in any part of your application that conveys important information.

Users with visual impairments may require a high level of contrast between the background and text colors. Often a black background and white text is used to prevent the background from "bleeding" over. These settings are critical for users with visual impairments.

- Don't hard-code application colors. Some users need to use particular combinations of colors and levels of contrast to be able to read the screen comfortably. Therefore all the main colors you use in your GNOME application should be taken from the GTK theme, so the user can set the colors for all their applications to something legible just by changing the theme. If for some reason you do need to use colors that are not available in the theme, ensure they are customizable within the application itself.

- Don't use color as the only means to distinguish items of information. All such information should be provided by at least one other method, such as shape, position or textual description. See Color and Contrast Examples.

- Support all the high contrast GNOME themes. Ensure that when one of these themes is selected, all the text in your application appears in the high contrast foreground and background colors specified by the theme.

- Ensure your application is not dependent on a particular high-contrast theme. Test it with different high-contrast themes to ensure your application respects the settings.

##### Exemplos de cor e contraste

###### Example illustrating redundant use of color

Example showing changes in stock price using color only | This display could cause problems for a red-green color-blind user (color-blindness affects as many as 1 in 7 males in some parts of the world). The lack of contrast between the red text and black background would also make it hard to read for a user with low vision, even with a screen magnifier.
Example showing changes in stock price using both color and arrows | This display reinforces the color-coding with arrows to show the stock price movement, and uses darker shades of green and red on a lighter background to provide higher contrast. This needn't be the default color scheme if testing were to show it to be too distracting for the majority of users, but it should be possible to customize it in this way either by theming or via the application's Preferences dialog.

#### Ampliação

Many users, even those not visually impaired, benefit from magnification of text and graphics. However, without magnification, a visually impaired user may not be able to access and use the program at all.

- Provide the ability for the user to magnify the work area.

- Provide options in the application to scale the work area. Users need to have an option to magnify the work area 150% to 400% or more. Test the application to confirm the object you are viewing is not affected by changing the magnification settings.

#### Áudio

People who have difficulty hearing, as well as those who work with the sound on their computers turned off, will be disadvantaged if your application relies on sound to convey information. In general, make sure that the user is able to have any audible information conveyed in other ways.

- Don't assume that a user will hear audio information. This applies as much to users with broken soundcards as it does to those with hearing impairments!

- Don't use audio as the only means of conveying information. Give the user the option to have all audio information provided in a visual way as well. This includes providing closed captioning or transcripts for any important spoken sound clips.

- Allow users to configure frequency and volume of all warning beeps and other sounds. This includes being able to turn off sound altogether.

#### Animação

Used sparingly, animation can be useful for drawing attention to important information in your application - and it can look cool, too. However, it can be problematic for some users, so make sure they can turn it off.

- Don't use flashing or blinking elements having a frequency greater than 2 Hz and lower than 55 Hz. This includes text as well as any graphical objects. Anything in this frequency range may cause particular problems for users susceptible to visually-induced seizures. Note that there is no "safe" frequency, though. If flashing is essential, you should use the system's cursor blink frequency (which should itself be customizable), or allow users to configure the frequency themselves.

- Don't flash or blink large areas of the screen. Small areas are less likely to trigger seizures in those susceptible to them.

- Make all animations optional. The animated information should be available in at least one non-animated format, at the user's request.

#### Foco do teclado

Showing the keyboard focus position clearly at all times is important, both for users with vision impairments as well as "power-users" who prefer to use the keyboard rather than the mouse. There should never be any confusion as to which control on the desktop has focus at any given time. You ought to be able to leave your computer with the focus on any widget in your application, then go off and phone your girlfriend or walk the dog until you've forgotten which widget you left it on. When you return, you should be able to tell straight away exactly which widget it was.

A visual focus indicator is an audio representation of the cursor position relative to the other objects on the desktop. This allows the user to move among objects interactively as the focus changes. The visual focus must be programmatically exposed to assistive technologies. Note that in most cases, this is handled automatically by the ATK, without requiring you to do any additional work. However, you will need to be aware of this requirement when writing your own custom widgets, for example.

- Start focus at the most commonly used control. If no control in a window is deemed to be the "most" useful, start the focus at the first control in the window when that window is opened. Focus should not be started on the OK or Cancel buttons of a dialog even if they are the most commonly used controls, as they can always be activated immediately by pressing Enter or Escape.

- Show current input focus clearly at all times. Remember that in controls that include a scrolling element, it is not always sufficient to highlight just the selected element inside that scrolling area, as it may not be visible. See Keyboard Focus Examples.

- Show input focus only in the active window. Hide all primary visual focus indicators in all windows that do not have the focus and activation. If a single window has separate panes, only one pane should have the focus indicator, and focus indicators should be hidden in all other panes. If it's important to continue showing which item in an unfocused list is selected, for example, use a secondary focus indicator. See Keyboard Focus Examples.

- Provide appropriate feedback when the user attempts to navigate past the end of a group of related objects. When navigating a list, for example, stopping with audio feedback is usually preferable to moving the focus back to the first object in the list. Otherwise, users who are blind or have low vision may not realize they have returned to the beginning. In the case of a text search in a document, a dialog may pop up to indicate that the end of the document has been reached, and ask if you want to resume the search at the start of the document.

- Play the system default audio or visual warning signal when the user presses an inappropriate key, or when a navigation key fails to move the focus. For example, when the focus is on the first character in a text field and the user presses left arrow key, or the user tries to perform multiple selection in a single selection dialog. (Note that users with hearing difficulties should be able to configure a system-wide visual equivalent to the default warning sound.)

##### Exemplos de foco do teclado

###### Example illustrating need to show focus clearly

The focused item in this window cannot be seen because it has been scrolled off-screen | One of the controls in this window has focus, but it's impossible to tell which...
The focused item in the list has been brought into view by scrolling the list | ...until you scroll the list, which reveals that one of its items is currently selected.
The list control in this example has a solid border indicating focus, whether its selected item is currently visible or not | If the list control itself is given a "focused" border, it's easy to tell it has focus even when the currently-selected item isn't visible.

###### Example illustrating use of secondary focus

Split-paned window in which both panes seem to have focus | In this example, it's impossible to tell just by looking which of the two panes actually has keyboard focus.
Split-pane window in which secondary highlighting is used to show which pane has focus | By using a secondary selection highlight color in the inactive pane, it's immediately obvious that the tree control has focus here...
Split-pane window in which secondary highlighting is used to show which pane has focus | ...and that the list control has focus here.

#### Tempo

Interfaces in which things appear, disappear or happen according to some hard-coded time limit are often a hindrance to accessibility. Some users may read, type or react very slowly in comparison to others. If information they require is hidden before they are finished with it, or obscured by other information popping up which they didn't explicitly request, then your application will become very frustrating or even impossible to use.

- Don't hard-code timeouts or other time-based features. Examples include automatic scrolling when dragging an object towards the edge of a window, holding down a scrollbar button, or automatically expanding a tree node when an object is dragged over it and held for a short time. These should either be customizable in the application, the GNOME control center, or at worst, manually editable from the command line via a configuration file or GConf entry.

- Don't briefly show or hide information based on the movement of the mouse pointer. (Exception: system-provided features such as tooltips, which the user can configure on a system-wide level). If you must provide such features, make them optional so users can turn them off when a screen-review utility is installed.

#### Documentação

People with disabilities cannot use the application effectively if they do not have access to the required manuals and help files. Of particular importance is keyboard navigation, since this is the only way many users can navigate the application.

- Provide all documentation in an accessible format. ASCII text and HTML are both excellent formats for assistive technologies.

- Provide alternative text descriptions for all graphics in the documentation.

- Document all your application's accessibility features. Keyboard navigation and shortcuts are particularly important to document. Include an accessibility section in your documentation, where information on all the accessibility features can be found.

## Testes

There are several points of review to conduct before declaring an application accessible. Over the course of development you may want to consider automated testing techniques. LDTP, for example, may complement your automated testing plan.

This section describes a number of tests you can perform manually on an application to test its accessibility. Passing all the tests does not necessarily imply that the application is fully accessible, but if the application fails any of these tests, then further work may need to be done to improve that aspect of its accessibility.

### Navegação do teclado

The following keyboard operations should be tested. Do not use the mouse in any part of this test.

- Using only keyboard commands, move the focus through all menu bars in the application.

- Confirme que:

  - Context sensitive menus display correctly.

  - Any functions listed on the toolbar can be performed using the keyboard.

  - You can operate every control in the client area of the application and dialog boxes.

  - Text and objects within the client area can be selected.

  - Any keyboard enhancements or shortcuts are working as designed.

### Elementos gráficos

Test the application using a screen reader and confirm that:

- Labels and text are being read correctly, including menus and toolbars.

- Informações do objeto são lidas corretamente.

### Indicador de foto visual

- Verify that when moving among objects that the visual focus indicator is easy to identify.

- Keyboard navigation through the software and menus should be clearly visible when the focus moves.

- Confirm that the screen reader is tracking the visual focus indicator as you navigate using a keyboard.

- Run a screen magnification program (if available) and verify that the magnifier can track the visual focus indicator as you navigate using the keyboard and mouse.

### Fontes e texto

- Change the font in the application and confirm that the settings are maintained.

- Test the application by changing colors and confirm that all settings are maintained.

- If magnification is available, test the font, color, and size using the magnification option.

### Cor e contraste

- Print screenshots to a black and white printer and confirm that all information is visible.

- Test applications using only black and white, high-contrast settings and confirm that all information is conveyed correctly.

- Test that the application provides at least three combinations of color schemes and that high-contrast schemes are available (e.g. white on black or yellow on blue).

- Turn on high-contrast settings in the GNOME Control Center and confirm that the application respects these settings.

- Test various themes to ensure that the software is working for all the available settings.

### Áudio

There should be an option in the application to show audio alerts visually.

Test that the audio is working correctly by enabling sound in the GNOME Control Center and then perform the following actions:

- Perform an action that should generate an audio alert and confirm that the application is working as designed.

- Verify that the application works correctly when increasing or decreasing the volume.

- Confirm that warning messages and alerts can be heard correctly in a noisy work environment.

### Animação

Verify that an option is available to stop animation and that it is working as designed.

Turn the animation off. Confirm that all information is still conveyed correctly.

### Foco do teclado

- Test all messages to confirm that the user is notified before a message times out and is given the option to indicate that more time is needed.

- Make sure an option has been included to adjust the response time and confirm that it is working as designed.

### Documentação

Test ASCII text documentation with a screen reader to confirm that it is clear and precise and can be read by assistive technologies.

Test HTML applications using a web browser and screen reader to confirm that the documentation is accessible to assistive technologies.

Note: There are web accessibility guidelines available at http://www.w3.org/TR/WAI-WEBCONTENT/.

Confirm the following information is included in the documentation:

- State if the application does not support the standard keyboard access used by the OS.

- Identify if there are unique keyboard commands.

- Identify any unique accessibility features.

- If an action is documented for the mouse, make sure there is an alternative for using the keyboard.

### Lista de verificação de interface de usuário

Essa seção resume as diretrizes dadas em Diretrizes de interface de usuário para suporte a acessibilidade. Você deveria acessar aquela seção do guia para informações mais detalhadas em qualquer um dos itens da lista de verificação dada.

When testing an application for accessibility, you should go through each of the items in the list. Note whether the application passes or fails each test, or does not apply to that application.

### Lista de verificação de princípios da gerais

PG | Princípios gerais | Passou/Falhou/ND
PG.1 | Every action that alters the user's data or application's settings can be undone.
PG.2 | All application settings can be restored to their defaults without the user having to remember what those defaults were.
PG.3 | After installation, the application can be used without the user having to insert a disk or CD at any time.
PG.4 | The most frequently used functions are found at the top level of the menu structure.

### Lista de verificação de navegação do teclado

NT | Navegação do teclado | Passou/Falhou/ND
NT.1 | Efficient keyboard access is provided to all application features.
NT.2 | All windows have a logical keyboard navigation order.
NT.3 | The correct tab order is used for controls whose enabled state is dependent on checkboxes, radio buttons or toggle buttons.
NT.4 | Keyboard access to application-specific functions does not override existing system accessibility features.
NT.5 | The application provides more than one method to perform keyboard tasks whenever possible.
NT.6 | There are alternative key combinations wherever possible.
NT.7 | There are no awkward reaches for frequently performed keyboard operations.
NT.8 | The application does not use repetitive, simultaneous keypresses.
NT.9 | The application provides keyboard equivalents for all mouse functions.
NT.10 | Any text or object that can be selected with the mouse can also be selected with the keyboard alone.
NT.11 | Any object that can be resized or moved with the mouse can also be resized or moved with the keyboard alone.
NT.12 | The application does not use any general navigation functions to trigger operations.
NT.13 | All keyboard-invoked menus, windows and tooltips appear near the object they relate to.

### Lista de verificação de interação do mouse

IM | Interação do mouse | Passou/Falhou/ND
IM.1 | No operations depend on input from the right or middle mouse buttons.
IM.2 | All mouse operations can be cancelled before they are complete.
IM.3 | Visual feedback is provided throughout drag and drop operations
IM.4 | The mouse pointer is never warped under application control, or its movement restricted to part of the screen by the application.

### Lista de verificação de elementos gráficos

EG | Elementos gráficos | Passou/Falhou/ND
EG.1 | There are no hard-coded graphical attributes such as line, border or shadow thickness.
EG.2 | All multi-color graphical elements can be shown in monochrome only, where possible.
EG.3 | All interactive GUI elements are easily distinguishable from static GUI elements.
EG.4 | An option to hide non-essential graphics is provided.

### Lista de verificação de fontes e texto

FT | Fontes e texto | Passou/Falhou/ND
FT.1 | No font styles or sizes are hard-coded.
FT.2 | An option to turn off graphical backdrops behind text is provided.
FT.3 | All labels have names that make sense when taken out of context.
FT.4 | No label names are used more than once in the same window.
FT.5 | Label positioning is consistent throughout the application.
FT.6 | All static text labels that identify other controls end in a colon (:).
FT.7 | Static text labels that identify other controls immediately precede those controls in the tab order.
FT.8 | An alternative to WYSIWYG is provided. For example, the ability to specify different screen and printer fonts in a text editor.

### Lista de verificação de cor e contraste

CC | Cor e contraste | Passou/Falhou/ND
CC.1 | Application colors are not hard-coded, but are drawn either from the current desktop theme or an application setting.
CC.2 | Color is only used as an enhancement, and not as the only means to convey information or actions.
CC.3 | The application supports all available high- contrast themes and settings.
CC.4 | The software is not dependent on any particular high-contrast themes or settings.

### Lista de verificação de ampliação

AM | Ampliação | Passou/Falhou/ND
AM.1 | The application provides the ability to magnify the work area.
AM.2 | The application provides the option to scale the work area.
AM.3 | The application's functionality is not affected by changing the magnification or scale settings.

### Lista de verificação de áudio

AU | Áudio | Passou/Falhou/ND
AU.1 | Sound is not used as the only means of conveying any items of information.
AU.2 | The user can configure the frequency and volume of all sounds and warning beeps.

### Lista de verificação de animação

AN | Animação | Passou/Falhou/ND
AN.1 | There are no flashing or blinking elements with a frequency greater than 2Hz or lower than 55Hz.
AN.2 | Any flashing or blinking is confined to small areas of the screen.
AN.3 | If animation is used, an option is available to turn it off before it is first shown.

### Lista de verificação de foco de teclado

FC | Foco do teclado | Passou/Falhou/ND
FC.1 | When a window is opened, focus starts at the most commonly-used control.
FC.2 | Current input focus position is clearly displayed at all times.
FC.3 | Input focus is shown in exactly one window at all times.
FC.4 | Appropriate audio or visual feedback is provided when the user attempts to navigate past either end of a group of related objects.
FC.5 | The default audio or visual warning signal is played when the user presses an inappropriate key.
FC.6 | There is sufficient audio information for the visual focus that the user can figure out what to do next.
FC.7 | When using assistive technologies, such as a screen reader or braille device, the current program indicates the position and content of the visual focus indicator.

### Lista de verificação de tempo

TM | Tempo | Passou/Falhou/ND
TM.1 | There are no hard-coded time-outs or time-based features in the application.
TM.2 | The display or hiding of important information is not triggered solely by movement of the mouse pointer.

### Lista de verificação de documentação

DC | Documentação | Passou/Falhou/ND
DC.1 | All documentation is in an accessible format, with textual alternate descriptions provided for all figures and diagrams.
DC.2 | The documentation includes a section that covers all the application's accessibility features.

### GOK (GNOME Onscreen Keyboard)

The information on this page is partially outdated: GNOME 3's Caribou has effectively replaced GNOME 2's gok.

Your application should be usable via gok; key input should be generated entirely by gok, not the keyboard. The aim here would be to work with your application and the desktop in general, ensuring any type of character input can be performed with the on-screen keyboard.

The gok application ships with the GNOME Desktop so should already be present. For full documentation, refer to the official gok site.

Follow these steps to verify the correct operation of gok with your application:

1. Inicie uma sessão no ambiente GNOME

2. Execute gok

3. Inicie seu aplicativo

4. Provide input to your application with a pointing device (e.g., mouse or head-tracker) and gok.

5. Work using the auto-completion and word prediction features of gok.

6. Verify that gok enables and disables the Menus and Toolbars buttons based on the kind of application invoked; for example, the Menus and Toolbars buttons are disabled for the 'Font properties' capplet, but the same buttons are enabled for the Gedit application.

7. Verify that the gok on-screen keyboard provided by the Compose button can be used to type in any text for the selected application; run Gedit, click on the text area, and then click on the Compose button in gok. Select the required keys from the on-screen keyboard. The characters should appear in the Gedit text area.

8. Verify that the Launcher button allows the user to launch any of the Terminal, Web Browser or Text Editor applications.

9. Verify that the Activate button allows the user to activate any of the currently running application windows on the user's desktop, including GNOME panels and the GNOME desktop.

10. Verify that the Menus button lists all the available menus in the current application. Verify that clicking on a menu button displays the sub-menu and menu items contained within the sub-menu. Finally, verify that clicking on a menu item activates the menu item. For example, click on the Help Browser application and click on the Menus button. The GOK window now displays the File, Go and Help buttons (the Help Browser menus). Click on the File button and it displays the New Window and Close Window buttons (menu items).

11. Verify that the Toolbars button lists all the available buttons in the application toolbar. For example, click on the Help Browser application and then click on the Toolbars button. The GOK window now displays the Back, Forward and Home buttons.

12. Verifique que o botão UI Grab mostra todos os itens de objetos para a janela do aplicativo selecionado. Por exemplo, abra o capplet 'Propriedades de fonte' e clique no botão UI Grab na janela GOK. A janela do aplicativo GOK deve mostrar os nomes de botões no capplet - Sans, Sans-serif, Close e Help.

### Accerciser

Accerciser e a arquitetura de acessibilidade do GNOME

Accerciser é um explorador de acessibilidade Python para o ambiente de trabalho GNOME. Usa AT-SPI para inspecionar e controlar componentes, permitindo que você verifique se um aplicativo está provendo a informação correta para as tecnologias assistivas e infraestruturas automáticas de teste. Accerciser tem uma estrutura simples de plug-in que você pode usar para criar visualizações customizadas da informação de acessibilidade. A documentação completa pode ser vista no manual oficial do Accerciser . Para uma demonstração do Accerciser e PyATSPI (Python-wrappered acesso e uso do AT-SPI), veja esse artigo. Para uma excelente introdução do autor, veja o artigo intitulado Faça seu aplicativo acessível com Accerciser.

Accerciser efetivamente substituiu a antiga ferramenta at-poke.