Relatório Avaliação de Candidatura
Informa Machico

Introdução

O website https://informa.cm-machico.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 aspetos34.6% (9/26)etiqueta: Não passa
Conteúdo29.4% (5/17)etiqueta: Não passa
Transação33.3% (3/9)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: 34.6% (9/26)
    • Requisitos avaliados: 27 (1 N/A excluído, 26 aplicáveis)
    • Requisitos OK: 9
    • Requisitos NOK: 17
    • Requisitos N/A: 1

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 #72 Comportamento inconsistente do menu quando ativado através da tecla Enter

    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.

    Evidências:

    Ao navegar utilizando apenas o teclado, foi verificado que a tecla Enter não produz um comportamento consistente na abertura do menu.

    Em determinadas páginas, ao pressionar Enter sobre o botão do menu, o utilizador é redirecionado para a página de pesquisa em vez de abrir o menu. Já nas páginas de notícias, a mesma ação não produz qualquer resultado, não ocorrendo nem a abertura do menu nem qualquer outra resposta da interface.

    Por outro lado, quando o controlo é ativado através da tecla Espaço, o menu é aberto corretamente. O problema também não se verifica durante a utilização de leitores de ecrã.

    Esta inconsistência pode causar confusão aos utilizadores de teclado, uma vez que a mesma funcionalidade apresenta comportamentos diferentes consoante a página em que se encontra e a tecla utilizada para a ativação.

    Image

    Página que é redirecionado ao clicar o botão do menu com o Enter

    Image

    Menu sendo aberto corretamente ao se utilizar o Espaço.

    URLs a verificar:

    Recomendações:

    • Rever a implementação do script responsável pela abertura do menu.
    • Validar o tratamento dos eventos de teclado associados às teclas Enter e Espaço, garantindo que ambas executam a mesma ação quando aplicável.
    • Corrigir a associação incorreta da tecla Enter que está a provocar o redirecionamento para a página de pesquisa.
    • Garantir que a ativação do menu apresenta um comportamento consistente independentemente do método de interação utilizado.

  • issue #69 Estado do menu não é comunicado aos leitores de ecrã

    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.

    Evidências:

    Ao interagir com o botão de abrir e fechar o menu, o leitor de ecrã não anuncia se o menu se encontra expandido ou colapsado.

    Embora o estado visual do menu seja alterado, essa informação não é transmitida às tecnologias de apoio. Como consequência, os utilizadores de leitores de ecrã não conseguem perceber se a ação executada resultou na abertura ou no fecho do menu, nem qual o estado atual do componente.

    Esta situação dificulta a compreensão e utilização da navegação, especialmente em interfaces que dependem de menus expansíveis.

    Image

    Imagem do menu sendo aberto e colapsado com o leitor de ecrã.

    URLs a verificar:

    Recomendações:

    • Implementar o atributo aria-expanded no botão que controla a abertura e fecho do menu.
    • Atualizar dinamicamente o valor de aria-expanded para true quando o menu estiver aberto e para false quando estiver fechado.
    • Garantir que o estado anunciado pelas tecnologias de apoio corresponde ao estado visual do menu.

  • issue #68 O menu principal não está estruturado 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.

    Evidências:

    Foi verificado que as opções do menu estão corretamente incluídas numa região de navegação (<nav>). No entanto, o botão utilizado para abrir e fechar o menu encontra-se fora dessa mesma região.

    Como consequência, os utilizadores de leitores de ecrã que utilizam mecanismos de navegação por regiões não conseguem aceder diretamente ao controlo responsável pela abertura do menu quando saltam para a área de navegação. Isto quebra a relação entre o controlo e o conteúdo que este gere, dificultando a compreensão e utilização da navegação.

    URLs a verificar:

    Recomendações:

    • Incluir o botão de abrir e fechar o menu dentro da respetiva região de navegação (<nav>) em todos os breakpoints.
    • Garantir que todos os elementos relacionados com a navegação, incluindo os controlos que a expandem ou recolhem, fazem parte da mesma estrutura semântica.
    • Assegurar que os utilizadores de tecnologias de apoio conseguem aceder diretamente ao botão ao navegar entre regiões de navegação.

  • issue #67 Menu sem indicação visual de foco durante a navegação por teclado

    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.

    Evidências:

    Ao navegar pelo menu utilizando apenas o teclado (Tab e Shift + Tab), não existe uma indicação visual clara que permita identificar qual a opção que se encontra atualmente em foco.

    Foi ainda verificado que a primeira opção do menu permanece visualmente destacada, mesmo quando o utilizador se encontra noutra página ou quando o foco está posicionado noutra opção de navegação. Desta forma, o destaque apresentado não corresponde nem à localização atual do utilizador nem ao elemento que está efetivamente selecionado durante a navegação por teclado.

    A ausência de um indicador de foco visível dificulta a utilização do website por pessoas que dependem exclusivamente do teclado, uma vez que não conseguem determinar qual o elemento que será ativado ao pressionar Enter.

    Image

    URLs a verificar:

    Recomendações:

    • Garantir que todos os elementos interativos do menu apresentam um indicador visual de foco claro e facilmente percetível.
    • Assegurar que o foco visual acompanha corretamente a navegação realizada através de Tab e Shift + Tab.
    • Diferenciar visualmente o estado de foco do estado de página ativa, evitando que ambos sejam confundidos.
    • Garantir que o destaque apresentado corresponde sempre ao elemento atualmente focado ou à página em que o utilizador se encontra.
    • Garantir que este problema seja corrigido juntamente com a issue #65.

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 #70 Nome acessível do botão do menu não reflete a ação disponível

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.3

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

    Evidências:

    Foi verificado que o botão utilizado para abrir e fechar o menu possui sempre o mesmo nome acessível, "Menu", independentemente do estado em que se encontra.

    Quando o menu está fechado, o nome não indica que a ação disponível é abrir o menu. Da mesma forma, quando o menu está aberto, o nome continua a ser anunciado como "Menu", sem indicar que a ação disponível é fechar o menu.

    Esta situação pode dificultar a compreensão da funcionalidade do botão por utilizadores de tecnologias de apoio, uma vez que o nome acessível não descreve claramente a ação que será executada.

    Image

    Imagem do leitor de ecrã anunciando o botão do menu como "Menu" independente do seu estado.

    Image

    Imagem do botão do menu na versão mobile apenas com o título="Menu"

    URLs a verificar:

    Recomendações:

    • Garantir que o nome acessível do botão descreve a ação disponível em cada momento.
    • Atualizar dinamicamente o nome acessível de acordo com o estado do menu.
    • Utilizar designações como "Abrir menu" quando o menu estiver fechado e "Fechar menu" quando estiver aberto, utilizando o atributo aria-label.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #25 Utilização de dois elementos h1 na mesma página

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 2.1

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

    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 poderá gerar problemas caso ambos os cabeçalhos h1 fiquem visíveis para os leitores de ecrã.

    Image

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

    URLs a verificar:

    https://informa.cm-machico.pt/acessibilidade

    Recomendações:

    • Remover o título genérico "Machico Resolve" da página de Declaração de Acessibilidade e Usabilidade.

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 #71 Campo de pesquisa sem etiqueta associada

    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:

    Foi identificado um campo de pesquisa implementado sem qualquer elemento <label> associado.

    O campo apresenta apenas um texto de placeholder ("Inserir referência..."), utilizado como indicação visual da sua finalidade.

    Contudo, o placeholder não substitui a função de uma etiqueta associada ao campo, uma vez que desaparece quando o utilizador inicia o preenchimento e não permite a interação prevista através do clique na etiqueta.

    Como consequência:

    • não existe uma etiqueta visível que identifique permanentemente o campo;
    • não é possível colocar o foco no campo através do clique numa etiqueta associada;
    • a identificação do campo pode tornar-se menos clara para alguns utilizadores.
    Image

    Figura 1 - Campo de pesquisa implementado sem elemento <label> associado

    URLs a verificar:

    Recomendações:

    • Associar uma etiqueta (<label>) ao campo de pesquisa através do atributo for;
    • Garantir que a etiqueta permanece visível durante a utilização do formulário;
    • Utilizar o placeholder apenas como informação complementar e não como substituto da etiqueta;
    • Validar que o clique na etiqueta posiciona corretamente o foco no campo de edição.

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 no formulário "Nova Ocorrência" não existe informação sobre o significado do asterisco (*) colocado à frente dos campos.

    Image

    Figura 1 - Formulário da página Nova Ocorrência. 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 *.

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 nome acessível 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 nome acessível do logótipo de aviso está a ser definido simultaneamente através dos atributos alt e title. Recomenda-se remover o atributo title, evitando duplicação ou inconsistência na informação transmitida aos utilizadores de tecnologias de apoio, e manter o nome acessível apenas no atributo alt. O texto atualmente presente no title deve ser transferido para o alt.

    Image

    URLs a verificar:
    https://informa.cm-machico.pt/pesquisa?ref=ODg4ODg4OA==

    Recomendações:
    As imagens não decorativas devem possuir uma descrição breve e adequada, disponibilizada por meio do atributo alt, descrevendo corretamente o conteúdo ou a função da imagem apresentada.

  • issue #10 (Melhoria) Imagem decorativa com texto alternativo indevido

    etiqueta: chk 10 webetiqueta: melhoriaetiqueta: 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 são utilizadas apenas como apoio visual, uma vez que a informação relevante já se encontra disponível por meio de título, descrição e links acessíveis em formato textual; nesses casos, as imagens podem ser consideradas decorativas e devem apresentar o atributo alt="". Observa-se, ainda, que algumas imagens possuem nome acessível por meio do atributo title; quando essas imagens forem meramente decorativas, além de definir o atributo alt como nulo (alt=""), recomenda-se remover o atributo title, a fim de evitar que tecnologias assistivas anunciem informações redundantes, irrelevantes ou desnecessárias.

    Image Image

    URLs a verificar:
    https://informa.cm-machico.pt/
    https://informa.cm-machico.pt/noticias/detalhe/617-construcao-de-escada-de-acesso-a-praia-da-maiata
    https://informa.cm-machico.pt/noticias (páginas internas das noticias)

    Recomendações:
    Recomenda-se que as imagens decorativas tenham alt="".

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #14 Imagem/gráfico não é acompanhado de uma descrição longa

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.2

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

    Evidências:

    Verifica-se que algumas imagens apresentadas no website não possuem texto alternativo ou conteúdo textual associado que descreva as informações nelas contidas. Um exemplo é a imagem abaixo onde podemos identificar que a imagem contém informação relevante em formato visual, incluindo o título da notícia, conteúdo textual e elementos gráficos, mas essa informação não está disponível de forma equivalente para utilizadores de tecnologias de apoio.

    Verifica-se também que o link alternativo indicado não disponibiliza uma transcrição ou descrição textual equivalente do conteúdo da imagem. Assim, a informação não fica plenamente acessível a utilizadores que dependem tecnologias de apoio.

    Image

    URLs a verificar:
    (verificar em todo website)

    Recomendações:
    A imagem deve ser acompanhado de uma descrição longa que pode ser associada à imagem em formato de texto.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #15 Imagem link têm um equivalente 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.

    Image Image

    URLs a verificar:
    https://informa.cm-machico.pt/

    Recomendações:
    Ajustar o nome acessível para identificar a finalidade e o destino do link, por exemplo: alt="Informa Machico - página inicial"

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 #34 Texto normal não têm contraste suficiente no website

    etiqueta: chk 10 webetiqueta: R 6.1etiqueta: NOK

    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.

    O website apresenta problemas de contraste no texto normal em formulários, nomeadamente nas mensagens de erro no símbolo de * para os campos obrigatórios, por exemplo no formulário de Nova ocorrência utilizam nas mensagens de erro, a combinação de cores #E73D4A(cor de primeiro plano) e #FFFFFF(cor de plano de fundo) que torna os textos pouco visíveis. (Figura 1)

    Image

    Figura 1- Mensagens de erro com problemas de contraste, com uma taxa de apenas 4,06:1 na avaliação com a ferramenta WAVE

    Na página Últimas Ocorrências a tabela apresenta a coluna “Estado” com problemas de contraste nas tags informativas, pois utilizam a combinação das cores #FFFFFF(cor de primeiro plano) e #D4C744(cor de plano de fundo) (Figura 2)

    Image

    Figura 2- Falha na avaliação de contraste em texto normal com a ferramenta ANDI

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

    URLs a verificar

    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;

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

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

