Relatório Avaliação de Candidatura
Associação para a Inclusão do Cidadão com Necessidades Especiais

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #43 Botão do menu mobile implementado com elemento de navegação inadequado

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.2

  É possível selecionar as opções e as subopções do menu quer com rato quer com teclado.

  • Ver requisito 1.2 da lista 10 aspetos

  Evidências:

  Nos menus de navegação (versão mobile), verificou-se que o controlo utilizado para abrir o menu foi implementado através de um elemento <a>, apesar de representar uma ação de interface e não uma navegação para outra página.

  Os elementos <a> devem ser utilizados para navegação entre páginas ou recursos, enquanto ações como abrir e fechar menus devem ser implementadas através de elementos semanticamente adequados, como <button>.

  A utilização de um link para executar uma ação pode gerar interpretações incorretas por parte das tecnologias de apoio, que anunciam o elemento como uma hiperligação em vez de um botão. Além disso, esta abordagem dificulta a comunicação adequada do estado do componente, nomeadamente se o menu se encontra expandido ou colapsado.

  

  Figura 01: Estrutura do botão do menu implementada com elemento <a>.

  URLs a verificar:

  • https://associacaoincluir.pt/ - versão mobile

  Recomendações:

  • Substituir o elemento <a> utilizado para abrir o menu por um elemento semântico <button type="button">.
  • Garantir que a abertura e o fecho do menu são geridos através de um script associado ao botão.
  • Utilizar o atributo aria-expanded para comunicar às tecnologias de apoio o estado atual do menu.

• evidência: issue #41 Os menus não estão estruturados como uma navegação de forma apropriada

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.2

  É possível selecionar as opções e as subopções do menu quer com rato quer com teclado.

  • Ver requisito 1.2 da lista 10 aspetos

  Evidências:

  Verifica-se que não está a ser utilizado a tag nav em nenhum menu de navegação. Isso faz com que ao navegar pelo website com o leitor de ecrã, não é possível realizar saltos diretamente para o menu, nem este é identificado como uma área de navegação:

  

  Imagem do menu principal não identificado como nav

  

  Imagem do menu principal da versão mobile não identificado como nav

  URLs a verificar:

  • https://associacaoincluir.pt/ - menu principal em todos os breakpoints.

  Recomendações:

  • Todos os menus devem estar estruturados dentro de uma tag nav.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #44 Texto alternativo do botão de fechar menu apresentado em idioma diferente do conteúdo da página

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.3

  As imagem-link, caso existam no menu, devem ter o correspondente equivalente alternativo em texto.

  • Ver requisito 1.3 da lista 10 aspetos

  Evidências:

  Na versão mobile, o botão utilizado para fechar o menu apresenta o nome acessível "Close (Esc)", em inglês, apesar de o conteúdo do website estar em português.

  Foi também verificado que o botão de abertura do menu utiliza corretamente a designação "Menu", criando uma inconsistência linguística entre os dois controlos da mesma funcionalidade.

  Esta situação pode dificultar a compreensão da ação disponível por parte dos utilizadores de leitores de ecrã que esperam que os nomes acessíveis sejam apresentados no mesmo idioma do conteúdo da página.

  

  URLs a verificar:

  • https://associacaoincluir.pt/ - menu mobile

  Recomendações:

  • Garantir que os nomes acessíveis dos componentes interativos utilizam o mesmo idioma do conteúdo principal da página.
  • Substituir o texto alternativo "Close (Esc)" por uma designação equivalente em português, como por exemplo "Fechar menu (Esc)" ou "Fechar (Esc)".
  • Rever os restantes nomes acessíveis e textos alternativos do website para assegurar consistência linguística em toda a interface.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #38 Ausência de título principal h1 na página

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 2.1

  Existe um título <h1> marcado na página.

  • Ver requisito 2.1 da lista 10 aspetos

  Evidências:

  Na página analisada, verificou-se a ausência de um elemento <h1> que identifique o título principal do conteúdo.

  Conforme ilustrado na Figura 1, a estrutura da página apresenta vários elementos <h2> , mas não existe um elemento <h1> associado ao tema principal da página (“Política de Cookies”).

  A ausência de um título principal compromete a estrutura semântica da página e dificulta a compreensão da sua organização por utilizadores de tecnologias de apoio.

  

  Figura 1 - Estrutura de cabeçalhos da página, evidenciando a ausência de um elemento <h1> .

  URLs a verificar:

  https://associacaoincluir.pt/politica-de-cookies/

  Recomendações:

  • Adicionar um elemento <h1> que identifique o título principal da página, por exemplo “Política de Cookies”.
  • Garantir que cada página contém um único elemento <h1> , correspondente ao conteúdo principal.
  • Rever a hierarquia de cabeçalhos da página, assegurando uma estrutura lógica e consistente entre os diferentes níveis de títulos e subtítulos.

• evidência: issue #36 Existência de múltiplos h1 na página web

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 2.1

  Existe um título <h1> marcado na página.

  • Ver requisito 2.1 da lista 10 aspetos

  Evidências:

  Cada página do website deve conter um único elemento <h1>, que represente o título principal do conteúdo. A utilização de múltiplos <h1> pode comprometer a interpretação da hierarquia da página por tecnologias de apoio.

  Na página de Declaração de Acessibilidade, verifica-se a existência de dois elementos <h1>, o que constitui uma utilização incorreta da estrutura de cabeçalhos.

  Esta duplicação introduz ambiguidade na identificação do título principal da página e prejudica a coerência da hierarquia semântica.

  

  Figura 1 - Identificação de dois cabeçalhos marcados com <h1> na mesma página.

  URLs a verificar:

  https://associacaoincluir.pt/acessibilidade/

  Recomendações:

  • Garantir que existe um único elemento h1, correspondente ao título principal de cada página.
  • Em todas as páginas o título principal está a ser atribuído como h2 sendo necessário alterar para h1. Devem garantir que essa alteração não gere problemas na hierarquia entre os cabeçalhos.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #37 Saltos na hierarquia de cabeçalhos

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 2.2

  Existe uma marcação hierarquizada de títulos e subtítulos na página <h1>...<h6>.
  – ver requisito 2.2 na lista 10 aspetos

  Evidências:

  Nas páginas analisadas, foram identificados saltos na hierarquia de cabeçalhos (ex.: utilização de <h3> sem existência prévia de <h2>).

  Estas inconsistências comprometem a correta estrutura semântica das páginas e dificultam a navegação por utilizadores de tecnologias de apoio.

  

  Figura 1 - Salto na hierarquia de cabeçalhos, com utilização de <h3> sem <h2>.

  URLs a verificar:

  https://associacaoincluir.pt/politica-de-cookies/

  Recomendações:

  • Implementar uma hierarquia consistente de cabeçalhos (<h1>–<h6>) em todas as páginas, respeitando a ordem sequencial, sem saltos de níveis.
  • Garantir que cada página contém um único <h1> por página, correspondente ao conteúdo principal.
  • Rever a estrutura semântica das páginas de forma a assegurar que os níveis de cabeçalhos refletem corretamente a relação hierárquica entre secções e subseções.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #40 Elemento caption em falta na legenda da tabela

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 3.2

  A legenda da tabela está marcada com o elemento <caption>
  – ver requisito 3.2 na lista 10 aspetos

  Evidências:

  Foi verificado que a tabela avaliada não possui uma legenda identificada através do elemento <caption> .

  A ausência deste elemento dificulta a identificação e contextualização da tabela por utilizadores de tecnologias de apoio, que dependem da legenda para compreender o propósito e o conteúdo dos dados apresentados.

  

  Figura 1 - Tabela sem utilização do elemento para identificação da respetiva legenda .

  URLs a verificar:

  https://associacaoincluir.pt/politica-de-cookies/

  Recomendações:

  • Adicionar uma legenda descritiva à tabela através do elemento <caption>.
  • Garantir que a legenda descreve adequadamente o conteúdo e a finalidade da tabela.
  • Incluir, quando aplicável, informação adicional relevante, como a fonte dos dados apresentados.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #63 O atributo placeholder está a substituir a etiqueta

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 4.1

  Ao clicar com o rato na etiqueta, o cursor surge no respetivo campo de edição.
  – ver requisito 4.1 na lista 10 aspetos

  Evidências:
  No formulário de pesquisa da página Política de cookies, verificámos que não existe etiqueta no campo de pesquisa:

  

  Campo de pesquisa sem etiqueta e com atributo placeholder

  Como se pode observar na figura, o campo de pesquisa não tem um elemento <label>, mas sim um atributo placeholder que está a substituir a etiqueta.
  Tal situação não é recomendável, uma vez que o conteúdo do placeholder desaparece da interface assim que se começa a escrever no campo, o que pode ser prejudicial para utilizadores com défice de memória.
  Quando cada campo tem uma etiqueta que lhe está associada programaticamente, é possível focar o campo ao clicar na etiqueta (ampliação da área de clique), o que pode beneficiar pessoas com dificuldades motoras ao selecionar um campo específico.

  URLs a verificar:
  https://associacaoincluir.pt/politica-de-cookies/

  Recomendações:
  Recomendamos a revisão dos formulários para garantir que todos os campos estejam corretamente construídos:

  • A etiqueta do campo deve estar estruturada como e deve estar associada ao campo.
  • Para estar associada ao campo, o atributo for da etiqueta e o id do campo de input devem ser iguais.
    Alguns exemplos de estrutura seriam:

  <label for="firstname">Primeiro nome:</label>
  <input type="text" name="first" id="firstname">
  

  Ou,

  <label>
      Primeiro nome:
      <input type="text" name="firstname">
  </label>
  

  • O placeholder é um complemento e não um substituto da etiqueta.

