Relatório Avaliação de Candidatura
Causa Animal de Câmara de Lobos

Introdução

O website https://causaanimal.cm-camaradelobos.pt etiqueta: não passa nos requisitos mínimos do Selo de Usabilidade e Acessibilidade.

Estado das avaliações efetuadas
Tipo de avaliaçãoEstado
Avaliação Automáticaetiqueta: NOK
Avaliação Manualetiqueta: NOK

Das avaliações manuais efetuadas obtiveram-se os resultados que se sintetizam na tabela seguinte.

Níveis de conformidade das avaliações manuais
ChecklistConformidade alcançadaResultado
10 aspetos12.5% (3/24)etiqueta: Não passa
Conteúdo23.5% (4/17)etiqueta: Não passa
Transação12.5% (1/8)etiqueta: Não passa

Nota: para passar os requisitos do Selo é necessário alcançar um nível de conformidade superior ou igual a 75% em cada uma das 3 checklists.

Avaliação automática

etiqueta: NOK

Para a produção das evidências do presente capítulo, foram utilizadas ferramentas automatizadas de avaliação de requisitos de acessibilidade de acordo com a norma WCAG 2.1 'AA'. A amostra em análise pelas ferramentas é composta pela Homepage mais todas as páginas diretamente hiperligadas por ela, pertencentes ao domínio.

Lista de evidências recolhidas:

Avaliação manual

etiqueta: NOK

A avaliação manual é feita por inspeção perícial dos diversos requisitos constantes da:

Sempre que os auditores localizam uma falha grave de um requisito de acessibilidade que, embora não faça parte do esquema de requisitos do Selo, se enquadre no âmbito das violações das WCAG 2.1 'AA' do W3C, tal referência é anotada em "Outras violações" do presente capítulo. Apesar destas violações não se apresentarem com carácter vinculativo no esquema de requisitos do Selo, recomenda-se que as mesmas sejam corrigidas.

Checklist 10 aspetos

etiqueta: NOK

Nível de conformidade:

  • Checklist 10 aspetos: 12.5% (3/24)
    • Requisitos avaliados: 27 (3 N/A excluídos, 24 aplicáveis)
    • Requisitos OK: 3
    • Requisitos NOK: 21
    • Requisitos N/A: 3

Requisito 1.1 - O menu de navegação deve estar estruturado como uma lista de opções

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #36 O menu do rodapé não está estruturado como lista

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.1

    O menu de navegação deve estar estruturado como uma lista de opções.

    Evidencias:

    As opções apresentadas no menu do rodapé estão sendo agrupadas por divs:

    Image

    Opções do menu do rodapé agrupadas por divs

    URLs a verificar:

    Recomendações:

    • Estruturar as opções do rodapé como uma lista não ordenada. Para isso, devem utilizar a semântica HTML ul li.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #38 Estado do acordeão não é anunciado pelo leitor de ecrã no menu secundário

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.2

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

    Evidencias:

    Ao navegar no menu secundário com rato ou teclado, o leitor de ecrã identifica como clicáveis apenas as opções que possuem subopções (acordeão). No entanto, o estado do acordeão (“expandido” ou “colapsado”) não é anunciado.

    Isto acontece porque o componente não utiliza o atributo aria-expanded, impedindo que o leitor de ecrã comunique corretamente o estado do acordeão ao utilizador.

    Image

    Imagem do leitor de ecrã não identificando o acordeão como expandido ou colapsado.

    Image

    Acordeão do menu secundário sem a tag aria-expanded.

    Recomendações:

    • Adicionar o atributo aria-expanded aos botões/opções do acordeão.
    • Atualizar dinamicamente o valor para true quando expandido e false quando colapsado.
    • Garantir compatibilidade com navegação por teclado e leitores de ecrã.

  • issue #37 O menu secundário e principal não estão estruturados como uma navegação de forma apropriada

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.2

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

    Evidencias:

    Verifica-se que não está a ser utilizado a tag nav no menu secundário. 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:

    Image

    Menu secundário não identificado como nav

    As opções do menu principal estão definidos como navegação. Contudo o botão "Menu" está fora da landmark nav:

    URLs a verificar

    Recomendações:

    • O menu deve ser estruturado dentro de uma tag nav. Isso inclui também o botão "Menu".

Requisito 1.3 - As imagens-link, caso existam no menu, devem ter o correspondente equivalente alternativo em texto

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #42 Ícones decorativos do menu principal possuem descrição redundante

    etiqueta: melhoriaetiqueta: chk 10 webetiqueta: R 1.3

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

    Evidencias:

    As imagens link do menu principal possuem texto alternativo e atributo title com uma descrição semelhante à já apresentada no nome do link. Além disso, os ícones SVG não estão definidos como decorativos.

    Isto faz com que leitores de ecrã anunciem informações redundantes, prejudicando a experiência de navegação.

    Image

    Imagem com título redundante.

    URL's a verificar:

    Recomendações:

    • Definir os ícones decorativos como ocultos para tecnologias de apoio.
    • Em SVGs decorativos, utilizar aria-hidden="true".
    • Remover textos alternativos e atributos title redundantes quando a descrição já estiver presente no nome do link.
    • Utilizar o atributo title apenas para fornecer informação complementar ou contextual adicional.

  • issue #41 Imagens link do menu principal não contêm texto alternativo

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.3

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

    Evidencias:

    O texto alternativo do menu principal está sendo informado pelo title. O title é utilizado para apresentar informações complementares e o nome do botão é uma informação primária que deve ser transmitida adequadamente:

    Image

    Imagem do botão do menu principal com texto alternativo inserido no title.

    URLs a verificar

    Recomendações:

    Idealmente o nome acessível do botão pode ser fornecido através de um texto dentro do próprio botão. Esse texto deve estar presente para que, além do ícone, exista uma indicação visual clara de que se trata de um botão de menu. Por exemplo:

    Menu com texto visível

    Caso optem em esconder o texto visualmente, ele deve continuar acessível para tecnologias de apoio. Para mais informações partilhamos o artigo Esconder Texto dos Utilizadores Que Usam o Sentido da Visão do site acessibilidade.gov.

Requisito 2.1 - Existe um título h1 marcado na página

etiqueta: NOK

Lista de evidências recolhidas:

Requisito 2.2 - Existe uma marcação hierarquizada de títulos e subtítulos na página (h1...h6)

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #33 Saltos na hierarquia de cabeçalhos

    etiqueta: chk 10 webetiqueta: NOKetiqueta: 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 <h4> sem existência prévia de <h3>).

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

    Image

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

    Image

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

    Image

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

    URLs a verificar:

    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.

Requisito 3.1 - As células que constituem os cabeçalhos da tabela estão marcadas com o elemento th

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #34 Não foram encontradas tabelas

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

    As células que constituem os cabeçalhos da tabela estão marcadas com o elemento <th>.
    – ver requisito 3.1 na lista 10 aspetos

    Evidências

    Não foram encontradas tabelas, tornando este critério N/A.

    Recomendações

    • Nada a acrescentar.

Requisito 3.2 - A legenda da tabela está marcada com o elemento caption

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #35 Não foram encontradas tabelas

    etiqueta: N/Aetiqueta: 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

    Não foram encontradas tabelas, tornando este critério N/A.

    Recomendações

    • Nada a acrescentar.