Lista de evidências recolhidas:

  • issue #63 Visibilidade do foco nos controlos do leitor multimédia

    etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 7.1

    Deve ser possível ativar os botões de controlo do leitor quer com o rato quer com o teclado.
    – ver requisito 7.1 na lista 10 aspetos

    Evidências:

    Durante a navegação por teclado no leitor multimédia, verificou-se que os controlos podem ser alcançados através da tecla Tab. No entanto, nem sempre é evidente qual o elemento que possui o foco naquele momento.

    A reduzida visibilidade do indicador de foco dificulta a navegação por teclado, obrigando o utilizador a percorrer os controlos de forma tentativa até identificar a ação que será executada.

    Adicionalmente, em algumas situações, a área do vídeo apresenta um comportamento visual inconsistente durante a navegação pelos controlos, tornando menos clara a identificação do elemento atualmente selecionado.

    Image

    Figura 1 - Exemplo de navegação por teclado no leitor multimédia, onde a indicação visual do foco não é suficientemente evidente .

    URLs a verificar:

    https://informa.cm-machico.pt/noticias/detalhe/686-intervencao-municipal-na-promenade-do-porto-da-cruz

    Recomendações:

    • Reforçar a visibilidade do foco nos controlos do leitor multimédia através de um indicador visual mais evidente.
    • Garantir que todos os elementos interativos do leitor apresentam um estado de foco claramente identificável durante a navegação por teclado.
    • Validar o comportamento visual do leitor durante a navegação por teclado, assegurando que o conteúdo multimédia e os controlos são apresentados de forma consistente.
    • Considerar a adoção de estilos de foco com contraste adequado e facilmente percetíveis pelos utilizadores.

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:

  • issue #61 Ausência de legendas sincronizadas nos conteúdos multimédia

    etiqueta: R 7.2etiqueta: chk 10 webetiqueta: NOK

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

    Evidências:

    Foram identificados conteúdos multimédia que não disponibilizam legendas sincronizadas.

    A ausência de legendas sincronizadas adequadas dificulta o acesso à informação por pessoas surdas ou com deficiência auditiva, bem como por utilizadores que não podem reproduzir áudio no momento da consulta.

    Image

    Figura 1 - Exemplo de conteúdo multimédia sem legendas sincronizadas .

    URLs a verificar:

    https://informa.cm-machico.pt/noticias/detalhe/686-intervencao-municipal-na-promenade-do-porto-da-cruz

    Recomendações:

    • Disponibilizar legendas fechadas sincronizadas para todos os conteúdos multimédia.
    • Garantir que as legendas reproduzem de forma fiel o conteúdo verbal relevante apresentado no vídeo.
    • Incluir, quando aplicável, informação sobre sons relevantes para a compreensão do conteúdo.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #28 Filtros de pesquisa expostos ao leitor de ecrã antes de estarem visíveis

    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 observada, o painel de filtros/pesquisa pode ficar visualmente oculto quando a largura disponível da interface não permite a sua apresentação imediata.

    Contudo, apesar de não estar visível para o utilizador, o conteúdo dos filtros permanece disponível na árvore de acessibilidade e pode ser navegado por leitores de ecrã.

    Como consequência, a ordem de leitura disponibilizada às tecnologias de apoio não corresponde à informação efetivamente apresentada na interface, originando uma inconsistência entre o conteúdo visível e o conteúdo exposto programaticamente.

    Image

    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 os filtros são apresentados ou ocultados.
    • Garantir que a ordem de leitura anunciada pelos leitores de ecrã corresponde à ordem visual apresentada ao utilizador.
    • Validar o comportamento em diferentes larguras de ecrã e com tecnologias de apoio.

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 #31 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 notícias 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.

    URL 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 #30 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> e <section>), 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

  • issue #5 Modal sem papel semântico de diálogo e sem nome acessí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

    Foi identificada uma janela modal de aviso de erro associada ao formulário, implementada com elementos genéricos <div>, sem definição semântica de diálogo.

    O contentor principal da modal é apresentado como:

    <div class="blocoErroForm" role="alert" tabindex="-1">

    No entanto:

    • não existe role="dialog" nem aria-modal="true";
    • a janela modal não possui nome acessível programaticamente determinável;
    • apesar de existir um título visível (“Aviso”), este não se encontra associado ao contentor através de aria-labelledby;
    • não existe alternativa com aria-label.

    Embora seja utilizado role="alert", este mecanismo apenas permite o anúncio do conteúdo como mensagem dinâmica, não comunicando adequadamente a existência de um novo contexto de interação modal, especialmente quando existem controlos interativos, como o botão de fechar.

    Quando a janela é apresentada, leitores de ecrã podem não anunciar corretamente que foi iniciado um novo contexto de interação, dificultando a compreensão da interface e da ação necessária por parte do utilizador.

    Image

    Figura 1 – Modal de erro do formulário implementada sem semântica de diálogo e sem nome acessível

    URLs a verificar:

    Recomendações

    • A janela modal deve ser identificada programaticamente com role="dialog" (ou alertdialog, quando aplicável);
    • Deve ser definido aria-modal="true" quando a modal estiver ativa;
    • A modal deve possuir um nome acessível;
    • Sempre que exista título visível (ex.: “Aviso”), esse título deve ser associado com aria-labelledby;
    • Quando não exista título visual, deve ser utilizado aria-label;
    • Deve ser validado que, ao abrir a modal, o leitor de ecrã anuncia corretamente o contexto do diálogo e o respetivo conteúdo.