etiqueta: OK (no entanto contém 1 melhoria que se recomenda efetuar)

Lista de evidências recolhidas:

• evidência: issue #64 Há campos obrigatórios que não estão identificados programaticamente

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 4.2

  É possível identificar os campos de preenchimento obrigatório quando se usa apenas um leitor de ecrã.
  – ver requisito 4.2 na lista 10 aspetos

  Evidências:

  Verificámos que a checkbox de concordância com o armazenamento dos dados do formulário de Contactos é de preenchimento obrigatório, mas não está programaticamente definido como tal:

  

  Análise do campo de concordância com o armazenamento dos dados do formulário de contactos
  URLs a verificar:
  https://associacaoincluir.pt/contactos

  Recomendações:
  Recomendamos que, em todos os campos obrigatórios, seja adicionado o atributo required de forma a reforçar aos utilizadores de tecnologias de apoio que o campo em questão é um campo de preenchimento obrigatório.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #65 Existem mensagens de erro ocultas das tecnologias de apoio

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 4.3

  É possível localizar e ler as mensagens de erro usando apenas um leitor de ecrã.
  – ver requisito 4.3 na lista 10 aspetos

  Evidências:
  Os campos 'Nome', 'Email' e 'assunto' do formulário de Contactos apresentam mensagens de erro na sua vizinhança, mas as mesmas estão ocultas das tecnologias de apoio através do atributo aria-hidden = “true”, o que impede que os utilizadores destas tecnologias consigam percecioná-las através da navegação por elementos:

  

  Mensagem de erro do campo nome oculta para as tecnologias de apoio

  Para além disso, a mensagem no topo com a lista sumária dos erros, para além de estar visível apenas para as tecnologias de apoio, não transmite informação acerca de quais dos campos foram incorretamente preenchidos, e não direciona o foco para cada um deles.

  

  Mensagem no topo oculta visualmente e não ajudando no correto preenchimento do formulário

  Como observado na figura, a mensagem “Por favor preencha este campo.” Não indica de que campo se trata, nem permite direcionar o foco para o campo.

  Verificámos ainda que foi adicionado o atributo aria-describedby a cada campo (associação programática da mensagem de erro ao campo), o que permite que cada mensagem de erro seja anunciada ao navegar por teclado (tab e shift+tab), mas o id colocado em cada valor de aria-describedby é o da respetiva mensagem de erro presente no topo e não o da mensagem na vizinhança do campo.
  Ao serem utilizados os ids das mensagens na vizinhança dos campos nos valores dos atributos aria-describedby desses campos mantém-se a coerência de anúncio de mensagens de erro para todos os utilizadores.
  Para além disso, a existência de mensagens no topo do formulário não é obrigatório caso o formulário tenha um número reduzido de campos, mas caso exista deve ser bem construída.

  URLs a verificar:
  Contactos

  Recomendações:
  Recomendamos que sejam apresentadas mensagens de erro junto aos campos de todos os formulários, visíveis para todos os agentes, para assim fornecerem apoio na correção dos mesmos e consequente submissão correta dos formulários. No caso do formulário aqui referido basta que seja removido o atributo aria-hidden de cada mensagem de erro.
  Adicionalmente, pode existir uma lista dos erros no topo de cada formulário que consolida os vários erros existentes, em que cada mensagem deve, não só remeter para o respetivo campo (por exemplo, através da colocação da mensagem num link cujo href contenha o id do respetivo campo), mas também deve conter o descritivo do campo, de modo a que o campo a que a mensagem se refere seja percecionado sem ser necessário remeter-lhe o foco a partir da mensagem.
  Um exemplo de um item de mensagem de topo seria:

  <li><a href="#id_do_campo_nome">'Nome': por favor preencha este campo</a></li>
  

  Recomendamos ainda que os ids presentes nos atributos aria-describedby de cada campo sejam os das mensagens na vizinhança dos campos.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #49 Não foram identificados gráficos no website

  etiqueta: chk 10 webetiqueta: N/Aetiqueta: R 5.2

  O gráfico é acompanhado de uma descrição longa.
  – ver requisito 5.2 na lista 10 aspetos

  Evidências:

  Após análise ao website, não foram identificados gráficos, diagramas ou outros elementos visuais de representação de dados que requeiram alternativas textuais específicas.

  Desta forma, o requisito relativo à existência de descrições alternativas para gráficos não é aplicável no contexto atual do website avaliado.

  URLs a verificar:

  N/A

  Recomendações:

  N/A

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #55 Texto normal não têm contraste suficiente

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 6.1

  No corpo de um documento, o rácio de contraste entre a cor do texto normal (menor que 18 pontos ou menor que 14 pontos negrito) e a cor do fundo é superior a 4,5:1.
  – ver requisito 6.1 na lista 10 aspetos

  Evidências:

  • O contraste no texto normal (menor que 18 pontos ou menor que 14 pontos negrito) das páginas deve ser, no mínimo 4,5:1, para que pessoas com baixa visão consigam ler o texto.

  A avaliação com a ferramenta Colour Contrast Analyser revela problemas relacionados com insuficiência de contraste, afetando diretamente a legibilidade.

  O website apresenta problemas de contraste no texto normal do menu principal da versão para dispositivos móveis na combinação de cores #848484FF(cor de primeiro plano) e #F4F4F4(cor de plano de fundo) que torna os textos pouco visíveis. (Figura 1)

  

  Figura 1- Texto normal nas opções do menu para dispositivos móveis com problemas de contraste, com uma taxa de apenas 3,4:1

  Além disso, há problemas de contraste nos estados de hover das hiperligações, por exemplo na página #29B94C(cor de primeiro plano) e #FFFFFF(cor de plano de fundo) que torna os textos pouco visíveis. (Figura 2)

  

  Figura 2- Estado de hover dos textos das hiperligações com problemas de contraste, com uma taxa de apenas 2,6:1

  Esta implementação dificultando perceção e compromete a leitura e interpretação da informação, especialmente para utilizadores com baixa visão.

  URLs a verificar

  • https://associacaoincluir.pt/ (Todo website)

  Recomendações
  Recomendamos a revisão das combinações de cores das páginas de todo website para garantir os valores mínimos de contraste do normal. Garantir consistência nos estados visuais (normal, hover, foco) com contraste adequado;

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #46 Legendas automáticas em conteúdos multimédia

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 7.2

  O vídeo ou áudio deve conter preferencialmente legendas fechadas sincronizadas.
  – ver requisito 7.2 na lista 10 aspetos

  Evidências:

  Nos vídeos avaliados, verificou-se a existência de legendas automáticas disponibilizadas através da plataforma YouTube. Estas legendas são geradas automaticamente e permitem acompanhar de forma geral o conteúdo áudio dos vídeos.

  Não foram identificados outros mecanismos adicionais de legendagem ou revisão manual das legendas para melhoria de precisão ou correção de eventuais erros de transcrição automática.

  

  Figura 1 - Exemplo de vídeo com legendas automáticas ativadas na interface do YouTube .

  URLs a verificar:

  • https://associacaoincluir.pt/sou-consigo-e-faco/
  • https://associacaoincluir.pt/minuto-solidario-montepio-2015/

  Recomendações:

  • Apesar de existir suporte a legendas automáticas, recomenda-se a disponibilização de legendas revistas ou editadas manualmente, de forma a garantir maior precisão, qualidade linguística e melhor acessibilidade para utilizadores surdos ou com dificuldades auditivas.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #35 Utilização incorreta de aria-expanded no elemento `<li>`

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.3

  Quando se retira o CSS, deve ser possível reconhecer a semântica dos diversos elementos.
  – ver requisito 8.3 na lista 10 aspetos

  Evidências:

  Foi identificada a utilização do atributo aria-expanded num elemento não interativo (<li>) do menu mobile:

  <li class="menu-item menu-item-has-children has-child"
      aria-expanded="false">
  

  O controlo responsável pela expansão/recolha do submenu é efetuado através de um elemento <button> independente:

  <button class="toggle" aria-label="Toggle">

  No entanto, o estado de expansão (aria-expanded) não se encontra associado ao elemento interativo responsável pela ação.

  De acordo com as boas práticas de acessibilidade, o atributo aria-expanded deve ser aplicado ao elemento de controlo que expande ou recolhe o conteúdo (por exemplo, <button>), permitindo que tecnologias de apoio anunciem corretamente o estado do componente.

  

  Figura 2 - Utilização incorreta de aria-expanded no elemento <li> do menu mobile

  Os leitores de ecrã poderão não anunciar corretamente o estado expandido/recolhido do submenu, dificultando a compreensão da estrutura de navegação e do estado atual do componente.

  URLs a verificar:

  • https://associacaoincluir.pt/
  • (em todo o website na versão mobile)

  Recomendações:

  • Remover o atributo aria-expanded do elemento <li>;
  • Aplicar aria-expanded ao botão responsável pela expansão do submenu;
  • Garantir atualização dinâmica do valor (true / false) conforme o estado do submenu;
  • Associar o botão ao submenu correspondente através de aria-controls, quando aplicável;
  • Substituir labels genéricas como "Toggle" por descrições contextualizadas da ação, por exemplo: "Expandir submenu Sobre Nós".