Requisito 4.1 - Ao clicar com o rato na etiqueta, o cursor surge no respetivo campo de edição

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #39 Existem campos de formulário sem etiquetas associadas

    etiqueta: chk 10 webetiqueta: NOKetiqueta: 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

    Nos formulários de filtro das páginas “Lista de adoção”, “Lista de adotados” e “Encontrar desaparecidos”, verificámos que os campos “Tipo” , “Género”, “Idade” e “Porte” não têm etiquetas corretamente associadas programaticamente aos respetivos controlos, o que impede, por exemplo, que o foco seja colocado no campo ao clicar na etiqueta.

    Image

    Figura 1 - Campo "Tipo” sem etiquetas associadas

    Adicionalmente, na página “Reportar desaparecido”, verificámos que os campos de descrição implementados através de textareas personalizadas não mantêm uma associação programática correta entre a etiqueta (label) e o controlo efetivamente exposto ao utilizador.

    Embora exista uma etiqueta associada ao elemento <textarea> original através dos atributos for e id, esse elemento é posteriormente ocultado (visibily:hidden) e substituído por um controlo personalizado, sem que a associação da etiqueta seja preservada no componente interativo apresentado ao utilizador.

    Image

    Figura 2 - Campo “Descrição” com editor personalizado sem associação correta da etiqueta

    URLs a verificar

    Recomendações

    Recomendamos a implementação de etiquetas associadas programaticamente a todos os campos dos formulários, seja de forma explícita (for + id) ou implícita (campo dentro do elemento <label>).

    Relativamente às comboboxes dos filtros, recomendamos uma de duas alternativas para melhoria da acessibilidade:

    • A utilização de elementos nativos (<select>), que já disponibilizam mecanismos de acessibilidade de forma nativa;
    • A reestruturação das comboboxes editáveis presentes no site, de modo a torná-las acessíveis, garantindo nome acessível, associação correta com a etiqueta e comportamento adequado por teclado e tecnologias de apoio. Para tal, podem seguir o exemplo da W3C: Editable Combobox With Both List and Inline Autocomplete.

    No caso dos campos de descrição da página “Reportar desaparecido”, recomendamos garantir que a etiqueta permanece corretamente associada ao controlo efetivamente utilizado pelo utilizador. Considerando os problemas frequentemente associados a editores personalizados, recomenda-se preferencialmente a substituição do editor atual por um elemento <textarea> nativo, preservando a associação programática com a respetiva <label> e garantindo um comportamento mais robusto para tecnologias de apoio, navegação por teclado e mecanismos nativos do navegador.

Requisito 4.2 - É possível identificar os campos de preenchimento obrigatório quando se usa apenas um leitor de ecrã

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #66 Não há informação clara sobre o que é o asterisco nos campos de preenchimento obrigatório

    etiqueta: chk 10 webetiqueta: NOKetiqueta: 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

    Os campos obrigatórios dos formulários devem estar devidamente identificados como tal. Idealmente, devem apresentar o texto “Obrigatório” à frente da legenda do campo. Pode-se colocar um * no campo obrigatório, desde que o significado do * seja mencionado no início do formulário.

    Verificámos que nos formulários "Reportar Desaparecido" e "Campanhas de Vacinação" não existe informação sobre o significado do asterisco (*) colocado à frente dos campos.

    Image

    _Figura 1 - Formulário da página Reportar Desaparecido. Não existe informação sobre o significado do asterisco (*) colocado à frente dos campos.

    URLs a verificar

    Recomendações

    Recomendamos a revisão dos formulários de forma a ser adicionada uma legenda no início do formulário a indicar claramente o significado de *.

  • issue #59 Há campos obrigatórios que não estão identificados programaticamente

    etiqueta: chk 10 webetiqueta: NOKetiqueta: 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, em alguns campos dos formulários "Reportar Desaparecido" e "Campanhas de Vacinação", existem campos de preenchimento obrigatório que não estão programaticamente definidos como tal.

    Image

    Figura 1 - Análise do campo "Confirmo que a informação aqui inserida estará visível.".

    Para além disso, existem campos em que o atributo required tem uma sintaxe incorreta (foi utilizado required = "", em vez de required ou required = "true"), para além de que não é necessário utilizar os dois atributos (required e aria-required) ao mesmo tempo.
    Acresce ainda que foram inseridos atributos aria-required = "true" em etiquetas. Atributos required ou aria-required em etiquetas não têm qualquer efeito, bem pelo contrário, são semanticamente incorretos e dificultam a manutenção do site.

    Image

    Figura 2 - Etiqueta com o atributo aria-required

    URLs a verificar

    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.
    • Também recomendamos ainda que seja verificada a sintaxe do atributo required nos elementos que já o têm, e que, no caso da existência dos atributos required e aria-required, permaneça apenas o atributo required.
    • Finalmente, recomendamos a remoção de todos os atributos required e aria-required de todas as etiquetas (<label>).

Requisito 4.3 - É possível localizar e ler as mensagens de erro usando apenas um leitor de ecrã

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #75 Existem mensagens de erro apresentadas entre a etiqueta e o campo

    etiqueta: chk 10 webetiqueta: NOKetiqueta: 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

    Foi identificado um campo de formulário cuja mensagem de erro é apresentada antes do componente visual interativo, quebrando a consistência da estrutura observada nos restantes controlos do website.

    Como consequência, a mensagem de erro surge visualmente entre a etiqueta e o campo percecionado pelo utilizador, em vez de ser apresentada após o controlo do formulário, criando inconsistência visual e podendo dificultar a compreensão da associação entre erro e campo.

    Image

    Figura 1 - Mensagem de erro apresentada a seguir à etiqueta

    URLs a verificar

    Recomendações

    • Garantir que as mensagens de erro são apresentadas após o último elemento visual do campo, mantendo a coerência com os restantes controlos do website.
    • Validar visualmente e por navegação por teclado que a ordem de leitura e apresentação do campo permanece consistente e previsível.

Requisito 5.1 - A imagem ou gráfico tem um equivalente alternativo em texto curto e correto

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #32 Imagem não decorativa com texto alternativo incorreto

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.1

    A imagem ou gráfico tem um equivalente em texto curto e correto.
    – ver requisito 5.1 na lista 10 aspetos

    Evidências

    Verifica-se que o ícone de alerta é apresentado através de um elemento gráfico (svg) sem texto alternativo. Neste caso, o ícone assinala uma mensagem de aviso relativa ao estado da candidatura e deve ser anunciado aos utilizadores de tecnologias de apoio.

    Image

    URLs a verificar

    https://causaanimal.cm-camaradelobos.pt/campanhas-de-vacinacao?freg=610

    Recomendações

    As imagens não decorativas deverão ter uma descrição breve associada, nomeadamente através do uso do atributo alt descrevendo corretamente a imagem apresentada. Por exemplo: alt="Alerta".

  • issue #9 (Melhoria) Imagens decorativas com texto alternativo indevido

    etiqueta: melhoriaetiqueta: chk 10 webetiqueta: R 5.1

    A imagem ou gráfico tem um equivalente em texto curto e correto.
    – ver requisito 5.1 na lista 10 aspetos

    Evidências

    Verifica-se que algumas imagens funcionam apenas como apoio visual, encontrando-se a informação relevante já disponibilizada através de título, descrição e links acessíveis em texto. Nestes casos, as imagens podem ser tratadas como decorativas, devendo possuir alt="".

    Image Image

    Verificado que alguns ícones com função meramente decorativa estão a ser expostos à tecnologias de apoio. Neste caso o SVG deve ser removido da árvore de acessibilidade, por exemplo com aria-hidden="true".

    Image Image

    Verificado que alguns nomes alternativos das imagens incluem caracteres especiais (como _), que estão a ser lidos pelo leitor de ecrã como "sublinhado".
    Quando a imagem não for decorativa, é recomendado que o equivalente alternativo seja apresentado em linguagem natural, sem identificadores técnicos ou caracteres desnecessários. Nesse caso, são decorativas.

    Image

    URLs a verificar

    https://causaanimal.cm-camaradelobos.pt/
    https://causaanimal.cm-camaradelobos.pt/lista-noticias
    https://causaanimal.cm-camaradelobos.pt/informacoes/legislacao
    https://causaanimal.cm-camaradelobos.pt/lista-noticias?Y2F0PTIy

    Recomendações

    • Recomenda-se que as imagens decorativas tenham alt="".
    • Quando o SVG tiver apenas finalidade visual ou decorativa, deve ser removido da árvore de acessibilidade, por exemplo com aria-hidden="true".

Requisito 5.2 - O gráfico é acompanhado de uma descrição longa

etiqueta: NOK

Lista de evidências recolhidas:

Requisito 5.3 - As imagens-link têm um equivalente alternativo correto

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #40 Imagens link com texto alternativo incorreto.

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.3

    As imagens-link têm um equivalente alternativo correto.
    – ver requisito 5.3 na lista 10 aspetos

    Evidências

    Verifica-se que a imagem do logótipo utilizada como link para a página inicial, apresenta um texto alternativo que não descreve adequadamente o seu propósito que é acesso à página inicial. Por exemplo: alt="Canil Municipal CMCL - acesso a página inicial".

    Image
    • Imagem-link da galeria
      Verifica-se que, embora o texto alternativo definido no atributo alt esteja correto, a presença simultânea de um aria-label faz com que o leitor de ecrã anuncie apenas este último, ignorando o alt. Como resultado, o texto alternativo deixa de ser efetivamente utilizado.
    Image
    • Imagem ampliada da galeria
      A imagem ampliada deve apresentar o mesmo texto alternativo da imagem-link, garantindo consistência na identificação do conteúdo visual. No entanto, nesse caso, o alt não deve incluir a indicação “abrir galeria”, uma vez que a ação já foi executada e a imagem ampliada deve apenas descrever o conteúdo efetivamente apresentado.
    Image

    URLs a verificar
    https://causaanimal.cm-camaradelobos.pt/lista-noticias (ajustar em todas as páginas que possuem galeria de imagens)
    https://causaanimal.cm-camaradelobos.pt/lista-noticias?Y2F0PTIy
    https://causaanimal.cm-camaradelobos.pt/lista-noticias/destaque/969-reuniao-entre-camara-municipal-e-arm

    Recomendações

    • O texto alternativo deve transmitir claramente o destino ou finalidade do link.
    • As imagens-link deverão ter uma descrição breve associada, nomeadamente através do uso do atributo alt descrevendo corretamente a imagem apresentada, sem identificadores técnicos ou caracteres desnecessários.
    • Quando o link direciona para um novo separador esta informação deve ser comunicada ao utilizador através do nome acessível da imagem.
    • Nas imagens da Galeria: deve ser removido o atributo aria-label da imagem-link e integrada no atributo alt a indicação da ação disponível, isto é, que a imagem permite abrir a galeria.

Requisito 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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #77 Texto normal não tem contraste suficiente

    etiqueta: chk 10 webetiqueta: NOKetiqueta: 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.

    Image

    Figura 1 - Texto com problemas de contraste .

    Image

    Figura 2 - Texto com problemas de contraste .

    URLs a verificar:

    https://causaanimal.cm-camaradelobos.pt/

    Recomendações

    • Recomendamos a revisão das cores das páginas do website nas combinações de cores utilizadas em texto normal.

Requisito 6.2 - O rácio de contraste entre a cor do texto de tamanho grande (maior ou igual que 18 pontos ou maior ou igual que 14 pontos negrito) e a cor do fundo é superior a 3:1

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #78 Textos grandes em imagens que não cumprem o rácio de contraste

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 6.2

    Evidências

    O rácio de contraste entre a cor do texto de tamanho grande (maior ou igual que 18 pontos ou maior ou igual que 14 pontos negrito) e a cor do fundo é superior a 3:1.
    – ver requisito 6.2 na lista 10 aspetos

    O contraste no texto grande (superior a 18 pontos ou superior a 14 pontos negrito) das páginas deve ser, no mínimo 3:1, para que as pessoas com baixa visão consigam ler o texto. É necessário também garantir que os textos por cima de imagens possuem contraste, principalmente quando a imagem é alterada ao longo do tempo, mas o estilo do texto mantém-se.


    Na Homepage, os textos grandes aplicados às imagens por exemplo “A decorrer para a freguesia do Jardim da Serra” apresentam problemas de contraste na combinação de cores #FFFFFF(cor de primeiro plano) e #9ECBE8(cor de plano de fundo) pois tornam os textos pouco visíveis.

    Image

    Figura 1- Textos grandes com problemas de contraste .

    Recomendações

    • Sugerimos que escureçam as imagens (do slideshow/banner por exemplo), colocando um filtro, para que o texto fique mais legível.

Requisito 7.1 - Deve ser possível ativar os botões de controlo do leitor quer com o rato quer com o teclado

etiqueta: NOK

Lista de evidências recolhidas:

Requisito 7.2 - O vídeo ou o áudio deve conter preferencialmente legendas fechadas sincronizadas. Caso não seja possível, no mínimo, deve disponibilizar-se uma transcrição textual

etiqueta: NOK

Lista de evidências recolhidas:

Requisito 8.2 - Quando se retira a CSS, a informação aparece numa ordem lógica

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #53 Botão de submissão associado ao formulário encontra-se fora do elemento

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.2

    Quando se retira a CSS, a informação aparece numa ordem lógica.
    – ver requisito 8.2 na lista 10 aspetos

    Evidências

    Na página “Reportar Desaparecido”, o botão visível utilizado para iniciar a submissão do formulário (“Reporta Desaparecido”) encontra-se programaticamente fora do elemento <form>.

    Embora exista um botão submit dentro do formulário, este encontra-se oculto (display:none), sendo a interação principal dependente de um botão externo acionado via JavaScript.

    Esta implementação pode comprometer a relação programática entre o formulário e o respetivo mecanismo de submissão, originando comportamentos inconsistentes para utilizadores de tecnologias de apoio, navegação exclusiva por teclado ou agentes que dependem da semântica HTML nativa.

    A ausência de uma associação nativa entre o botão principal e o formulário pode:

    • impedir a submissão esperada através da tecla Enter;
    • gerar inconsistências na identificação do mecanismo de submissão por tecnologias de apoio;
    • reduzir previsibilidade de interação em contextos sem JavaScript ou com suporte parcial.
    Image

    Figura 1 - Botão de submissão visualmente associado ao formulário, mas programaticamente fora do elemento <form>

    URLs a verificar

    Recomendações

    Recomendamos que o botão de submissão principal:

    • seja incluído dentro do elemento <form>; ou
    • seja explicitamente associado ao formulário através do atributo form, quando tecnicamente necessário.

    Adicionalmente, recomenda-se a utilização de um controlo nativo de submissão (type="submit") como mecanismo principal, evitando dependência exclusiva de JavaScript para operações essenciais do formulário.

  • issue #8 Formulário de pesquisa avançada exposto ao leitor de ecrã antes de estar visível em mobile

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.2

    Quando se retira a CSS, a informação aparece numa ordem lógica.
    – ver requisito 8.2 na lista 10 aspetos

    Evidências

    Na versão mobile da página observada, o formulário de “Pesquisa avançada” encontra-se visualmente oculto por defeito, sendo apresentado apenas após ativação do respetivo botão.

    No entanto, apesar de não estar visível na interface, o formulário permanece disponível na árvore de acessibilidade e pode ser imediatamente navegado por leitores de ecrã.

    Como consequência, a ordem de leitura disponibilizada às tecnologias de apoio não corresponde à sequência visual efetivamente apresentada ao utilizador, originando uma inconsistência entre a interface visível e a informação exposta programaticamente.

    Figura 1 - Formulário oculto visualmente mas disponível ao leitor de ecrã antes da ativação da pesquisa avançada

    URLs a verificar

    Recomendações

    • Garantir que o formulário permanece oculto da árvore de acessibilidade enquanto não estiver visível.
    • Utilizar mecanismos apropriados para ocultação acessível, como:
      • hidden;
      • display: none;
      • aria-hidden="true" enquanto o painel estiver fechado.
    • Atualizar corretamente os atributos de acessibilidade quando o painel é aberto ou fechado.
    • Garantir que a ordem de leitura anunciada pelos leitores de ecrã corresponde à ordem visual apresentada ao utilizador.
    • Validar o comportamento com navegação assistiva em dispositivos móveis.