Requisito 8.4 - Quando se retira a CSS, a informação relevante permanece visível

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #27 Ticker de notícias/eventos com movimento automático sem mecanismo percetível de controlo

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.4

    Quando se retira o CSS, a informação relevante permanece visível.
    – ver requisito 8.4 na lista 10 aspetos

    Evidências:

    Na homepage foi identificado um ticker de ocorrências com deslocação horizontal automática contínua.

    O componente apresenta conteúdos que se deslocam automaticamente da direita para a esquerda, sem interação inicial do utilizador.

    Embora no código existam controlos de navegação e pausa, estes encontram-se ocultos:

    <div class="bn-controls">
    <button><span class="bn-arrow bn-prev"></span></button>
    <button><span class="bn-action bn-pause"></span></button>
    <button><span class="bn-arrow bn-next"></span></button>
</div>

    Deste modo, o utilizador pode ser exposto a conteúdo em movimento contínuo sem um mecanismo percetível para pausar, interromper ou controlar a animação.

    Image

    Figura 1 – Ticker com deslocação automática e controlos ocultos

    URL a verificar:

    Recomendações

    • Deve existir um mecanismo visível e facilmente identificável que permita pausar ou interromper o movimento automático.
    • Os controlos de navegação e pausa não devem estar ocultos quando o componente está ativo.
    • O utilizador deve poder avançar, recuar ou interromper a animação manualmente.
    • Recomenda-se validar este comportamento com navegação por teclado e leitores de ecrã.

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:

  • issue #7 Foco não é deslocado para a janela de erro após submissão inválida

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 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
    – ver requisito 9.1 na lista 10 aspetos

    Evidências:

    Após uma tentativa de submissão inválida do formulário, é apresentada uma janela com a mensagem de erro.

    Contudo, quando essa janela é aberta, o foco permanece no contexto anterior da página, não sendo deslocado para qualquer elemento presente na mensagem apresentada.

    Como consequência, os utilizadores que navegam por teclado ou recorrem a tecnologias de apoio podem não se aperceber imediatamente de que surgiu uma nova área de interação com informação relevante para a continuação da tarefa.

    Importa referir que esta situação poderá estar relacionada com os problemas estruturais identificados no issue https://github.com/a11y-PT/report_081/issues/5 relativamente à implementação da janela modal.

    Image

    Figura 1 - Janela de erro apresentada após submissão inválida sem deslocação automática do foco para o seu conteúdo

    URLs a verificar:

    Recomendações:

    • Garantir que, quando a janela de erro é aberta, o foco é automaticamente movido para um elemento presente no seu conteúdo.
    • Assegurar que os utilizadores de teclado conseguem iniciar imediatamente a interação no novo contexto apresentado.
    • Validar o comportamento com navegação exclusivamente por teclado e com tecnologias de apoio.

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 #26 O 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 modal esta aberta o foco não fica limitado a modal (teclado, leitor de ecrã).

    Image

    URLs a verificar:
    https://informa.cm-machico.pt/nova-ocorrencia

    Recomendações:

    • Recomenda-se prender o foco 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:

  • issue #29 A caixa de diálogo tem de ter um mecanismo que permita sair ou fechar a caixa

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 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
    – ver requisito 9.3 na lista 10 aspetos

    Evidências:
    Verifica‑se que a caixa de diálogo não pode ser encerrada através da tecla ESC.

    Image

    URLs a verificar:
    https://informa.cm-machico.pt/nova-ocorrencia

    Recomendações:
    Idealmente podem implementar um mecanismo que permita o encerramento das janelas modais através da tecla ESC.

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:

  • issue #33 Ao fechar a caixa de diálogo o cursor não retorna ao elemento que o acionou

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.4

    Quando a caixa de diálogo fecha, o foco (cursor do Browser) deve voltar ao elemento interativo que a invocou
    – ver requisito 9.4 na lista 10 aspetos

    Evidências:

    Ao fechar a modal o foco não retorna para o elemento que o acionou, em vez disso é reposicionado em outro elemento da página.

    Image

    URLs a verificar:
    https://informa.cm-machico.pt/nova-ocorrencia

    Recomendações:
    Recomenda-se que ao fechar a modal, o foco seja devolvido ao elemento que a acionou.

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 #73 Não foram encontrados PDFs

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

    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.

    URLs a verificar:

    Recomendações:

    Nada a acrescentar.