• evidência: issue #34 Modal do menu mobile sem semântica apropriada de diálogo

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.3

  Quando se retira o CSS, deve ser possível reconhecer a semântica dos diversos elementos.
  – ver requisito 8.3 na lista 10 aspetos

  Evidências:

  Foi identificado que o menu mobile apresentado em formato modal/off-canvas não utiliza uma estrutura semântica apropriada para representar um diálogo/modal acessível.

  O conteúdo do menu é apresentado dentro de elementos genéricos <div>, sem utilização de um mecanismo semântico que identifique programaticamente a região como um diálogo/modal:

  <div class="mfp-wrap mfp-auto-cursor off-canvas off-canvas-left mfp-ready" tabindex="-1">

  Não foi identificada a utilização de atributos semânticos apropriados para este tipo de componente, tais como:

  • role="dialog"
  • aria-modal="true"
  • aria-label="Menu principal"

  ou equivalente através do elemento semântico <dialog>.

  A ausência desta semântica impede que tecnologias de apoio reconheçam adequadamente a mudança de contexto quando o menu mobile é aberto.

  Leitores de ecrã poderão não anunciar corretamente a abertura de uma modal, dificultando a perceção de contexto e a compreensão da estrutura da interface.

  

  Figura 1 - Modal do menu mobile sem semântica apropriada de diálogo

  URLs a verificar:

  • https://associacaoincluir.pt/
  • (em todo o website na versão mobile)

  Recomendações:

  • Garantir que o menu mobile é identificado semanticamente como um diálogo/modal;
  • Utilizar o elemento semântico <dialog> ou adicionar role="dialog" ao contentor do modal;
  • Definir aria-modal="true" para indicar que a interação está limitada ao modal;
  • Garantir um nome acessível ao modal através de aria-label ou aria-labelledby;
  • Validar o comportamento com tecnologias de apoio para confirmar o correto anúncio da região modal.

• evidência: issue #29 Item de menu sem função identificável e sem semântica adequada

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.3

  Quando se retira o CSS, deve ser possível reconhecer a semântica dos diversos elementos.
  – ver requisito 8.3 na lista 10 aspetos

  Evidências:

  Foi identificado, no menu mobile, um item apresentado como elemento de navegação (<a>), mas sem função identificável nem propósito claro para o utilizador.

  O elemento não possui destino (href) nem executa qualquer ação quando ativado, apresentando apenas o carácter “-” como conteúdo visível e a indicação técnica “WooCommerce needed” através do atributo title.

  <li>
      <a class="element-error tooltip" title="WooCommerce needed">-</a>
  </li>
  

  Este comportamento introduz um elemento interativo sem significado funcional, podendo gerar confusão para utilizadores, particularmente quando navegam por links ou estrutura semântica da página através de tecnologias de apoio.

  Como consequência, o menu mobile inclui uma opção de navegação sem utilidade ou significado identificável, comprometendo a clareza semântica da interface.

  

  Figura 1 - Item de menu mobile sem função identificável

  URLs a verificar:

  • https://associacaoincluir.pt/
  • (em todas as páginas do website)

  Recomendações:

  • Remover o item de menu caso não corresponda a uma funcionalidade efetiva do website;
  • Garantir que todos os elementos de navegação possuem propósito claro e funcionalidade efetiva;
  • Evitar exposição de mensagens técnicas ou internas de configuração (ex.: “WooCommerce needed”) na interface pública;
  • Garantir que elementos interativos possuem nome compreensível e comportamento consistente para os utilizadores.