Requisito 8.3 - Quando se retira a CSS, deve ser possível reconhecer a semântica dos diversos elementos

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #15 Modais sem nome acessível programaticamente determinável

    etiqueta: chk 10 webetiqueta: NOKetiqueta: 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

    Na modal observada, embora exista a utilização de role="dialog" e aria-modal="true", não existe qualquer nome acessível associado à janela.

    Não é feita associação a um título visível através de aria-labelledby, nem é fornecido um nome alternativo através de aria-label.

    Como consequência, quando a modal é aberta, os leitores de ecrã podem anunciar apenas que se trata de um diálogo, sem identificar a sua finalidade ou o contexto apresentado ao utilizador.

    Image

    Figura 1 – Modal sem nome acessível programaticamente determinável

    URLs a verificar

    Recomendações

    • Garantir que todas as modais possuem um nome acessível programaticamente determinável.
    • Associar a modal a um título visível, através de aria-labelledby.
    • Quando não existir título visível, fornecer um nome acessível através de aria-label.
    • Verificar este padrão em todas as modais do website.
    • Validar com leitores de ecrã para confirmar que, ao abrir a modal, o contexto é corretamente anunciado ao utilizador.

  • issue #14 Controlos do slider utilizam hiperligações em vez de botões e apresentam nomes acessíveis pouco descritivos

    etiqueta: chk 10 webetiqueta: NOKetiqueta: 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 os controlos de navegação do slider (“anterior” e “seguinte”) foram implementados utilizando elementos <a href="#">, apesar de representarem ações de interface e não navegação entre páginas.

    Este tipo de controlo corresponde semanticamente a uma ação sobre o conteúdo da página (alteração do slide apresentado), sendo mais apropriada a utilização de elementos <button>.

    Adicionalmente, o nome acessível dos controlos depende exclusivamente do atributo alt das imagens (alt="previous" e alt="next"), apresentando limitações:

    • os textos encontram-se em inglês num contexto de interface em português;
    • os nomes não são suficientemente descritivos do comportamento do controlo;
    • a acessibilidade do controlo fica dependente da imagem e não do próprio elemento interativo.

    A utilização de hiperligações com href="#" pode ainda originar comportamentos inesperados (ex.: deslocação da página ou alteração do foco) caso o comportamento por JavaScript falhe.

    Image

    Figura 1 - Controlos de navegação do slider implementados com elementos <a> e nome acessível dependente do atributo alt da imagem

    URLs a verificar

    Recomendações

    • Substituir os elementos <a href="#"> por elementos <button type="button">, adequados a ações de interface;
    • Garantir nomes acessíveis explícitos nos controlos através de aria-label, por exemplo:
      • aria-label="Slide anterior"
      • aria-label="Slide seguinte"
    • Tornar as imagens decorativas, utilizando alt="" e aria-hidden="true" quando o nome acessível for definido no botão;
    • Garantir coerência linguística da interface, evitando textos em inglês em controlos de navegação do site;
    • Validar o comportamento dos controlos com navegação por teclado e tecnologias de apoio.

  • issue #13 Controlos de fecho de modal/carousel implementados com elementos não semânticos

    etiqueta: chk 10 webetiqueta: NOKetiqueta: 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

    No componente de modal/carousel observado, o controlo de fecho é implementado através de um elemento genérico (<div>), utilizado para executar uma ação de interface.

    Apesar de o elemento poder ser focável e interativo através de JavaScript, não utiliza um elemento HTML semântico apropriado para ações, como <button>.

    Como consequência, a função do controlo não é corretamente transmitida de forma nativa às tecnologias de apoio, dependendo de atributos adicionais e comportamento programado para simular a sua funcionalidade.

    Image

    Figura 1 – Controlo de fecho de modal/carousel implementado com <div> em vez de <button>

    URLs a verificar

    Recomendações

    • Substituir o elemento <div> por um elemento semântico <button> para o controlo de fecho.
    • Garantir que o botão mantém toda a funcionalidade existente, incluindo:
      • ativação por teclado (Enter e Espaço);
      • foco acessível e visível;
      • comportamento consistente em diferentes tecnologias de apoio.
    • Evitar o uso de elementos genéricos para representar ações interativas em componentes de modal/carousel.
    • Validar o comportamento com navegação por teclado e leitores de ecrã para garantir que a função é corretamente anunciada e operável.

  • issue #12 Duplicação de links para o mesmo conteúdo

    etiqueta: chk 10 webetiqueta: NOKetiqueta: 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

    Em cada item da listagem, observa-se a existência de dois elementos clicáveis (<a>) com o mesmo destino:

    • Um elemento <a> que envolve a imagem (<img>)
    • Um elemento <a> que envolve o título (<h3>), funcionando como chamada principal do conteúdo

    Ambos apontam para a mesma página, resultando em redundância de navegação e aumento do número de elementos interativos.

    Image

    Figura 1 – Duplicação de links no mesmo bloco de conteúdo

    URLs a verificar

    Recomendações

    • Remover a duplicação de links com o mesmo destino dentro do mesmo bloco de conteúdo
    • Remover o link associado à imagem e manter apenas o link do título como elemento principal de navegação
    • Caso a imagem seja meramente decorativa, garantir que não constitui um elemento interativo autónomo
    • Garantir uma estrutura de navegação mais limpa e consistente para utilizadores e tecnologias de apoio

  • issue #11 Listagem de conteúdos sem estrutura semântica adequada

    etiqueta: chk 10 webetiqueta: NOKetiqueta: 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

    Na página principal, têm várias secções em que cada item é apresentado como um conjunto de conteúdos relacionados (imagem, data, título, descrição e ligação para detalhe), estruturado com múltiplos elementos <div>.

    No entanto, estes itens não estão inseridos numa estrutura semântica de lista (<ul> / <li>), apesar de representarem claramente uma listagem de conteúdos homogéneos.

    Image

    Figura 1 – Listagem de campanhas de vacinação estruturada com elementos <div> sem utilização de lista semântica

    Como consequência, as tecnologias de apoio não conseguem identificar programaticamente que estes elementos pertencem a um conjunto, nem o número total de itens existentes.

    Quando os estilos CSS são desativados, os conteúdos passam a ser apresentados como blocos isolados, sem indicação clara da relação entre si, dificultando a compreensão da estrutura da informação.

    URLs a verificar

    Recomendações

    • Deve ser verificado este padrão em todo o website.
    • Os conjuntos de conteúdos que representem listagens (ex.: documentos, notícias, resultados) devem ser estruturados semanticamente como listas (<ul> ou <ol>), com cada item representado por um <li>.
    • Cada item da lista deve agrupar toda a informação relacionada (categoria, título, descrição e ações) dentro do respetivo <li>.
    • Evitar a utilização exclusiva de elementos genéricos (<div>) para representar agrupamentos de conteúdos.
    • Validar com leitores de ecrã para garantir que o agrupamento e o número de itens são corretamente anunciados.

  • issue #10 Ausência de landmarks semânticos

    etiqueta: chk 10 webetiqueta: NOKetiqueta: 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

    Observa-se a ausência de landmarks semânticos que permitam identificar programaticamente as principais regiões da página (ex.: cabeçalho, navegação, conteúdo principal e rodapé). A estrutura da interface aparenta estar predominantemente assente em elementos genéricos (<div>), sem utilização consistente de elementos HTML semânticos ou roles equivalentes.

    A inexistência destas regiões semânticas dificulta a navegação por tecnologias de apoio, nomeadamente leitores de ecrã, impedindo os utilizadores de saltar rapidamente entre áreas relevantes da página.

    Image

    Figura 1 - Ausência de landmarks semânticos identificáveis na estrutura da página

    URLs a verificar

    Recomendações

    • Implementar landmarks semânticos para as principais regiões da página, recorrendo preferencialmente a elementos HTML nativos como <header>, <nav>, <main> e <footer>
    • Garantir a existência de uma única região principal (<main>) por página
    • Quando não for possível utilizar elementos HTML semânticos, aplicar roles ARIA equivalentes, como role="banner", role="navigation", role="main" e role="contentinfo"
    • Validar a estrutura semântica com tecnologias de apoio para confirmar que as regiões são corretamente identificadas e anunciadas ao utilizador.

    Referência: MDN – ARIA landmark roles

Requisito 9.1 - Quando a caixa de diálogo é aberta, o foco (cursor do Browser) move-se para um elemento dentro da caixa de diálogo

etiqueta: NOK

Lista de evidências recolhidas:

Requisito 9.2 - Quando uma caixa de diálogo está aberta, a navegação com teclado (Browser ou Tecnologia de apoio) tem de ficar circunscrita aos elementos que compõem a caixa de diálogo

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #45 Foco não fica limitado a caixa de diálogo

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.2

    Quando uma caixa de diálogo está aberta, a navegação com teclado (Browser ou Tecnologia de apoio) tem de ficar circunscrita aos elementos que compõem a caixa de diálogo
    – ver requisito 9.2 na lista 10 aspetos

    Evidências

    Verifica-se que, quando a janela modal está aberta, o foco do teclado e do leitor de ecrã não permanece limitado à modal, permitindo que o utilizador navegue para elementos externos à mesma.

    Image

    URLs a verificar

    https://causaanimal.cm-camaradelobos.pt/reportar-desaparecido
    https://causaanimal.cm-camaradelobos.pt/campanhas-de-vacinacao?freg=612

    Recomendações

    • Recomenda-se prender o foco do teclado dentro da dialog utilizando um script/evento no JavaScript ou na linguagem apropriada.
    • Quando o utilizador navega com TAB a partir do último elemento focável, o foco deve voltar para o primeiro elemento focável.
    • Quando o utilizador navega com SHIFT+TAB a partir do primeiro elemento focável, o foco deve mover‑se para o último elemento focável.

Requisito 9.3 - A caixa de diálogo tem de ter um mecanismo que permita sair ou fechar a caixa, quer através de teclado quer através de um dispositivo apontador

etiqueta: NOK

Lista de evidências recolhidas:

Requisito 9.4 - Quando a caixa de diálogo fecha, o foco (cursor do Browser) deve voltar ao elemento interativo que a invocou

etiqueta: NOK

Lista de evidências recolhidas:

Requisito 10.1 - Nos ficheiros PDF é possível, no mínimo, extrair o conteúdo textual para formato TXT

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #71 Não foram encontrados PDFs

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

    Nos ficheiros PDF é possível, no mínimo, extrair o conteúdo textual para formato TXT.
    – ver requisito 10.1 na lista 10 aspetos

    Evidências

    Não foram encontrados PDFs no website, tornando este critério N/A.

    Recomendações

    • Nada a acrescentar.

Checklist Conteúdo

etiqueta: NOK

Nível de conformidade:

  • Checklist Conteúdo: 23.5% (4/17)
    • Requisitos avaliados: 17 (17 aplicáveis)
    • Requisitos OK: 4
    • Requisitos NOK: 13

Requisito 1.1 - O sítio Web apresenta um resumo breve do seu propósito, visível sem se fazer scroll

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #29 Falta de resumo visível na página principal

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 1.1

    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 do website de Causa Animal da Câmara Municipal de Câmara de Lobos, não aparece presente um resumo breve do próposito do site.

    Image

    Imagem da página principal sem fazer scroll

    URL's a verificar:

    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:

    Image

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

Requisito 1.2 - Os termos mais complexos têm uma definição agregada

etiqueta: NOK

Lista de evidências recolhidas:

Requisito 1.4 - A informação sobre a entidade responsável pelo conteúdo está em todas as páginas

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #31 Informação da Entidade Responsável Não Apresentada por Extenso

    etiqueta: R 1.4etiqueta: chk conteúdoetiqueta: NOK

    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 existir no rodapé o logotipo da entidade e acesso rápido aos contactos. Observamos que o nome da entidade responsável não está disponível por extenso no texto ”Todos os direitos reservados | Canil Municipal CMCL ”.

    Image

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

    URL's a verificar:

    Recomendações:

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

    Image

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

Requisito 2.1 - O tipo de letra do corpo do documento é adequado e o tamanho da letra é, no mínimo, de 12 pontos

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #74 O corpo de texto tem um tamanho inferior a 12pt (equivalente a 16px)

    etiqueta: R 2.1etiqueta: chk conteúdoetiqueta: NOK

    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

    Evidencias:

    Na página Campanhas de Vacinação, foi identificado um tamanho de letra de 14px nas mensagens de validação do formulário, comprometendo a legibilidade da informação necessária ao correto preenchimento dos campos. (Figura 01)

    Análise do tamanho de letra das mensagens de validação do formulário através do Google Inspector

    Figura 01 — Análise do tamanho de letra das mensagens de validação do formulário Campanhas de Vacinação através do Google Inspector, com valor identificado de 14px.

    Foi igualmente identificado um tamanho de 14px no formulário Reportar desaparecido. (Figura 02)

    Análise do tamanho de letra das mensagens de validação do formulário através do Google Inspector

    Figura 02 — Análise do tamanho de letra das mensagens de validação do formulário Reportar desaparecido através do Google Inspector, com valor identificado de 14px.

    URLs a verificar:

    Recomendações:
    Recomenda-se a revisão dos tamanhos de letra utilizados nas mensagens de validação dos formulários, garantindo uma dimensão mínima equivalente a 12 pontos (16px), de forma a melhorar a legibilidade e compreensão da informação apresentada aos utilizadores.

    Sugere-se igualmente a uniformização dos tamanhos de letra aplicados às mensagens de erro e validação dos formulários, assegurando uma apresentação mais consistente e acessível em diferentes dispositivos e resoluções de ecrã.

  • issue #73 O conteúdo do site fica desformatado em resoluções mais pequenas

    etiqueta: R 2.1etiqueta: chk conteúdoetiqueta: NOK

    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

    Evidencias:

    No Website, verificamos que alguns textos descritivos associados aos blocos Adoção", “Comunicar Animal Desaparecido”, "Final Feliz para todos!" e “Campanha de Vacinação” apresentam tamanho de letra reduzido em resoluções mais pequenas, dificultando a leitura e perceção da informação apresentada em dispositivos móveis.
    (Figura 01)

    Esta situação verifica-se igualmente nas descrições dos cartões de notícias da secção “Campanhas de Vacinação”. (Figura 02)

    Textos descritivos com tamanho de letra reduzido em resoluções mais pequenas

    Figura 01 — Textos descritivos com tamanho de letra reduzido em resoluções mais pequenas.

    Descrições dos cartões de notícias com tamanho de letra reduzido em resoluções mais pequenas

    Figura 02 — Descrições dos cartões de notícias com tamanho de letra reduzido em resoluções mais pequenas.

    Verificamos que, em resoluções mais pequenas, os textos de erro dos formulários Campanhas de Vacinação e Reportar desaparecido apresentam tamanho de letra reduzido, dificultando a leitura e perceção da informação apresentada em dispositivos móveis. (Figura 03)

    Textos de erro do formulário com tamanho de letra reduzido em resoluções mais pequenas

    Figura 03 — Textos de erro do formulário Campanhas de Vacinação com tamanho de letra reduzido em resoluções mais pequenas.

    URLs a verificar:

    Recomendações:
    As páginas deverão ser revistas para garantir que todo o conteúdo se adapta a diferentes resoluções de ecrã.