Checklist Conteúdo

etiqueta: NOK

Nível de conformidade:

  • Checklist Conteúdo: 29.4% (5/17)
    • Requisitos avaliados: 17 (17 aplicáveis)
    • Requisitos OK: 5
    • Requisitos NOK: 12

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

etiqueta: NOK

Lista de evidências recolhidas:

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 #36 O corpo de texto tem um tamanho inferior a 12pt (equivalente a 16px)

    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

    • Para garantir a legibilidade do corpo de texto, este deve ter um tamanho igual ou superior a 12pt, que equivale a 16px.

    O website possui informações primárias com tamanho inferior a 12pontos(16px). Na página Últimas Ocorrências, no conteúdo da tabela a coluna “Ocorrências” possui blocos de textos com tamanho de letra abaixo do valor mínimo recomendado. (Figura 1 e 2)

    Image

    Figura 1 - Conteúdo da tabela possui tamanho de letra com apenas 14px

    Na página Notícias, as descrições breves dos conteúdos das notícias apresentam tamanho de letra inferior ao mínimo recomendado. (Figura 2)


    Image

    Figura 2 - Textos informativos e informações de contactos com apenas 12px
    

    Além disso, o website apresenta botões e conteúdos informativos com tamanho de texto inferior ao recomendado. Como por exemplo na página inicial (Figura 3)

    Image

    Figura 3 - Verificação do tamanho de texto em botões e conteúdos informativos no website

    O formulário Nova ocorrência, possui filtros de categorias e textos em placeholders nos campos de preenchimentos, com textos que possuem tamanho de letra de apenas 14px. (Figura 4)

    Image

    Figura 4- Textos considerados informações primárias para preenchimento dos formulários com dimensão inferior ao recomendado

    URLs a verificar

    Recomendações
    É necessário rever todo website para ser corrigido os textos de informações primárias, para um tamanho igual ou superior ao recomendado.

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