• evidência: issue #23 Duplicação do landmark principal (main)

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.3

  Quando se retira o CSS, deve ser possível reconhecer a semântica dos diversos elementos.
  – ver requisito 8.3 na lista 10 aspetos

  Evidências:

  Foi identificada a utilização duplicada do landmark principal da página, através da combinação de um elemento <main> e de um elemento adicional com role="main".

  <main id="main" class="">
  
  <div id="content" role="main" class="content-area">
  

  A existência de múltiplos landmarks principais sem necessidade funcional pode dificultar a navegação semântica por tecnologias de apoio, uma vez que leitores de ecrã permitem navegação rápida entre landmarks e poderão anunciar múltiplas regiões principais indistintas.

  Como consequência, os utilizadores podem ter dificuldade em compreender qual a verdadeira área principal de conteúdo da página.

  

  Figura 1 - Duplicação do landmark principal (main) na estrutura da página

  URLs a verificar:

  • https://associacaoincluir.pt/
  • (em todas as páginas do website)

  Recomendações:

  • Garantir a existência de apenas um landmark principal por página;
  • Remover o role="main" redundante quando já existe um elemento <main>;
  • Utilizar apenas um mecanismo semântico para representar a área principal do conteúdo;
  • Validar a navegação por landmarks com leitores de ecrã para confirmar existência de uma única região principal.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #25 Falta de resumo na página inicial do website

  etiqueta: R 1.1etiqueta: NOKetiqueta: chk conteúdo

  O sítio Web apresenta um resumo breve do seu propósito, visível sem fazer scroll.
  – ver requisito 1.1 na lista Conteúdo

  Evidências:

  Na página principal sem fazer scroll, não aparece presente um resumo breve do próposito do site.

  

  Imagem da página principal sem fazer scroll

  URLs a verificar:

  • https://associacaoincluir.pt/

  Recomendações:

  O propósito deve transmitir, de forma clara, o que o utilizador pode efetivamente encontrar e realizar no website. Esse propósito deve ser imediatamente visível na página, sem ser necessário fazer scroll, avançar no slideshow, entre outros.

  Como exemplo de uma boa prática, é possível verificar no website selo.usabilidade.gov que o seu propósito está escrito no topo da página:

  

  Imagem exemplo de uma frase de propósito do website selo.usabilidade.gov

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #27 Falta de glossário para termos complexos

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 1.2

  Os termos mais complexos têm uma definição agregada.
  – ver requisito 1.2 na lista Conteúdo

  Evidências:

  Ao longo do website, é possível identificar a utilização de diversos termos técnicos e complexos que surgem sem qualquer definição ou explicação associada. Na ausência de um glossário ou de mecanismos que permitam esclarecer esses conceitos, os utilizadores podem ter dificuldade em compreender plenamente a informação apresentada, especialmente aqueles que não estão familiarizados com a terminologia utilizada.

  

  Imagem com o termo complexo "ATL" sem definição agregada. Disponível em: https://associacaoincluir.pt/banco-de-recursos-para-a-inclusao/

  

  Imagem com os termos complexos "IBAN" e "CCAM" sem definição agregada. Disponível em: https://associacaoincluir.pt/como-apoiar-a-associacao-incluir/

  URLs a verificar:

  • https://associacaoincluir.pt/contactos/ - AADPCMCSM
  • https://associacaoincluir.pt/como-apoiar-a-associacao-incluir/ - IBAN, CCAM, IRS, NIF

  Recomendações:

  Recomenda-se a criação de um glossário que permita a utilização consistente de siglas ao longo do website, evitando que o utilizador tenha de procurar repetidamente a sua definição noutros parágrafos.

  Como exemplo podem visualizar o glossario do acessibilidade.gov.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #26 Falta de datas de atualização em blocos de conteúdo

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 1.3

  Cada bloco de conteúdo contém a sua data de atualização.
  – ver requisito 1.3 na lista Conteúdo

  Evidências:

  Não foi possível identificar datas de atualização em certos blocos de conteúdo analisados. Considerando que as informações relativas às associações são relevantes e exigem credibilidade, é fundamental que todos os conteúdos apresentem uma data de atualização visível, de forma a reforçar a confiança, a transparência e a fiabilidade da informação disponibilizada.

  A falta dessas referências compromete a perceção de atualidade e fiabilidade da informação disponibilizada, tornando mais difícil para o utilizador avaliar se os conteúdos e contactos apresentados continuam válidos. A inclusão de datas de atualização, especialmente em páginas institucionais e informativas, é um elemento fundamental para reforçar a transparência, a credibilidade e a confiança na informação fornecida.

  

  Página de contactos sem data de atualização.

  URLs a verificar:

  • https://associacaoincluir.pt/contactos/
  • https://associacaoincluir.pt/objetivos/
  • https://associacaoincluir.pt/sobre-nos/
  • https://associacaoincluir.pt/como-apoiar-a-associacao-incluir/
  • https://associacaoincluir.pt/banco-de-recursos-para-a-inclusao/
  • entre outros;

  Recomendações:

  • Incluir a data de publicação e/ou última atualização em todos os conteúdos relevantes;
  • Garantir que essa informação está semanticamente estruturada;
  • Assegurar consistência na apresentação das datas em todo o site.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #28 Falta da informação da entidade responsável

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 1.4

  A informação sobre a entidade responsável pelo conteúdo está em todas as páginas.
  – ver requisito 1.4 na lista Conteúdo

  Evidências:

  Todas as páginas devem apresentar o nome da entidade responsável pelos conteúdos publicados no site. O nome da entidade pode ser apresentado através de um logótipo ou texto, mas deve estar por extenso.

  Apesar de conter acesso rápido aos contactos. Observamos que o nome da entidade responsável não está disponível, o texto ”Todos os direitos reservados” não remete à entidade responsável.

  

  Imagem do rodapé com os direitos de autor e hiperligação para os contactos.

  URLs a verificar:

  • https://associacaoincluir.pt/ - rodapé

  Recomendações:

  Deve ser adicionado o nome da entidade por extenso em todo o website, como é possível observar no acessibilidade.gov.pt:

  

  Imagem de exemplo do rodapé do acessibilidade.gov.pt

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #22 Informações primárias não possuem tamanho mínimo recomendado

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 2.1

  O tipo de letra do corpo do documento é adequado e o tamanho da letra é, no mínimo, de 12 pontos.
  – ver requisito 2.1 na lista Conteúdo

  Evidências:

  Verificámos que, no website Associação Incluir, existem alguns conteúdos textuais apresentados com um tamanho de letra inferior ao recomendado para uma leitura confortável.

  As opções do menu principal, incluindo "Sobre Nós", "Objetivos", "Como Apoiar", "Contactos" e "Documentos", apresentam um tamanho de letra de 14px, valor inferior aos 16px recomendados. (Figura 01)

  

  Figura 01 — As opções do menu principal apresentam um tamanho de letra de 14px.

  Os botões "A Nossa História" , "Os Nossos Serviços" e "Como apoiar a incluir" apresentam um tamanho de letra de 15,52px, valor inferior aos 16px recomendados para conteúdos textuais. (Figura 02)

  

  Figura 02 — O Botão "A Nossa História" apresenta um tamanho de letra de 15,52px.

  Na janela de cookies do website Associação Incluir, as hiperligações "Política de Privacidade" e "Política de Cookies" apresentam um tamanho de letra de 14px. (Figura 03)

  

  Figura 03 — As hiperligações "Política de Privacidade" e "Política de Cookies" na janela de cookies apresentam um tamanho de letra de 14px.

  Verificámos que, na página Sobre Nós, o botão "Apoiar Agora" apresenta um tamanho de letra de 15,42px. (Figura 04)

  

  Figura 04 — O botão "Apoiar Agora" apresenta um tamanho de letra de 15,42px.

  Verificámos que, na página Contactos, as mensagens de validação apresentadas no formulário, como "Por favor preencha este campo.", utilizam um tamanho de letra de 14,4px. (Figura 05)

  

  Figura 05 — A mensagem de validação do formulário apresenta um tamanho de letra de 14,4px.

  Adicionalmente, a hiperligação "Mostrar informações sobre o serviço" apresenta um tamanho de letra de 14px.
  (Figura 06)

  

  Figura 06 — A hiperligação "Mostrar informações sobre o serviço" apresenta um tamanho de letra de 14px.

  URLs a verificar:

  • https://associacaoincluir.pt/ - Menu Princiapal, Botões "A nossa historia", "Os Nossos Serviços" e "Como apoiar a incluir"
  • https://associacaoincluir.pt/sobre-nos/ - Botão "Apoiar agora."
  • https://associacaoincluir.pt/objetivos/ - Botão "Apoiar agora."
  • https://associacaoincluir.pt/como-apoiar-a-associacao-incluir/ - Botão "Contacte-nos."
  • https://associacaoincluir.pt/contactos/ - Botão "Submeter" e Mensagens de erro do formulário.
  • https://associacaoincluir.pt/contactos/ (Informações úteis dos contactos: "(Chamada para a rede fixa nacional) e "(Chamada para a rede móvel nacional – MEO)"

  Recomendações:

  Garantir que os conteúdos textuais do website são apresentados com um tamanho de letra adequado à leitura em diferentes dispositivos e contextos de utilização.
  Recomenda-se a revisão dos elementos identificados, assegurando que menus, botões, hiperligações, mensagens de apoio e restantes conteúdos textuais utilizam, sempre que possível, um tamanho de letra não inferior a 16px, promovendo uma leitura mais confortável e uma melhor perceção da informação.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #15 Existem blocos de textos com mais de 100 caracteres por linha

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 2.3

  Blocos e linhas de texto com largura não superior a 100 caracteres.
  – ver requisito 2.3 na lista Conteúdo

  Evidências:

  Verificámos que, na página inicial do website Associação Incluir, a secção "Cada contribuição faz a diferença!" apresenta blocos de texto com uma largura superior à recomendada para uma leitura confortável. Foi identificada uma extensão de 110 caracteres por linha, valor superior ao limite recomendado de 100 caracteres. (Figura 01)

  

  Figura 01 — Análise de bloco de texto da secção "Cada contribuição faz a diferença!" da página inicial na ferramenta WordCounter, com 110 caracteres por linha.

  Verificámos que, na página Objetivos, existem blocos de texto com uma largura superior à recomendada para uma leitura confortável.
  Foi identificada uma extensão de 123 caracteres por linha, valor superior ao limite recomendado de 100 caracteres.
  (Figura 02)

  

  Figura 02 — Análise de bloco de texto da página "Objetivos" na ferramenta WordCounter, com aproximadamente 123 caracteres por linha, acima do limite recomendado.

  Verificámos que, na página Termos e Condições, existem blocos de texto com uma largura superior à recomendada para uma leitura confortável.
  Foi identificada uma extensão de 154 caracteres por linha, valor superior ao limite recomendado de 100 caracteres.

  

  Figura 03 — Análise de bloco de texto da página "Termos e Condições" na ferramenta WordCounter, com aproximadamente 154 caracteres por linha.

  URLs a verificar:

  • https://associacaoincluir.pt/objetivos/- 123 caracteres.
  • https://associacaoincluir.pt/sobre-nos/#quem-somos - 118 caracteres.
  • https://associacaoincluir.pt/ - 110 caracteres.
  • https://associacaoincluir.pt/como-apoiar-a-associacao-incluir/ - 118 caracteres.
  • https://associacaoincluir.pt/contactos/ - 118 caracteres.
  • https://associacaoincluir.pt/documentos/ - 147 caracteres.
  • https://associacaoincluir.pt/termos-e-condicoes/ - 154 caracteres.
  • https://associacaoincluir.pt/politica-de-privacidade/ - 151 caracteres.

  Recomendações:

  Revisar blocos de textos para garantir que não é ultrapassado o número máximo de caracteres por linha. Recomendamos que seja definida uma largura máxima para as caixas de texto max-width, em CSS, com unidades relativas ao tamanho de fonte unidades em ou rem.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #16 O espaçamento entre linhas está abaixo do recomendado

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 2.4

  O espaçamento entre linhas não é inferior a 1.5x o tamanho da letra.
  – ver requisito 2.4 na lista Conteúdo

  Evidências:

  Verificámos que, na página Banco de Recursos para a Inclusão, existem conteúdos tabulares com tamanho de letra inferior ao recomendado. Por exemplo, na secção "Orçamento", a tabela apresenta texto com espaçamento de 15.12px para um tamanho de letra de 14.4px. (Figura 1)

  

  Figura 01 — A tabela da secção "Orçamento" apresenta texto com espaçamento de 15.12px para um tamanho de letra de 14.4px.

  Verificámos que, na janela de preferências de privacidade do website Associação Incluir, os textos descritivos das categorias de cookies apresentam um espaçamento entre linhas inferior ao recomendado.
  Foi identificado um espaçamento de 19,6px para um tamanho de letra de 14px, valor abaixo do mínimo recomendado de 21px para garantir uma leitura confortável. (Figura 02)

  

  Figura 02 — O texto descritivo das categorias de cookies apresenta um espaçamento entre linhas de 19,6px para um tamanho de letra de 14px.

  URL a verificar:

  • https://associacaoincluir.pt/banco-de-recursos-para-a-inclusao/
  • https://associacaoincluir.pt/

  Recomendações:

  Para a evidência apresentada na Figura 01, o espaçamento entre linhas deveria ser, no mínimo, de 21,6px, correspondente a 1,5 vezes o tamanho da letra identificado (14,4px).
  E para a evidência apresentada na Figura 02, o espaçamento entre linhas deveria ser, no mínimo, de 21px, correspondente a 1,5 vezes o tamanho da letra identificado (14,4px).

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #32 Falta de identificação complementar nas hiperligações

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 3.3

  As hiperligações de texto não devem ser diferenciadas apenas com base na cor.
  – ver requisito 3.3 na lista Conteúdo

  Evidências:

  Foram identificadas diversas hiperligações que dependem exclusivamente da cor para se distinguirem do restante conteúdo. Em muitos casos, o sublinhado apenas é exibido ao passar o cursor (hover), o que dificulta a identificação imediata de elementos clicáveis, especialmente para utilizadores com limitações visuais ou dificuldades de perceção de cor.

  Os links devem apresentar uma indicação visual adicional além da cor, visível de forma persistente, sem exigir interação do utilizador. A ausência dessa distinção pode comprometer a compreensão e a navegação no conteúdo.

  

  Imagem dos links do rodapé sem qualquer indicação visual de hiperligação.

  

  Imagem do link de "Políticas de Privacidade" sem identificação visual de hiperligação. Disponível em: https://associacaoincluir.pt/contactos/

  URLs a verificar:

  • https://associacaoincluir.pt/termos-e-condicoes/ - "Associação Incluir" no primeiro parágrafo
  • https://associacaoincluir.pt/documentos/ - Todos os documentos
  • https://associacaoincluir.pt/politica-de-privacidade/ - "Associação Incluir" no 1º parágrafo e "política de privacidade" no 5º parágrafo
  • https://associacaoincluir.pt/politica-de-cookies/ - várias hiperligações
  • https://associacaoincluir.pt/acessibilidade/ - várias hiperligações

  Recomendações:

  • Garantir que todas as hiperligações possuem um indicador visual persistente, como sublinhado, independentemente de hover.
  • Evitar depender exclusivamente da cor para diferenciar links do texto normal.
  • Assegurar contraste adequado entre links e texto circundante, conforme os requisitos de acessibilidade.
  • Validar que estilos de foco (focus) também são visíveis e consistentes para navegação por teclado.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #8 Páginas extensas sem índice de navegação interna entre secções

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 4.1

  Os documentos longos têm um índice no topo com hiperligações internas para o mesmo.
  – ver requisito 4.1 na lista Conteúdo

  Evidências:

  Verificámos que, na página Acessibilidade, o conteúdo se encontra organizado em várias secções e subsecções, sem que seja disponibilizado um índice de navegação no topo da página com hiperligações internas para os respetivos conteúdos.

  Esta situação dificulta a navegação e o acesso rápido às diferentes secções do documento. (Figura 01)

  

  Figura 01— A página de Acessibilidade não disponibiliza um índice de navegação para as diferentes secções do documento.

  URLs a verificar:

  • https://associacaoincluir.pt/acessibilidade/
  • https://associacaoincluir.pt/termos-e-condicoes/
  • https://associacaoincluir.pt/politica-de-privacidade/
  • http://associacaoincluir.pt/banco-de-recursos-para-a-inclusao/

  Recomendações:

  Disponibilizar um índice de navegação no início dos documentos mais extensos, contendo hiperligações internas para as principais secções e subsecções da página.
  Esta abordagem facilita a navegação, permite o acesso direto aos conteúdos pretendidos e melhora a utilização de documentos com grande volume de informação.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #9 Inconsistências de adaptação responsiva e apresentação de conteúdos em dispositivos móveis

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 4.2

  O layout do sítio Web é adaptável a plataformas móveis sem necessidade de efetuar varrimento horizontal.
  – ver requisito 4.2 na lista Conteúdo

  Evidências:

  Verificámos que, na página Banco de Recursos para a Inclusão, alguns conteúdos, como a tabela da secção "Orçamento", não se adaptam corretamente a larguras de ecrã reduzidas.

  Em dispositivos móveis, a tabela ultrapassa a área visível do ecrã, obrigando à realização de varrimento horizontal para aceder à totalidade da informação apresentada (Figura 01).

  

  Figura 01 — A tabela da secção "Orçamento" ultrapassa a largura visível do ecrã em dispositivos móveis, obrigando à realização de varrimento horizontal.

  **URL a verificar:

  • https://associacaoincluir.pt/banco-de-recursos-para-a-inclusao/

  Recomendações:

  Garantir que os conteúdos e componentes da página se adaptam corretamente a diferentes larguras de ecrã, evitando a necessidade de varrimento horizontal.
  Para tal, deverão ser adotadas soluções responsivas que permitam a visualização integral da informação em dispositivos móveis, sem comprometer a leitura e a navegação.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #7 Elementos interativos com área clicável inferior à dimensão mínima recomendada de 44px CSS

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 5.2

  Os elementos interativos têm uma dimensão mínima de 44px CSS (44 pontos), vertical e horizontal.
  – ver requisito 5.2 na lista Conteúdo

  Evidências:

  Verificámos que, no sítio Web da Associação Incluir, existem vários elementos interativos com dimensões inferiores aos 44px × 44px recomendados.

  O botão de regresso ao topo da página apresenta uma dimensão de 38,8px × 38,8px, valor inferior aos 44px × 44px recomendados para elementos interativos. (Figura 01)

  

  Figura 01 — O botão de regresso ao topo da página apresenta uma dimensão de 38,8px × 38,8px.

  Os ícones de redes sociais presentes no cabeçalho e os ícones de partilha apresentados após o vídeo possuem dimensões inferiores aos 44px × 44px recomendados para elementos interativos. Idenficiamos um tamanho de 16.33 x 17.6px. (Figura 02)

  

  Figura 02— O ícone da rede social Instagram apresenta uma dimensão aproximada de 16,3px × 17,6px.

  Foi identificada uma dimensão de 32,98px × 32,98px nos ícones de partilha, o que pode dificultar a sua utilização em dispositivos táteis. (Figura 03)

  

  Figura 03— Os ícones de partilha apresentados após o vídeo apresentam uma dimensão de 32,98px × 32,98px.

  Os controlos de navegação do carrossel de destaques apresentados em dispositivos móveis possuem uma área de ativação inferior à recomendada. Foi identificada uma largura de 20px no botão de navegação. (Figura 04).

  

  Figura 04— O botão de navegação do carrossel apresenta uma largura aproximada de 20px.

  Verificámos que, na página Minuto Solidário Montepio 2015, a ligação utilizada para navegar para o artigo anterior apresenta uma altira de 19.2px. A altura identificada encontra-se abaixo dos 44px recomendados para elementos interativos, podendo dificultar a sua utilização em dispositivos táteis. (Figura 05)

  

  Figura 05— A ligação para navegação entre artigos apresenta uma altura de 19.2px.

  URLs a verificar:

  • https://associacaoincluir.pt/
  • https://associacaoincluir.pt/minuto-solidario-montepio-2015/
  • https://associacaoincluir.pt/sou-consigo-e-faco/

  Recomendações:

  Garantir que todos os elementos interativos dispõem de uma área de ativação mínima de 44px × 44px, tanto na horizontal como na vertical.
  Para tal, deverão ser revistas as dimensões dos botões, hiperligações, ícones e restantes controlos interativos, assegurando que podem ser facilmente selecionados em diferentes dispositivos e modos de interação, em particular através de toque.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #6 Hierarquia visual insuficiente entre ações principais e elementos informativos

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 5.3

  Há apenas um botão de ação principal por página e o mesmo encontra-se destacado.
  – ver requisito 5.3 na lista Conteúdo

  Evidências:

  Verificamos que, no website Associação Incluir, as opções "Aceitar todos" e "Continuar sem aceitar" apresentadas na janela inicial de consentimento de cookies possuem o mesmo destaque visual, dificultando a identificação da ação principal (Figura 01).

  

  Figura 01 — As ações da janela de consentimento de cookies apresentam o mesmo destaque visual.

  Verificámos igualmente que, ao selecionar a opção "Definir opções de privacidade individuais", as ações "Aceitar todos", "Continuar sem aceitar" e "Guardar opções personalizadas" mantêm o mesmo destaque visual e nível hierárquico (Figura 02).

  

  Figura 02 — As ações disponíveis nas preferências de privacidade individuais apresentam o mesmo destaque visual.

  Verificámos que, no website Associação Incluir, os botões utilizados para ações principais, como o botão "Submeter" presente no formulário de contactos, apresentam o mesmo estilo visual de outros botões utilizados para navegação e acesso a conteúdos, como os botões "A Nossa História" e "Os Nossos Serviços" disponíveis na página inicial. (Figura 03)

  Esta abordagem dificulta a identificação das ações principais disponíveis nas diferentes páginas do website.

  

  Figura 03 — O botão "Submeter" apresenta o mesmo estilo visual de outros botões utilizados para navegação no website.

  URLs a verificar:

  • https://associacaoincluir.pt/
  • https://associacaoincluir.pt/contactos/
  • https://associacaoincluir.pt/minuto-solidario-montepio-2015/

  Recomendações:

  Garantir que cada página apresenta uma ação principal claramente identificável e visualmente diferenciada das restantes ações disponíveis.
  Para tal, os botões associados a ações principais deverão utilizar um estilo visual distinto, permitindo estabelecer uma hierarquia clara entre ações primárias, secundárias e elementos de navegação, facilitando a sua identificação pelos utilizadores.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #5 Elementos interativos com contraste insuficiente relativamente ao fundo

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 5.4

  Elementos gráficos interativos têm de aparentar ser clicáveis.
  – ver requisito 5.4 na lista Conteúdo

  Evidências:

  Verificámos que, na página Minuto Solidário Montepio 2015, os ícones das redes sociais apresentam um contraste insuficiente face ao fundo onde se encontram inseridos. Foi identificado um rácio de contraste de 1,81:1, valor inferior ao mínimo recomendado, dificultando a sua perceção por utilizadores com baixa visão ou dificuldades de perceção visual. (Figura 01)

  

  Figura 01— Os ícones das redes sociais apresentam um rácio de contraste de aproximadamente 1,81:1.

  Verificámos que, na página Sobre Nós, quando o menu principal é apresentado em versão móvel, o botão de pesquisa identificado pelo ícone de lupa apresenta um contraste insuficiente entre o ícone e o fundo do botão.

  Foi identificado um rácio de contraste de 1,18:1, valor inferior ao mínimo recomendado para componentes de interface, dificultando a sua identificação e utilização por utilizadores com baixa visão ou dificuldades de perceção visual. (Figura 02)

  

  Figura 02 — O ícone de pesquisa apresentado no menu principal em versão móvel possui um rácio de contraste de 1,18:1 face ao fundo do botão.

  URLs a verificar:

  • https://associacaoincluir.pt/minuto-solidario-montepio-2015/#main
  • https://associacaoincluir.pt/sou-consigo-e-faco/
  • https://associacaoincluir.pt/sobre-nos/

  Recomendações:

  Garantir que os elementos gráficos interativos e componentes de interface apresentam um contraste suficiente face ao fundo onde se encontram inseridos, permitindo a sua identificação clara por todos os utilizadores.

  Para tal, deverão ser revistas as combinações de cores utilizadas nos ícones e controlos interativos, assegurando uma diferenciação visual adequada entre os elementos e o respetivo fundo.