Requisito 2.3 - Blocos e linhas de texto com largura não superior a 100 caracteres

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #61 Existem blocos de textos com mais de 100 caracteres por linha

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: 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 no website existem blocos de texto com largura superior ao recomendado por linha.

    Na página Campanhas de Vacinação, foi identificado um bloco de texto com 135 caracteres por linha, utilizando a ferramenta WordCounter.

    Verificou-se ainda um bloco de conteúdo com 103 caracteres por linha, nomeadamente no texto:

    • Inscrição para Reforço Vacinal: 14,00€ (Vacinação antirrábica (10,00€) + Desparasitação interna (4,00€)

    Esta situação compromete o conforto de leitura e a perceção contínua do conteúdo apresentado. (Figura 01)

    Análise de bloco de texto na ferramenta WordCounter

    Figura 01 — Análise de bloco de texto na ferramenta WordCounter com 135 caracteres.

    Na página A Nossa causa foram identificados alguns blocos de texto com mais de 100 caracteres por linha, comprometendo o conforto de leitura do conteúdo apresentado.

    Esta situação verifica-se, por exemplo, nos seguintes conteúdos:

    • Brevemente os serviços afetos à veterinária municipal estarão em funcionamento pleno e como tal o trabalho de comunicação e informação — 134 caracteres;
    • Horário: 2ªf a 6ªf das 10:00h às 20:00 / Sábados: das 09:30h às 14:00 / Domingos: das 10:00h às 12:00 — 101 caracteres.
    • A Câmara Municipal de Câmara de Lobos dispõe de um protocolo com a SPAD - Sociedade Protetora de Animais Domésticos para a gestão dos — 133 caracteres; (Figura 02)
    Análise de bloco de texto na ferramenta WordCounter

    Figura 02 — Análise de bloco de texto na ferramenta WordCounter com 134 caracteres.

    URLs a verificar:

    Recomendações:
    Recomenda-se a revisão dos blocos de texto do website, de forma a evitar linhas excessivamente longas e garantir uma leitura mais confortável dos conteúdos.

    Sugere-se ainda a definição de uma largura máxima para os blocos de texto através de CSS max-width, utilizando unidades relativas ao tamanho da fonte, como em ou rem.

Requisito 2.4 - O espaçamento entre linhas não é inferior a 1.5x o tamanho da letra

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #62 O espaçamento entre linhas está abaixo do recomendado

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: 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:

    Verificou-se que, no website, o bloco de texto das descrições das notícias apresenta espaçamento entre linhas inferior ao recomendado relativamente ao tamanho da letra utilizado.

    Foi identificado um espaçamento entre linhas de 24.28px para um tamanho de letra de 17px, abaixo da proporção mínima recomendada de 1.5x relativamente ao tamanho da fonte. (Figura 01)

    Análise do espaçamento entre linhas das descrições das notícias através do Google Inspector

    Figura 01 — Análise do espaçamento entre linhas das descrições das notícias através do Google Inspector, com valor identificado de 24.28px para um tamanho de letra de 17px.

    Na página Campanhas de Vacinação, verificaram-se blocos de texto com espaçamento entre linhas inferior ao recomendado relativamente ao tamanho da letra utilizado.

    Foi identificado um espaçamento entre linhas de 24.28px para um tamanho de letra de 17px, abaixo da proporção mínima recomendada de 1.5x relativamente ao tamanho da fonte. (Figura 02)

    Análise do espaçamento entre linhas através do Google Inspector

    Figura 02 — Análise do espaçamento entre linhas através do Google Inspector, com valor identificado de 24.28px para um tamanho de letra de 17px.

    URLs a verificar:

    Recomendações:
    Para as evidências apresentadas, o espaçamento entre linhas deverá respeitar a proporção mínima recomendada de 1.5x relativamente ao tamanho da letra utilizado.

    Nos casos identificados nas figuras 01 e 02, para um tamanho de letra de 17px, o espaçamento entre linhas deverá ser, no mínimo, de 25.5px.

    Recomenda-se igualmente a revisão dos blocos de texto em todo o website, garantindo a aplicação consistente do espaçamento mínimo recomendado para melhorar o conforto e fluidez da leitura.

Requisito 3.2 - A navegação principal está sempre visível e sempre no mesmo local

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #52 Menu secundário sem identificação consistente de navegação

    etiqueta: melhoriaetiqueta: chk conteúdoetiqueta: R 3.2

    A navegação principal está sempre visível e sempre no mesmo local.
    – ver requisito 3.2 na lista Conteúdo

    Evidências:

    O menu secundário encontra-se disponível apenas em algumas páginas, estando ausente nas páginas "Encontrar Desaparecidos", "Comunicar Desaparecidos", "Notícias" e "Documentos", o que gera inconsistência na navegação.

    Adicionalmente, verifica-se um problema de nomenclatura na opção "Documentos", uma vez que esta redireciona para uma página intitulada "Legislação". Esta discrepância entre o nome do menu e o título da página pode causar desorientação ao utilizador quanto à sua localização no sítio web (ver Figura 1).

    Image

    Figura 01: Página sem menu secundário presente.

    Além disso, na página “Campanhas de vacinação”, a página atual não é identificada no menu secundário (Ver figura 02).

    Image

    Figura 02: A página de "Campanhas de Vacinação" não é identificado como página atual no menu secundário.

    Foi também verificado que as páginas presentes no menu principal não utilizam o atributo aria-current para indicar a página ativa, dificultando a identificação do contexto atual por utilizadores de tecnologias de apoio (Ver figura 03).

    Image

    Figura 03: Opções do menu principal não contêm o atributo aria-current.

    URL's a verificar:

    Recomendações:

    • Garantir consistência na apresentação do menu secundário entre páginas relacionadas.
    • Identificar visualmente e semanticamente a página atual nos menus de navegação.
    • Utilizar o atributo aria-current="page" no item correspondente à página ativa, tanto no menu principal como no menu secundário.

  • issue #49 A navegação principal do site está colapsada em desktop

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 3.2

    A navegação principal está sempre visível e sempre no mesmo local.
    – ver requisito 3.2 na lista Conteúdo

    Evidências:

    No caso de breakpoints superiores, normalmente considerados para desktop, devem estar imediatamente visíveis no ecrã pelo menos as opções de 1º nível porque, à partida, existe espaço para tal.

    No caso de breakpoints inferiores, normalmente considerados para tablet e mobile, o menu pode manter-se colapsado.
    Independentemente da página, o menu deve estar sempre posicionado no mesmo local.

    Em breakpoints superiores, o menu principal do site está colapsado e só é possível expandi-lo a partir do botão “Menu hambúrguer” (ver Figura 01). Por isso, as opções de primeiro nível não são imediatamente visíveis para os utilizadores.

    Image

    Figura 01: Imagem da página inicial com o menu principal colapsado no topo direito.

    URL's a verificar:

    Recomendações:

    Em breakpoints superiores, as opções de 1º nível do menu devem estar sempre visíveis na página enquanto existir espaço.

    Adicionalmente, recomenda-se alinhar a nomenclatura entre ambos os menus, ajustando as opções do menu principal, ou, em alternativa, remover as opções da barra superior.

Requisito 3.3 - As hiperligações de texto não devem ser diferenciadas apenas com base na cor

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #55 Falta de identificação complementar nas hiperligações

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: 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:

    Foi identificado um problema de acessibilidade relacionado com a identificação visual de links no website. Atualmente, existem situações em que os links não estão devidamente diferenciados do texto normal, sendo identificáveis apenas através da cor ou de interação (hover), o que não cumpre as boas práticas de acessibilidade. Segue em seguida alguns exemplos encontrados:

    Image

    Imagem dos títulos de notícias com hiperligações sem indicação visual complementar.

    Image

    Imagem de hiperligações do menu do rodapé sem indicação visual.

    URL's a verificar:

    Recomendações:

    Garantir que todos os links:

    • Sejam visualmente distinguíveis do texto normal sem depender exclusivamente da cor;
    • Incluam sublinhado ou outro indicador visual consistente;
    • Mantenham consistência em todos os estados (normal, hover, focus).
    • Rever o estado de hover das hiperligações no rodapé com problemas de contraste (Ver Requisito 6.1)

Requisito 4.1 - Os documentos longos têm um índice no topo com hiperligações internas para o mesmo

etiqueta: NOK

Lista de evidências recolhidas:

Requisito 4.2 - O layout do sítio Web é adaptável a plataformas móveis sem necessidade de efetuar varrimento horizontal

etiqueta: NOK

Lista de evidências recolhidas:

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

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: 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:

    Verificamos que, em alguns dispositivos móveis, a secção de destaques da página inicial Home - Causa Animal apresenta os ícones interativos desalinhados, verificando-se também a ocultação da imagem central utilizada na composição do layout.

    Esta situação afeta a distribuição e perceção dos elementos interativos. (Figura 01)

    Problemas de alinhamento e visibilidade em dispositivos móveis

    Figura 01 — Problemas de alinhamento e visibilidade na secção de destaques em dispositivos móveis.

    Verificamos que, em dispositivos móveis, o menu principal da página A nossa causa apresenta problemas de organização e sobreposição de conteúdos na área inferior dos acessos rápidos.

    Esta situação dificulta a leitura e perceção dos elementos apresentados. (Figura 02)

    Menu principal em dispositivos móveis com problemas de organização e sobreposição de conteúdos

    Figura 02 — Menu principal em dispositivos móveis com problemas de organização e sobreposição de conteúdos nos acessos rápidos.

    URLs a verificar:

    Recomendações:
    Recomenda-se a adaptação da secção de destaques para diferentes larguras de ecrã, garantindo uma distribuição consistente dos elementos interativos e evitando problemas de alinhamento ou ocultação de conteúdos em dispositivos móveis.

Requisito 5.2 - Os elementos interativos têm uma dimensão mínima de 44px CSS (44 pontos) (vertical e horizontal)

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #21 Elementos interativos com área clicável inferior à dimensão mínima recomendada

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: 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:

    Verificamos que na página inicial Home - Causa Animal o botão de abertura do menu principal apresenta uma área acionável com dimensão inferior aos 44px CSS recomendados, apresentando 33.75px de altura.

    Esta situação pode dificultar a interação em dispositivos táteis, especialmente para utilizadores com menor precisão no toque.
    (Figura 01).

    Botão do menu principal com dimensão inferior ao recomendado

    Figura 01 — Botão do menu principal com dimensão inferior ao recomendado.

    Verificamos que, no formulário da página Campanhas de vacinação, os radio buttons do campo “Serviço pedido”, nomeadamente “Primeira vez” e “Reforço vacinal”, apresentam 24.27px de altura, abaixo da dimensão mínima recomendada de 44px CSS.

    Esta situação pode dificultar a interação em dispositivos táteis. (Figura 02)

    Radio buttons com dimensão inferior ao recomendado

    Figura 02 — Radio buttons do campo “Serviço pedido” com dimensão inferior ao recomendado.

    URLs a verificar:

    Recomendações:
    Recomenda-se o aumento da área acionável dos elementos interativos, garantindo uma dimensão mínima de 44x44px CSS, de forma a melhorar a interação em dispositivos táteis.

Requisito 5.3 - Há apenas um botão de ação principal por página e o mesmo encontra-se destacado

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #22 Hierarquia visual insuficiente entre ações principais e elementos informativos

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: 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, na página Legislação, o botão “Limpar filtro” não apresenta o destaque visual esperado para a ação principal da área de filtros, sendo apresentado visualmente como texto simples, enquanto o botão secundário “Voltar atrás” surge com maior evidência visual.

    Os botões secundários deverão apresentar menor destaque visual relativamente às ações principais.

    Esta situação dificulta a identificação da ação principal disponível. (Figura 01).

    Botão principal com reduzido destaque visual

    Figura 01 — Botão “Limpar filtro” sem indicação visual clara de interatividade.

    URL a verificar:

    Recomendações:
    Recomenda-se a criação de uma hierarquia visual mais clara entre ações principais e secundárias, garantindo maior destaque visual para os botões de ação principal relativamente aos restantes elementos interativos.

Requisito 5.4 - Elementos gráficos interativos têm de aparentar ser clicáveis

etiqueta: NOK

Lista de evidências recolhidas:

Checklist Transação

etiqueta: NOK

Nível de conformidade:

  • Checklist Transação: 12.5% (1/8)
    • Requisitos avaliados: 13 (5 N/A excluídos, 8 aplicáveis)
    • Requisitos OK: 1
    • Requisitos NOK: 7
    • Requisitos N/A: 5

Requisito 1.1 - A sequência de tabulação entre campos segue a sequência de preenchimento

etiqueta: NOK

Lista de evidências recolhidas:

Requisito 1.2 - Os formulários com mais de 2 ecrãs de altura devem ser distribuídos por várias páginas

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #69 Não foram encontrados formulários com mais de 2 ecrãs no website

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

    Evidências

    Evidências:
    Não foram encontrados formulários no site Causa Animal de Câmara de Lobos com mais de dois ecrãs. Assim, este critério é considerado "Não aplicável (N/A)".

Requisito 1.3 - Os formulários com mais de uma página têm a sequência de passos ilustrada

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #70 Não foram encontrados formulários com mais de uma página

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

    Evidências

    Evidências:
    Não foram encontrados formulários com mais de uma página dentro do site Causa Animal de Câmara de Lobos. Assim, este requisito fica avaliado como "Não Aplicável".

Requisito 2.1 - O tamanho dos campos deve refletir o tamanho previsível dos dados

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #80 O tamanho dos campos não reflete o tamanho previsível dos dados

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

    Evidências

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

    Verificámos que na página Reportar Desaparecido e Campanhas de Vacinação, grande parte dos campos do formulário são demasiado largos para a informação a inserir.

    Por exemplo: o número de CC é constituído por 8 dígitos, no entanto é possível inserir mais de 50 carateres no campo.

    Image

    Figura 1 - Formulário da página Reportar Desaparecido .

    Image

    Figura 2 - Formulário da página Campanhas de Vacinação .

    URLs a verificar:

    https://causaanimal.cm-camaradelobos.pt/reportar-desaparecido - Campos a verificar:

    • "Tipo de Animal"
    • "Identificação do animal – SIAC"
    • "Idade"
    • "Género"
    • "Cor"
    • "Porte"
    • " Cor da coleira"
    • " Data de desaparecimento"
    • "Nome"
    • "Email (não será público)"
    • " NIF (não será público)"
    • "Telefone".

    https://causaanimal.cm-camaradelobos.pt/campanhas-de-vacinacao?freg=612 - Campos a verificar:

    • "Nome tutor completo"
    • "Documento de identificação" (tanto o nº como a validade)
    • " Identificação do animal – SIAC (15 números)"
    • "Data nascimento do animal"
    • "Nome do animal".

    Recomendações

    • Recomendamos a revisão dos campos dos formulários de forma a garantir que os campos de input tenham uma largura proporcional ao tipo de informação a inserir.

Requisito 2.2 - É usada revelação progressiva em vez de campos inativos

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #67 Não foram identificados formulários que utilizem revelação progressiva

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

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

    Evidências

    No site Causa Animal da Câmara de Lobos, 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”.

    Recomendações

    N/A

Requisito 2.3 - As legendas dos campos são breves e claras

etiqueta: NOK

Lista de evidências recolhidas:

Requisito 2.4 - Campos obrigatórios devem ser claramente indicados como tal

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #25 Não há informação clara sobre o que é o asterisco nos campos de preenchimento obrigatório

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

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

    Evidências:

    Os campos obrigatórios dos formulários devem estar devidamente identificados como tal. Idealmente, devem apresentar o texto “Obrigatório” à frente da legenda do campo. Pode-se colocar um * no campo obrigatório, desde que o significado do * seja mencionado no início do formulário.

    Verificamos que na página Campanhas de vacinação não existe informação que explique o significado do asterisco (*) utilizado nos campos obrigatórios do formulário. (Figura 01)

    Campos obrigatórios sem explicação do asterisco

    Figura 01 - Formulário da página Campanhas de Vacinação. Não existe informação sobre o significado do asterisco (*) colocado à frente dos campos.

    URL a verificar:

    Recomendações:
    Recomenda-se a revisão dos formulários, garantindo a apresentação de uma indicação clara sobre o significado do símbolo (*) utilizado nos campos obrigatórios, preferencialmente no início do formulário.

  • issue #18 Há campos obrigatórios que não estão identificados programaticamente

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

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

    Evidências:

    Verificámos que, na página Campanhas de Vacinação, os campos obrigatórios das secções “Documento de identificação” e “Serviço pedido”, nomeadamente “CC/BI”, “Passaporte”, “Primeira vez” e “Reforço vacinal”, bem como os campos “Documento de identificação”, “Tipo de animal”, “Serviço", "pedido” e "Confirmo que a informação aqui inserida estará visível", não se encontram programaticamente identificados como obrigatórios através dos atributos required ou aria-required.

    Esta situação pode dificultar a identificação correta dos campos obrigatórios por tecnologias de apoio. (Figura 01 e Figura 02).

    Análise dos campos CC/BI e Passaporte através do Google Inspector

    Figura 01 — Análise dos campos “CC/BI” e “Passaporte”, da secção “Documento de identificação” da página Campanhas de Vacinação, através do Google Inspector.

    Análise dos campos Primeira vez e Reforço vacinal através do Google Inspector

    Figura 02 — Análise dos campos “Primeira vez” e “Reforço vacinal”, da secção “Serviço pedido” da página Campanhas de Vacinação, através do Google Inspector.

    URL a verificar:

    https://causaanimal.cm-camaradelobos.pt/reportar-desaparecido

    Campos

    • Descrição
    • Tipo animal
    • Serviço pedido

    Recomendações:
    Recomendamos que todos os campos obrigatórios dos formulários sejam identificados programaticamente através dos atributos adequados, comorequired ou aria-required="true", garantindo que essa informação é corretamente transmitida às tecnologias de apoio e validada de forma consistente pelos navegadores.

Requisito 3.1 - Em ações longas, o sistema deve indicar o que está a acontecer

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #3 Inexistência de ações longas

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

    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.

    Recomendações
    N/A

Requisito 3.2 - Deve ser confirmado o sucesso da transação/envio de informação

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #4 Feedback após submissão não acessível

    etiqueta: chk transaçãoetiqueta: NOKetiqueta: 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 feedback não é anunciada por leitores de ecrã
    • Não existe uso de aria-live, role="alert" ou role="status"
    • O foco não é movido para a mensagem
    • A mensagem não é alcançável por navegação por teclado
    • O utilizador pode permanecer no formulário sem perceber que a ação foi concluída

    Este comportamento compromete a compreensão do estado da interface.

    Image

    Figura 1 – Mensagem de feedback não anunciada nem acessível por teclado

    URL a verificar

    Recomendações

    • Garantir que todas as ações apresentam feedback claro e acessível
    • Utilizar aria-live="polite" ou role="status" para mensagens dinâmicas
    • Mover o foco para a mensagem de sucesso/erro após submissão
    • Assegurar que o feedback é navegável por teclado
    • Garantir que mensagens são visíveis e persistentes
    • Validar com leitores de ecrã e navegação por teclado

Requisito 4.2 - As ações destrutivas nunca devem ser permanentes; deve ser sempre possível desfazer a operação

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #54 Não existem formulários que permitam ações destrutivas pelo utilizador

    etiqueta: chk transaçãoetiqueta: N/Aetiqueta: 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 identificamos formulários que permitem o utilizador fazer ações destrutivas e por esse motivo, consideramos esse critério como "Não aplicável".

    Recomendações

    N/A

Requisito 4.3 - As mensagens de erro são claramente identificadas junto aos campos de origem

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #81 Existem mensagens de erro apresentadas entre a etiqueta e o campo

    etiqueta: chk transaçãoetiqueta: NOKetiqueta: 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

    Foi identificado um campo de formulário cuja mensagem de erro é apresentada antes do componente visual interativo, quebrando a consistência da estrutura observada nos restantes controlos do website.

    Como consequência, a mensagem de erro surge visualmente entre a etiqueta e o campo percecionado pelo utilizador, em vez de ser apresentada após o controlo do formulário, criando inconsistência visual e podendo dificultar a compreensão da associação entre erro e campo.

    Image

    Figura 1 - Mensagem de erro apresentada a seguir à etiqueta

    URLs a verificar

    Recomendações

    • Garantir que as mensagens de erro são apresentadas após o último elemento visual do campo, mantendo a coerência com os restantes controlos do website.
    • Validar visualmente e por navegação por teclado que a ordem de leitura e apresentação do campo permanece consistente e previsível.

  • issue #76 Existem mensagens não associadas programaticamente aos campos

    etiqueta: chk transaçãoetiqueta: NOKetiqueta: 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

    Foi identificado uma checkbox obrigatória cuja mensagem de erro não está programaticamente associada ao campo interativo.

    No caso observado, a mensagem “Campo de preenchimento obrigatório.” existe visualmente, mas encontra-se associada a um campo oculto (input type="hidden") em vez do checkbox (veracidadeCheck) com o qual o utilizador interage.

    Como consequência, leitores de ecrã podem não anunciar a mensagem de erro ao navegar para o checkbox, dificultando a identificação do problema por utilizadores de tecnologias de apoio.

    Image

    Figura 1 - Checkbox sem mensagem de erro programaticamente associada

    URLs a verificar

    Recomendações

    • Associar a mensagem de erro diretamente ao checkbox através de aria-describedby.
    • Evitar associar mensagens de erro a campos ocultos (input type="hidden").
    • Validar com leitor de ecrã para confirmar que a mensagem é anunciada ao focar o checkbox.

Requisito 4.4 - As mensagens de erro devem mostrar os passos concretos para a resolução dos mesmos

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #79 Existem mensagens de erro que não ajudam na resolução do problema

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

    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, introduza um endereço eletrónico válido.” presente nos formulários da páginas "Reportar Desaparecido" e "Campanhas de Vacinação" não ajuda no preenchimento do campo:

    Image

    Figura 1 - Mensagem de erro que não guia o utilizador na resolução do erro

    Como observado na figura, a mensagem “Por favor, introduza um endereço eletrónico válido.” 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

    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.

Outras violações

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

Lista de evidências recolhidas:

  • issue #72 Outras violações - O menu não está responsivo

    etiqueta: melhoriaetiqueta: outras violações

    Evidências
    Quando abrimos o menu em resoluções menores, como no mobile, verifica‑se que as opções ficam sobrepostas devido ao espaço reduzido do ecrã, o que prejudica a leitura e dificulta a seleção correta de uma opção:

    URLs a verificar

    Recomendações

    • Devem garantir que o conteúdo seja responsivo e se adapte aos diferentes tamanhos de ecrã. As opções não devem ser sobrepostas.

  • issue #68 Outras violações - Existem filtros que não retornam conteúdo, e essa situação não é comunicada ao utilizador

    etiqueta: melhoriaetiqueta: outras violações

    Evidências
    Quando realizamos uma consulta no filtro de legislação, é possível verificar que, em determinadas combinações, não é retornado qualquer conteúdo. Contudo, em vez de ser apresentada uma mensagem a informar que não existem resultados para a pesquisa, é exibida uma imagem decorativa.

    Para além de não transmitir informação útil, esta imagem reage ao movimento do rato, o que induz o utilizador a pensar que se trata de um elemento interativo ou clicável, quando na realidade não possui qualquer funcionalidade.

    URLs a verificar

    Recomendações

    • Substituir a imagem decorativa apresentada por uma mensagem em texto acessível também para as tecnologias de apoio, informando o utilizador de que o filtro não devolveu conteúdos.

  • issue #51 Outras violações - O website não utiliza landmarks de forma apropriada

    etiqueta: melhoriaetiqueta: outras violações

    Evidências
    Verifica-se que no website não existem landmarks. O uso de landmarks permite identificar regiões específicas na página e facilitam o entendimento da estrutura do website para pessoas que utilizam tecnologias de apoio:

    Não é possível identificar o main e o footer

    URLs a verificar

    Recomendações
    Recomendamos a revisão geral do website, de forma a garantir que todas as páginas incluam corretamente as landmarks estruturais — nomeadamente o footer e, em particular, a main. Não deverá existir conteúdos estruturados fora das landmarks.

  • issue #50 Outras violações - Link de saltar para conteúdo principal

    etiqueta: melhoriaetiqueta: outras violações

    Evidências
    Verifica-se que o website possui o link “Ir para conteúdo”, cuja finalidade é permitir aos utilizadores contornar blocos repetitivos de navegação e aceder diretamente à área principal do conteúdo.

    No entanto, este link apresenta problemas:

    • Não é apresentado de forma visível quando está em foco, o que dificulta a localização quando é feito pelo teclado.
    • Quando selecionamos o link com o leitor de ecrã, está sendo direcionado para o h1 ao invés do conteúdo principal main.

    URLs a verificar

    Recomendações

    • O link deve ser visualmente perceptível, apresentando-se como um link a. Devem garantir que o contraste esteja acima do recomendado.
    • Idealmente ele deveria estar sempre visível no ecrã, no entanto, pode ser visível apenas quando recebe foco por teclado ou leitor de ecrã.
    • Estruturalmente deve ser posicionado no início da página como o primeiro elemento interativo.
    • O atributo href do link deve conter o id do respectivo main da página. É necessário garantir que as landmarks estejam incluídas apropriadamente no website. Por isso recomendamos analisarem em conjunto com o critério #51 .

  • issue #43 Outras violações - O link associado à imagem direciona para a página incorreta.

    etiqueta: melhoriaetiqueta: outras violações

    Evidências

    Identificou‑se que o link associado à imagem-link na sessão Animais desaparecidos encaminha o utilizador para a página inicial, em vez de o dirigir para a página específica com informação sobre os animais desaparecidos.

    Image

    URLs a verificar

    Recomendações

    • Recomenda‑se corrigir o URL para apontar para o destino correto.

Significado das etiquetas utilizadas