etiqueta: NOK

Lista de evidências recolhidas:

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 #39 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

    Na página Últimas Ocorrências, no conteúdo da tabela a coluna “Ocorrências” possui blocos de textos com espaçamento inferior ao recomendado, por exemplo com espaçamento entre linhas de apenas 1.42 comprimindo o texto em relação ao tamanho da fonte. (Figura 1)



    Image

    Figura 1 - Textos com espaçamento inferior ao recomendado.

    URLs a verificar

    Recomendações

    Para assegurar a leitura confortável de blocos de texto deve ser usado um espaçamento entre linhas de 1.5x o tamanho da letra.
    É necessário rever todo website para garantir o espaçamento mínimo recomendado, relativo ao tamanho da letra.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    etiqueta: NOKetiqueta: 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:

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

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

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 Links do rodapé sem indicação visual de hiperligação

    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:

    Foi verificado que as hiperligações presentes no rodapé não possuem qualquer indicação visual que permita distingui-las do restante conteúdo.

    Os links são apresentados apenas como texto, sem elementos visuais adicionais, como sublinhado, alteração de estilo tipográfico ou outros indicadores que permitam aos utilizadores identificar facilmente que se trata de conteúdo clicável.

    Image

    Links do rodapé sem indicação de hiperligação.

    URLs a verificar:

    Recomendações:

    • 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).

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:

  • issue #16 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:

    Verificamos que a página O que posso comunicar apresenta um volume significativo de conteúdo distribuído por várias secções, sem disponibilizar um índice no topo da página com hiperligações internas para as respetivas áreas. Esta situação dificulta a navegação e a localização rápida da informação disponibilizada. (Figura 01)

    Image

    Figura 01 — Página "O que posso comunicar" sem índice de navegação interna.

    URL a verificar:

    Recomendações:

    Disponibilizar um índice de navegação interna no início da página, preferencialmente após o título principal (h1), contendo hiperligações para as principais secções do conteúdo. Por exemplo, na página O que posso comunicar, o índice poderá incluir ligações para as diferentes categorias ou áreas temáticas apresentadas ao longo da página, permitindo o acesso direto a cada secção e facilitando a navegação em conteúdos extensos.

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 #17 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:

    Verificamos que, em alguns dispositivos móveis, não é possível aceder ao conteúdo do rodapé da página inicial do website Machico Informa.
    Este comportamento impede o acesso a informação e funcionalidades disponibilizadas nessa área, comprometendo a adaptação do layout a diferentes tamanhos de ecrã. (Figura 01)

    Image

    Figura 01 — Rodapé da página inicial não acessível em determinados dispositivos móveis.

    Verificamos que, na página Nova Ocorrência, o botão "Enviar" não é apresentado corretamente em alguns dispositivos móveis, surgindo desalinhado relativamente aos restantes elementos do formulário. (Figura 02)

    Image

    Figura 02 — Botão "Enviar" desalinhado em alguns dispositivo móveis.

    Verificamos que, na página Últimas Ocorrências, parte da informação apresentada na tabela deixa de estar disponível em alguns dispositivos móveis. Enquanto na versão desktop são apresentadas várias colunas com informação sobre as ocorrências, na versão móvel apenas é apresentada a coluna "Subcategoria", não sendo possível consultar os restantes dados. (Figura 03)

    Image

    Figura 03 — Informação da tabela não apresentada na versão móvel.

    Verificamos que, na página Miradouro do Pico do Facho renovado e oficialmente reaberto ao público, o conteúdo das notícias não é apresentado integralmente em alguns dispositivos móveis, ficando parte do texto e das imagens cortada devido à largura disponível no ecrã. (Figura 04)

    Image

    Figura 04 — Conteúdo da notícia apresentado de forma incompleta em dispositivo móvel.

    URLs a verificar:

    Recomendações:

    Garantir que o website se adapta corretamente às diferentes larguras de ecrã, assegurando que todos os conteúdos e funcionalidades permanecem acessíveis em dispositivos móveis.
    Recomenda-se rever o comportamento responsivo do rodapé, dos formulários, das tabelas e dos conteúdos das notícias, de forma a evitar cortes de informação, desalinhamentos ou perda de conteúdo em ecrãs de menor dimensão.