• evidência: issue #3 Elementos interativos sem diferenciação visual clara ou comportamento consistente de interação

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 5.4

  Elementos gráficos interativos têm de aparentar ser clicáveis.
  – ver requisito 5.4 na lista Conteúdo

  Evidências:

  Verificámos que, na página Minuto Solidário Montepio 2015, a data de publicação apresentada nos artigos pode ser selecionada como hiperligação, apesar de se apresentar visualmente como texto informativo.

  A ausência de elementos visuais que indiquem a sua interatividade dificulta a identificação desta funcionalidade pelos utilizadores. (Figura 01)

  

  Figura 01— A data de publicação do artigo apresenta-se como texto estático apesar de ser uma hiperligação.

  Verificámos que, no website Associação Incluir, diversas hiperligações são apresentadas visualmente como texto estático, sem elementos que permitam identificar claramente a sua interatividade.

  As hiperligações para as redes sociais "Facebook", "Instagram" e "YouTube", presentes no rodapé, são apresentadas visualmente como texto estático, não existindo elementos visuais que permitam identificar claramente a sua interatividade. Adicionalmente, estas hiperligações não apresentam alterações visuais significativas quando percorridas com o cursor (Figura 02).

  

  Figura 02— As hiperligações para as redes sociais no rodapé apresentam-se visualmente como texto estático.

  Verificámos igualmente que as opções "Termos e Condições", "Política de Privacidade", "Livro de Reclamações", "Livro de Elogios", "Política de Cookies" e "Acessibilidade" apresentam o mesmo comportamento, surgindo visualmente como texto comum e sem indicadores visuais que evidenciem a possibilidade de interação
  (Figura 03).

  

  Figura 03 — As hiperligações para conteúdos institucionais no rodapé apresentam-se visualmente como texto estático.

  Verificámos que, na página Documentos, as ligações para descarregamento dos documentos disponibilizados, incluindo os Estatutos, os Relatórios de Contas e o Código de Ética, são apresentadas visualmente como texto comum. A ausência de elementos visuais que permitam identificar claramente a sua interatividade dificulta a perceção de que estes conteúdos podem ser selecionados para consulta ou descarregamento. (Figura 04)

  

  Figura 04— As ligações para descarregamento de documentos apresentam-se visualmente como texto estático.

  URLs a verificar:

  • https://associacaoincluir.pt/minuto-solidario-montepio-2015/
  • https://associacaoincluir.pt/
  • https://associacaoincluir.pt/documentos/
  • https://associacaoincluir.pt/politica-de-privacidade/
  • https://associacaoincluir.pt/politica-de-cookies/
  • https://associacaoincluir.pt/acessibilidade/

  Recomendações:

  Garantir que as hiperligações e restantes elementos interativos apresentam indicadores visuais que permitam identificar de forma clara a sua interatividade.
  Para tal, deverão ser adotadas soluções visuais consistentes, como alterações de cor, sublinhado, ícones ou outros elementos distintivos, assegurando que estes componentes se diferenciam do texto estático e são facilmente reconhecidos como acionáveis pelos utilizadores.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #13 Não foram encontrados formulários com mais de 2 ecrãs no website

  etiqueta: N/Aetiqueta: chk transaçãoetiqueta: R 1.2

  Os formulários com mais de 2 ecrãs de altura devem ser distribuídos por várias páginas.
  – ver requisito 1.2 na lista Transação

  Evidências:
  Não foram encontrados formulários com mais de dois ecrãs no site Associação para a Inclusão do Cidadão com Necessidades Especiais INCLUIR. Assim, este critério é considerado "Não aplicável (N/A)".

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #14 Não foram encontrados formulários com mais de uma página

  etiqueta: N/Aetiqueta: chk transaçãoetiqueta: R 1.3

  Os formulários com mais de uma página têm a sequência de passos ilustrada.
  – ver requisito 1.3 na lista Transação

  Evidências:
  Não foram encontrados formulários com mais de uma página dentro no site Associação para a Inclusão do Cidadão com Necessidades Especiais INCLUIR. Assim, este requisito fica avaliado como "Não Aplicável" (N/A).

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #47 O tamanho dos campos não reflete o tamanho previsível dos dados

  etiqueta: NOKetiqueta: chk transaçãoetiqueta: R 2.1

  O tamanho dos campos deve refletir o tamanho previsível dos dados.
  – ver requisito 2.1 na lista Transação

  Evidências:
  O campo de pesquisa na página Política de Cookies é demasiado estreito, o que compromete a sua utilização. Este campo, colocado logo abaixo do cabeçalho de nível 2 “Que cookies são utilizados neste site?”, serve para filtrar os resultados apresentados na tabela de cookies. No entanto, quando introduzimos termos longos que constam na própria tabela de cookies — como “real_cookie_banner-consent-queue” ou “https://associacaoincluir.pt” — estes não ficam totalmente visíveis dentro do campo, devido à sua largura reduzida.

  

  Figura - Teste do campo de pesquisa, presente na página Política de Cookies, através da introdução do termo de pesquisa "real_cookie_banner-consent-queue*".

  URL a verificar:
  Página Política de Cookies

  Recomendações:
  Recomendamos reformular este campo para ser maior.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #50 Não foram identificados formulários que utilizem revelação progressiva

  etiqueta: R 2.2etiqueta: N/Aetiqueta: chk transação

  É usada revelação progressiva em vez de campos inativos.
  – ver requisito 2.2 na lista Transação

  Evidências:

  Na Associação para a Inclusão do Cidadão com Necessidades Especiais - INCLUIR, não foram encontrados campos cujo conteúdo dependente seja ocultado ou revelado automaticamente com base na ativação de um campo chave. Assim, o requisito 2.2. da Checklist de Transação é avaliado como “Não aplicável”.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #53 O texto placeholder está a substituir a label

  etiqueta: NOKetiqueta: R 2.3etiqueta: chk transação

  As legendas dos campos são breves e claras.
  – ver requisito 2.3 na lista Transação

  Notas gerais:
  Não deve ser usado o texto placeholder em substituição de uma label, porque ao escrever no campo esse texto irá desaparecer e torna a tarefa difícil para pessoas com problemas de memória ou na revisão das respostas do formulário. Para além disso, alguns leitores de ecrã podem não estar preparados para ler esse texto.

  Manter a label visível no ecrã também aumenta a área de clique, o que beneficia pessoas com dificuldades motoras ao selecionar um campo específico.

  Evidências:
  No campo de pesquisa da página Política de Cookies, o texto placeholder está a substituir a etiqueta do campo.

  

  Figura - Análise do campo de pesquisa na página Política de Cookies através do Google Inspector.

  URL a verificar:
  Página Política de Cookies

  Recomendações:
  Recomendamos a revisão dos formulários para garantir que:

  • São atribuídas legendas aos campos utilizando o elemento ;
  • O texto placeholder, quando utilizado, auxilia no preenchimento do campo em vez de substituir a legenda;
  • Caso seja usada a legenda dentro do campo, esta deve estar identificada como e não deve desaparecer quando o campo está em foco, como acontece no exemplo do Campos de formulário - Material Design e/ou Caixa de seleção - Material Design

  Para mais informações, recomendamos consultar a página sobre boas práticas nos formulários da WebAIM.

etiqueta: OK (no entanto contém 1 melhoria que se recomenda efetuar)

Lista de evidências recolhidas:

• evidência: issue #62 Não há indicação programática de que o campo é obrigatório

  etiqueta: melhoriaetiqueta: R 2.4etiqueta: chk transação

  Campos obrigatórios devem ser claramente indicados como tal.
  – ver requisito 2.4 na lista Transação

  Evidências:
  O campo “Eu concordo com o armazenamento dos meus dados de acordo com as Políticas de Privacidade.”, presente no formulário da página Contactos, inclui um asterisco *. A legenda correspondente — “* Indica um campo obrigatório” — está visível no início do formulário e é anunciada tanto na interface gráfica como pelos leitores de ecrã.

  No entanto, o campo não possui qualquer indicação programática de obrigatoriedade, ou seja, não está marcado como obrigatório no código, o que impede as tecnologias de apoio de o identificarem corretamente como tal.

  

  Figura - Análise do campo "Eu concordo com o armazenamento dos meus dados de acordo com as Políticas de Privacidade.", presente no formulário da página Contactos, através do Google Inspector.

  URL a verificar:
  Página Contactos

  Recomendações:
  Recomendamos adicionar o atributo required a todos os campos obrigatórios, para que as tecnologias de apoio os consigam identificar corretamente como campos de preenchimento obrigatório.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #4 Inexistência de ações longas

  etiqueta: N/Aetiqueta: chk transaçãoetiqueta: R 3.1

  Em ações longas, o sistema deve indicar o que está a acontecer.
  – ver requisito 3.1 na lista Transação

  Evidências:
  Na análise realizada, não foram identificadas ações longas que exijam comunicação de estado ao utilizador.
  Desta forma, considera-se que o critério é não aplicável.