Requisito 5.1 - Não existem elementos interativos acionados apenas com a passagem do rato (hover)

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #18 Elementos interativos dependentes de interação por hover para visualização

    etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 5.1

    Não existem elementos interativos acionados apenas com a passagem do rato.
    – ver requisito 5.1 na lista Conteúdo

    Evidências:

    Verificámos que existe um elemento interativo no rodapé do website Informa Machico que apenas é apresentado quando o utilizador passa o rato sobre a área correspondente. Esta funcionalidade não se encontra disponível da mesma forma para utilizadores que navegam através de dispositivos de toque. (Figura 01)

    Image

    Figura 01— O elemento interativo apenas é apresentado quando o utilizador passa o rato sobre a área correspondente.

    URL a verificar:

    Recomendações:

    Garantir que os elementos interativos se encontram permanentemente visíveis ou disponíveis através de diferentes formas de interação, não dependendo exclusivamente da passagem do rato para serem apresentados.

    Desta forma, assegura-se o acesso à mesma funcionalidade por utilizadores de dispositivos de toque e outras formas de navegação.

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 #19 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:

    Verificamos que o botão "Pesquisar", disponível na página inicial do website Informa Machico, tem uma altura de 35px, abaixo dos 44px recomendados para elementos interativos. (Figura 01)

    Image

    Figura 01 — Botão "Pesquisar" com altura de 35px inferior à dimensão recomendada.

    Adicionalmente, o botão "Contactos", presente no rodapé do website, tem uma altura de 37,1px. (Figura 02)

    Image

    Figura 02 — Botão "Contactos" com altura 37.1px inferior à dimensão recomendada.

    Verificamos que as caixas de seleção associadas às opções "Declaro sob compromisso de honra a veracidade do reporte submetido e assumo toda a responsabilidade consequente de falsas declarações ou inexatidão" e "Tomei conhecimento das condições editadas em Privacidade, Termos, RGPD e Cookies e concordo com as mesmas", presentes na página Nova Ocorrência, possuem uma altura de 28,56px, abaixo da dimensão mínima recomendada de 44px para elementos interativos. (Figura 03)

    Image

    Figura 03 — Caixas de seleção com dimensão inferior à recomendada.

    Verificamos que o botão de navegação utilizado para percorrer as categorias de ocorrências na página Todas as Ocorrências possui uma largura de 38px, valor inferior à dimensão mínima recomendada de 44px para elementos interativos. (Figura 04)

    Image

    Figura 04 — Botão de navegação com largura 38px inferior à dimensão recomendada.

    URLs a verificar:

    Recomendações:

    Garantir que os elementos interativos do website dispõem de uma área acionável mínima de 44px por 44px, de forma a facilitar a sua utilização em dispositivos de toque e por utilizadores com limitações motoras.
    Recomenda-se rever a dimensão dos botões, caixas de seleção e controlos de navegação identificados, assegurando que cumprem a dimensão mínima recomendada sem comprometer a legibilidade ou a experiência de utilização.

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 #20 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 o botão "Enviar", presente na página Nova Ocorrência, apresenta o mesmo estilo visual utilizado noutros botões do website, como os botões "Pesquisar", "Nova Ocorrência", "Contactos" e o botão do "Menu". Esta situação dificulta a identificação da ação principal da página. (Figura 01)

    Image

    Figura 01 — Botão "Enviar" e botão "Menu" com o mesmo estilo visual.

    URL a verificar:

    Recomendações:

    Destacar visualmente o botão "Enviar" relativamente às restantes ações disponíveis no website, assegurando que a ação principal da página é facilmente identificável pelos utilizadores.
    Recomenda-se a utilização de um estilo visual diferenciado, através da cor, dimensão, destaque ou outro elemento gráfico que o distinga claramente dos botões secundários e de navegação.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #22 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:

    Verificamos que o ícone de expansão da caixa de seleção presente na página Nova Ocorrência apresenta um contraste de 2.84:1 face ao fundo envolvente. Esta situação reduz a sua visibilidade e dificulta a identificação do componente como elemento interativo. (Figura 01)

    Image

    Figura 01 — Ícone de expansão com reduzida perceção visual.

    Verificamos que o ícone de filtragem/ordenação presente no cabeçalho da tabela da página Últimas Ocorrências3 apresenta um contraste de 2.39:1 face à cor de fundo. Esta situação reduz a sua visibilidade e dificulta a identificação da funcionalidade disponível. (Figura 02)

    Image

    Figura 02 — Ícone de filtragem/ordenação com contraste inferior ao recomendado.

    Verificamos que, em estado hover, os elementos de filtragem do mapa de Todas as Ocorrências, como por exemplo "Água", apresentam um contraste de 1.87:1, valor inferior ao mínimo recomendado. Esta situação dificulta a leitura e identificação do elemento selecionado. (Figura 03)

    Image

    Figura 03 — Elemento de filtragem com contraste inferior ao recomendado em estado hover.

    Verificamos que, no mapa da página Todas as Ocorrências, a etiqueta "Em análise" apresenta um contraste de 1.74:1 em estado hover, valor inferior ao mínimo recomendado. Esta situação dificulta a leitura e identificação do estado apresentado. (Figura 04)

    Image

    Figura 04 — Etiqueta "Em análise" com contraste inferior ao recomendado em estado hover.

    URLs a verificar:

    Recomendações:

    Garantir que os elementos interativos apresentam um contraste suficiente face ao fundo envolvente, de forma a facilitar a sua identificação e utilização.

    Recomenda-se rever as cores utilizadas nos ícones de expansão, filtragem e ordenação, bem como nos estados de interação dos elementos de filtragem, assegurando uma perceção visual clara das funcionalidades disponíveis.

  • issue #21 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:

    Verificamos que o elemento gráfico composto pelo símbolo e pela designação "Informa Machico", presente na página inicial do website Informa Machico é clicável, mas não apresenta características visuais que permitam identificar essa funcionalidade. A sua apresentação é semelhante à de um elemento meramente informativo, podendo dificultar a perceção da interação disponível. (Figura 01)

    Image

    Figura 01 — Elemento gráfico clicável sem indicação visual de interação.

    Verificamos que o cabeçalho "Data da ocorrência", presente na tabela da página Últimas Ocorrências, permite ordenar os resultados apresentados, mas não apresenta indicadores visuais que permitam identificar claramente essa funcionalidade. Esta situação pode dificultar a perceção do elemento como interativo. (Figura 02)

    Image

    Figura 02 — Cabeçalho da coluna "Data da ocorrência" sem indicação visual da funcionalidade de ordenação.

    Verificamos que, na página Notícias, o botão "Limpar filtro" é apresentado de forma semelhante a texto comum, sem indicadores visuais que permitam identificar claramente a sua funcionalidade. Esta situação pode dificultar a perceção do elemento como interativo. (Figura 03)

    Image

    Figura 03 — Botão "Limpar filtro" sem diferenciação visual face ao conteúdo envolvente.

    URLs a Verificar:

    Recomendações:

    Garantir que os elementos gráficos interativos apresentam características visuais que permitam identificar claramente a sua funcionalidade. Recomenda-se a utilização de indicadores visuais consistentes, como estilos de botão, ícones, efeitos visuais ou outros elementos que reforcem a perceção de interação.

    No caso da página Notícias, recomenda-se que a ação "Limpar filtro" seja apresentada como um elemento interativo claramente identificável e que a hierarquia visual das ações disponíveis na página seja consistente, diferenciando adequadamente as ações principais das secundárias.