etiqueta: OK (no entanto contém 1 melhoria que se recomenda efetuar)

Lista de evidências recolhidas:

• evidência: issue #10 Feedback após submissão não anunciado de forma imediata

  etiqueta: melhoriaetiqueta: chk transaçãoetiqueta: R 3.2

  Deve ser confirmado o sucesso da transação/envio de informação.
  – ver requisito 3.2 na lista Transação

  Evidências:

  Após submissão do formulário, a mensagem de confirmação é disponibilizada na página, sendo posteriormente lida pelo leitor de ecrã.

  Contudo, após a submissão, o foco é reposicionado no início da página, levando o leitor de ecrã a anunciar novamente conteúdos de navegação, menus e outros elementos da interface antes de chegar à mensagem de confirmação.
  A mensagem de sucesso apenas é anunciada após leitura de múltiplos conteúdos intermédios, não sendo apresentada de forma imediata nem contextual ao utilizador.

  Como consequência, os utilizadores de tecnologias de apoio podem não perceber imediatamente que a submissão foi concluída com sucesso, nem compreender rapidamente o estado da interface após a ação executada.

  

  Figura 1 - Mensagem de confirmação apenas anunciada após leitura integral da página

  URL a verificar:

  • https://associacaoincluir.pt/contactos/

  Recomendações:

  • Garantir que a mensagem de confirmação é anunciada imediatamente após a submissão;
  • Mover programaticamente o foco para a mensagem de feedback, quando apropriado;
  • Utilizar role="status" ou aria-live="polite" para anunciar dinamicamente o resultado da ação;
  • Garantir que o utilizador percebe imediatamente o estado da transação sem necessidade de reler toda a página;
  • Validar comportamento com leitores de ecrã.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #68 Não existem formulários que permitam ações destrutivas pelo utilizador

  etiqueta: N/Aetiqueta: chk transaçãoetiqueta: R 4.2

  As ações destrutivas nunca devem ser permanentes, deve ser sempre possível desfazer a operação.
  – ver requisito 4.2 na lista Transação

  Evidências
  Não identificámos formulários que permitem o utilizador fazer ações destrutivas e por esse motivo, consideramos esse critério como "Não aplicável".

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #66 Existem mensagens de erro ocultas das tecnologias de apoio

  etiqueta: NOKetiqueta: chk transaçãoetiqueta: R 4.3

  As mensagens de erro são claramente identificadas junto aos campos de origem.
  – ver requisito 4.3 na lista Transação

  Evidências:
  Os campos 'Nome', 'Email' e 'assunto' do formulário de Contactos apresentam mensagens de erro na sua vizinhança, mas as mesmas estão ocultas das tecnologias de apoio através do atributo aria-hidden = “true”, o que impede que os utilizadores destas tecnologias consigam percecioná-las através da navegação por elementos:

  

  Mensagem de erro do campo nome oculta para as tecnologias de apoio

  Para além disso, a mensagem no topo com a lista sumária dos erros, para além de estar visível apenas para as tecnologias de apoio, não transmite informação acerca de quais dos campos foram incorretamente preenchidos, e não direciona o foco para cada um deles.

  

  Mensagem no topo oculta visualmente e não ajudando no correto preenchimento do formulário

  Como observado na figura, a mensagem “Por favor preencha este campo.” Não indica de que campo se trata, nem permite direcionar o foco para o campo.

  Verificámos ainda que foi adicionado o atributo aria-describedby a cada campo (associação programática da mensagem de erro ao campo), o que permite que cada mensagem de erro seja anunciada ao navegar por teclado (tab e shift+tab), mas o id colocado em cada valor de aria-describedby é o da respetiva mensagem de erro presente no topo e não o da mensagem na vizinhança do campo.
  Ao serem utilizados os ids das mensagens na vizinhança dos campos nos valores dos atributos aria-describedby desses campos mantém-se a coerência de anúncio de mensagens de erro para todos os utilizadores.
  Para além disso, a existência de mensagens no topo do formulário não é obrigatório caso o formulário tenha um número reduzido de campos, mas caso exista deve ser bem construída.

  URLs a verificar:
  Contactos

  Recomendações:
  Recomendamos que sejam apresentadas mensagens de erro junto aos campos de todos os formulários, visíveis para todos os agentes, para assim fornecerem apoio na correção dos mesmos e consequente submissão correta dos formulários. No caso do formulário aqui referido basta que seja removido o atributo aria-hidden de cada mensagem de erro.
  Adicionalmente, pode existir uma lista dos erros no topo de cada formulário que consolida os vários erros existentes, em que cada mensagem deve, não só remeter para o respetivo campo (por exemplo, através da colocação da mensagem num link cujo href contenha o id do respetivo campo), mas também deve conter o descritivo do campo, de modo a que o campo a que a mensagem se refere seja percecionado sem ser necessário remeter-lhe o foco a partir da mensagem.
  Um exemplo de um item de mensagem de topo seria:

  <li><a href="#id_do_campo_nome">'Nome': por favor preencha este campo</a></li>
  

  Recomendamos ainda que os ids presentes nos atributos aria-describedby de cada campo sejam os das mensagens na vizinhança dos campos.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #69 Existem mensagens de erro que não ajudam na resolução do problema

  etiqueta: NOKetiqueta: R 4.4etiqueta: chk transação

  As mensagens de erro devem mostrar os passos concretos para a resolução dos mesmos.
  – ver requisito 4.4 na lista Transação

  Evidências:
  A mensagem de erro “Por favor digite um endereço de email.” presente no formulário de Contactos não ajuda no preenchimento do campo:

  

  Mensagem de erro que não guia o utilizador na resolução do erro
  Como observado na figura, a mensagem “Por favor digite um endereço de email.” que é apresentada quando o campo foi preenchido com um formato incorreto não indica qual o formato a ser inserido, não ajudando a preencher o campo.

  URLs a verificar:
  Contactos

  Recomendações:
  Recomendamos rever todos os formulários do website para garantir que as mensagens de erro apresentadas expliquem para o utilizador como preencher os campos corretamente.

etiqueta: OK (no entanto contém 3 melhorias que se recomenda efetuar)

Lista de evidências recolhidas:

• evidência: issue #61 Outras violações - Opção indisponível e não funcional no menu da versão mobile

  etiqueta: melhoriaetiqueta: outras violações

  Evidências:

  Verificou-se a existência de um item no menu mobile que se encontra indisponível e sem funcionalidade efetiva (Figura 1).

  

  Figura 1 – Opção não funcional no menu mobile

  Este elemento não recebe foco através de navegação por teclado nem está acessível por interação tátil. A única informação associada surge sob a forma de uma tooltip em inglês com a mensagem “WooCommerce needed”, o que pode gerar confusão para os utilizadores, especialmente por não existir contexto adicional nem ação associada. A presença de um item não interativo e sem conteúdo útil contribui para ruído informacional, prejudicando a clareza e a usabilidade do menu de navegação.


  URLs a verificar:

  • https://associacaoincluir.pt/ (Versão para dispositivos móveis)

  Recomendações:
  Recomenda-se assegurar que todos os itens presentes no menu mobile são funcionais, acessíveis e relevantes para o utilizador. Em particular:

  • Remover o item caso não exista funcionalidade ou conteúdo útil associado, evitando ruído e confusão.
  • Caso o item seja necessário, garantir que está devidamente ativo, com comportamento consistente e acessível em dispositivos móveis.
  • Eliminar ou traduzir mensagens técnicas (como “WooCommerce needed”), substituindo-as por conteúdos claros e compreensíveis para utilizadores finais.

• evidência: issue #60 Outras violações - Botão “Newsletter” não funciona na versão para dispositivos móveis

  etiqueta: melhoriaetiqueta: outras violações

  Evidências:
  Na versão mobile do website, o menu apresenta a opção “Newsletter”, porém esta funcionalidade encontra-se indisponível. (Figura 1)

  

  Figura 1 – Item não funcional no menu mobile, associado à componente da Newsletter

  Embora o botão receba foco visível quando navegado por teclado e seja clicável através de interação tátil (ou rato em simulação), a ação não produz qualquer resultado. Não ocorre redirecionamento, nem é apresentada qualquer mensagem de erro ou feedback ao utilizador após o clique, comprometendo a perceção de funcionalidade do elemento.

  URLs a verificar:

  • https://associacaoincluir.pt/#header-newsletter-signup

  Recomendações:

  • Verificar a implementação do link associado ao botão “Newsletter” na versão mobile, assegurando que o atributo href ou o evento de clique (onclick) está corretamente configurado.
  • Confirmar se não existem scripts JavaScript a impedir o comportamento esperado no contexto mobile e verificar erros de execução.
  • Garantir consistência funcional entre versões desktop e mobile, assegurando que o botão executa a mesma ação em diferentes dispositivos. (Atualmente a opção não está disponível na versão desktop)
  • Incluir feedback ao utilizador por exemplo, mensagens de erro, avisos de redirecionamento ou abertura de formulário, para evitar ambiguidades em caso de falha.
  • Testar a funcionalidade com tecnologias de apoio, assegurando conformidade com boas práticas de acessibilidade e navegação por teclado.

• evidência: issue #59 Outras violações - Há botões em inglês na versão portuguesa do website

  etiqueta: melhoriaetiqueta: outras violações

  Evidências:
  Verificámos uma inconsistência linguística, uma vez que o site está em português mas há botões e conteúdos com o textos alternativos em inglês.
  

  O website apresenta problemas de inconsistência linguística em elementos interativos como o link “Skip to content”, que indica para utilizador navegar para conteúdo principal, dificultando a compreensão para utilizadores do idioma português, língua em que o site é implementado. (Figura 1)


  

  Figura 1 - Link para “Saltar para o conteúdo principal da página” em inglês impacta na experiência com leitor de ecrã NVDA

  Verifica‑se a existência de conteúdos textuais em inglês. Esta inconsistência linguística acontece em diferentes botões do website, como o “Voltar ao topo” com title="Go to top" (Figura 2)

  

  Figura 2 - Texto alternativo do botão “voltar ao topo”, em inglês

  A mistura de idiomas pode causar confusão aos utilizadores, afetar a compreensão da informação e constituir uma barreira à acessibilidade, especialmente para pessoas com dificuldades cognitivas, utilizadores de leitores de ecrã ou cidadãos com menor proficiência em inglês. 

  URLs a verificar

  • https://associacaoincluir.pt/ - (Botão “Saltar para o conteúdo principal” e elementos interativos no menu mobile Ex: “Toggle”)
  • https://associacaoincluir.pt/acessibilidade/ - (Botão “Voltar ao topo” em todo website)

  Recomendações:

  Recomenda‑se a uniformização do idioma de todos os conteúdos apresentados na página, garantindo que o texto se encontra integralmente em português quando o idioma principal definido é PT. Deverá ser assegurado que quaisquer termos, componentes ou conteúdos sejam devidamente traduzidos e revistos, promovendo a coerência linguística, a clareza da informação.