Checklist Transação

etiqueta: NOK

Nível de conformidade:

  • Checklist Transação: 33.3% (3/9)
    • Requisitos avaliados: 13 (4 N/A excluídos, 9 aplicáveis)
    • Requisitos OK: 3
    • Requisitos NOK: 6
    • Requisitos N/A: 4

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #11 Elementos do formulário não incluídos na sequência de tabulação

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

    A sequência de tabulação entre campos segue a sequência de preenchimento.
    – ver requisito 1.1 na lista Transação

    Evidências:
    Durante os testes de navegação por teclado ao formulário, verificou-se que alguns campos de seleção (comboboxes), nomeadamente os campos de Categoria, Subcategoria e Freguesia, não são alcançados através da navegação sequencial com a tecla Tab.

    Como consequência, a sequência de tabulação não acompanha integralmente a ordem de preenchimento do formulário, obrigando os utilizadores que dependem exclusivamente do teclado a recorrer a métodos alternativos para aceder a estes campos.

    Este comportamento pode dificultar o preenchimento do formulário e comprometer a previsibilidade da navegação.

    Image

    Figura 1 - Campos de seleção não incluídos na sequência normal de tabulação do formulário

    URLs a verificar:

    Recomendações:

    • Garantir que todos os campos necessários ao preenchimento do formulário são alcançáveis através da tecla Tab.
    • Verificar a implementação dos componentes de seleção utilizados (comboboxes), assegurando a sua integração na sequência de foco.
    • Garantir que a ordem de tabulação acompanha a ordem lógica de preenchimento do formulário.
    • Validar o comportamento com navegação exclusivamente por teclado.

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 #8 Não foram encontrados formulários com mais de 2 ecrãs no website

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

    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 Informa Machico. 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 #9 Não foram encontrados formulários com mais de uma página

    etiqueta: chk transaçãoetiqueta: N/Aetiqueta: 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 do site Informa Machico. 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 #41 O tamanho dos campos não reflete o tamanho previsível dos dados

    etiqueta: chk transaçãoetiqueta: NOKetiqueta: 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:
    Verificámos que na página Nova Ocorrência, os campos Categoria, Subcategoria, Freguesia, Sítio/Localidade e Morada, apresentam uma largura maior do que a necessária para o tipo de dados que devem receber. Esta dimensão excessiva pode levar os utilizadores — sobretudo nos campos de texto livre — a pensar que precisam de escrever mais informação do que a realmente exigida.

    Image

    Figura – Formulário da página Nova Ocorrência.

    URL a verificar:
    Página Nova Ocorrência. Campos:

    • Categoria
    • Subcategoria
    • Freguesia
    • Sítio/Localidade
    • Morada

    Recomendações:
    Recomendamos ajustar a largura dos campos para que corresponda ao tamanho real da informação a inserir.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #42 Há campos dependentes de outros campos que estão imediatamente visíveis mas estão inativos

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

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

    Notas gerais:
    Os campos dependentes do preenchimento de outros campos devem aparecer apenas após o campo principal ter sido preenchido. Desta forma, reduz-se a probabilidade de preencher dados contraditórios.

    Evidências:
    No formulário da página Nova Ocorrência, o campo Subcategoria (dependente do campo anterior Categoria) está visível, mas inativo por defeito.

    Image

    Figura – Análise do campo Subcategoria, na página Nova Ocorrência, através do Google Inspector.

    URL a verificar:
    Página Nova Ocorrência – Campo Subcategoria

    Recomendações:
    Recomendamos que o campo Subcategoria seja totalmente ocultado, tanto na interface como para tecnologias de apoio. Este campo só deve ser apresentado ao utilizador depois de o campo Categoria, do qual depende, ter sido preenchido.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #46 Existem campos do formulário sem legenda

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

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

    Notas gerais:
    Todos os campos devem ter uma legenda breve e clara associada, que descreva quais os tipos de dados que devem ser inseridos nesse mesmo campo.

    Evidências:
    No formulário da página Pesquisa e no campo de pesquisa presente no cabeçalho do site, verificámos que estes campos não têm uma legenda (label) associada. Sem essa identificação, não é imediatamente claro para o utilizador — incluindo quem utiliza tecnologias de apoio — que tipo de informação deve ser introduzida no campo.

    Image

    Figura 1 - Análise do formulário da página Pesquisa através do Google Inspector.

    Image

    Figura 2 - Análise do campo de pesquisa geral fixo no topo do site através do Google Inspector.

    URLs e componentes a verificar:

    • Página Pesquisa
    • Campo de pesquisa geral fixo no topo do site

    Recomendações:
    Recomendamos que seja adicionado um rótulo, através do elemento

  • issue #43 Existem campos cuja legenda não é clara

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

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

    Notas gerais:
    As legendas dos campos devem ser claras, curtas e concisas, para que sejam rapidamente entendidas pelo utilizador.

    Evidências:
    Verificámos que a legenda do campo Sítio/Localidade do formulário da página Nova Ocorrência não é clara.

    Image

    Figura – Formulário da página Nova Ocorrência. Campo Sítio/Localidade está destacado através de um retângulo de borda preta.

    URL a verificar:
    Página Nova Ocorrência – Campo Sítio/Localidade.

    Recomendações:
    A legenda do campo deve ser alterada para deixar mais claro a informação a inserir. Neste caso, uma possível solução seria apenas “Localidade”.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #45 Campos obrigatórios não reconhecidos por leitores de ecrã

    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, em alguns campos do formulário da página Nova Ocorrência, apesar de existir a associação do atributo required aos campos obrigatórios, o leitor de ecrã não os reconhece como tal devido a uma estrutura semântica incorreta.

    Image

    Figura 1 – Análise do campo Categoria, no formulário da página Nova Ocorrência, através do leitor de ecrã NVDA.

    Image

    Figura 2 – Análise do campo Categoria, no formulário da página Nova Ocorrência, através do Google Inspector.

    URL a verificar:
    Página Nova Ocorrência – Campos:

    • Categoria
    • Subcategoria
    • Freguesia
    • Declaro sob compromisso de honra a veracidade do reporte submetido e assumo toda a responsabilidade consequente de falsas declarações ou inexatidão.
    • Tomei conhecimento das condições editadas em Privacidade, Termos, RGPD e Cookies e concordo com as mesmas.

    Recomendações:
    Recomendamos que estes campos sejam reestruturados para garantir que a obrigatoriedade é exposta de forma programática e corretamente interpretada por tecnologias de apoio.

    Como referência para uma implementação acessível de uma combobox, recomendamos consultar o exemplo da W3C Editable Combobox With Both List and Inline Autocomplete.
    No caso de componentes como campos de texto livre, listas suspensas ou checkboxes, a página Creating Accessible Forms apresenta exemplos práticos de implementações acessíveis destes componentes.

    Além disso, recomendamos que todos os campos obrigatórios incluam o atributo required aplicado diretamente no controlo do formulário. Nos campos de texto livre, este atributo deve ser colocado no elemento . No caso de uma combobox, o atributo deve ser aplicado no elemento ou

  • issue #44 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

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

    Evidências:
    Verificámos que, no formulário da página Nova Ocorrência, há o símbolo de um asterisco * após o rótulo dos campos.
    No entanto, não é fornecida uma legenda clara sobre o significado do asterisco no formulário.

    Image

    Figura - Formulário da página Nova Ocorrência.

    URLs a verificar:
    Página Nova Ocorrência

    Recomendações:
    Recomendamos que seja adicionada uma legenda no início do formulário que indique claramente o significado de *.
    Uma outra possível solução é adicionar a descrição “(obrigatório)” ou “(campo obrigatório)” em frente aos rótulos dos campos obrigatórios.

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 #4 Inexistência de ações longas

    etiqueta: chk transaçãoetiqueta: N/Aetiqueta: 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.

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 #13 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".

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 #48 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:

    Verificado que as mensagens de erro apresentadas nos campos: Email, NIF e Telefone, presentes no formulário Nova Ocorrência, não ajudam no preenchimento correto dos campos.

    Conforme observado na figura, quando estes campos são preenchidos com um formato incorreto, as mensagens de erro apresentadas não indicam qual o formato esperado. Dessa forma, o utilizador não recebe orientação suficiente para corrigir a informação introduzida e concluir o preenchimento do formulário de forma adequada.

    Image

    URLs a verificar:
    https://informa.cm-machico.pt/nova-ocorrencia

    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 4 melhorias que se recomenda efetuar)

Lista de evidências recolhidas:

Significado das etiquetas utilizadas