Relatório Avaliação de Candidatura
Machico Ambiente

Introdução

O website https://machicoambiente.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 aspetos20.0% (5/25)etiqueta: Não passa
Conteúdo17.6% (3/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: 20.0% (5/25)
    • Requisitos avaliados: 27 (2 N/A excluídos, 25 aplicáveis)
    • Requisitos OK: 5
    • Requisitos NOK: 20
    • Requisitos N/A: 2

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 #47 O menu principal não está estruturado como uma lista

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.1

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

    Evidências:

    Apesar de estarem a utilizar a semântica de lista com ul e li, foi utilizado atributos como o role="menubar", role="menuitem" e aria-haspopup que alteram a semântica nativa desses elementos. Como consequência, as tecnologias de apoio deixam de os reconhecer como uma lista, passando a interpretá‑los como componentes de menu de aplicação e não de navegação:

    Image

    Opção do menu "Atividades Municipais" com o atributo role="menuitem" e aria-haspopup="true"

    URLs a verificar:

    Recomendações:

    Remover os atributos role="menubar", role="menuitem" e aria-haspopup="true" do menu principal.

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 #53 Não é possível fechar as opções do menu com o leitor 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 navegar no menu com um leitor de ecrã, é possível expandir as opções de primeiro nível utilizando o comando de ativação (por exemplo, VO + Espaço). No entanto, após a expansão, não é possível voltar a recolher a mesma opção através desse mesmo mecanismo.

    Quando o utilizador regressa ao item de primeiro nível utilizando as setas direcionais do leitor de ecrã (VO + Setas), os comandos VO + Espaço ou Enter deixam de permitir o fecho da opção expandida. Como consequência, o comportamento do componente torna-se inconsistente para utilizadores de tecnologias de apoio.

    Este problema sugere que o estado do componente não está a ser corretamente gerido ou comunicado através do atributo aria-expanded, impedindo que leitores de ecrã reconheçam adequadamente as transições entre os estados expandido e colapsado.

    Image

    URLs a verificar:

    Recomendações:

    • As opções de 1º nível devem abrir ou fechar conforme a ação do utilizador.
    • Rever a implementação do atributo aria-expanded, assegurando que o seu valor é atualizado
    • Quando as subopções estiverem visíveis, deve ser possível voltar para a opção de 1º nível e fechá‑la utilizando as teclas VO + Espaço ou Enter.
    • Idealmente, podem incluir a tecla ESC como uma segunda alternativa para fechar as subopções.
    • As opções de 1º nível devem abrir ou fechar conforme a ação do utilizador. Isso também deve ser revisto no menu mobile

  • issue #52 Não é possível navegar para a opção seguinte do menu sem percorrer as subopções

    etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 1.2

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

    Evidências:

    No menu mobile, quando se navega pelas opções com o leitor de ecrã e com o teclado, as subopções são automaticamente apresentadas ao utilizador. Isso obriga o utilizador a percorrer todas as opções e respetivas subopções até encontrar a desejada, não permitindo saltar diretamente entre as opções de 1.º nível:

    Image

    URLs a verificar:

    Recomendações:

    • As opções devem abrir/fechar conforme escolha do utilizador. Para isso, é necessário implementar um evento em conjunto com o aria-expanded gerenciar a abertura e fecho das subopções.

  • issue #51 Não é possível identificar opções que contém subopções com o leitor 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:

    Quando navegamos com o leitor de ecrã no menu lateral, não é possível identificar quais opções possuem subopções, uma vez que não é anunciado se estão abertas ou fechadas:

    Image

    Leitor de ecrã não informa se a opção está aberta ou fechada

    Existe um botão sem ícone responsável por abrir/fechar o menu. O leitor de ecrã não identifica quando está expandido ou compactado

    Image

    Na estrutura não é localizado o atributo aria-expanded no botão role="button". Para além disso, o nome da opção (MACHICO AMBIENTE) está estruturado como link ao invés de ser um texto

    Isso acontece também com o menu mobile, quando abrimos ou fechamos o menu não é indicado que ele aberto ou fechado. Para além disso, quando navegamos pelas opções do menu, não é possível abrir / fechar as opções porque está sendo aberto automaticamente quando está em foco. Isso não é recomendável porque o utilizador será forçado a percorrer todas as opções do menu.

    Image

    URLs a verificar:

    Recomendações:

    • Estruturalmente existem dois elementos interativos para a mesma ação de abrir / fechar menu. O link que está sendo estruturado no nome de cada opção deve ser alterado para ser um texto e no botão deve ser inserido um ícone (▾) para indicar visualmente que existem subopções. Para além disso, não recomendamos utilizarem o role="button", ele deve ser estruturado com a tag button do html.
    • O ícone do botão (▾) deve ter um texto alternativo apropriado. Para mais informações consultar a issue #49 (critério 1.3)
    • Utilizar o atributo aria-expanded em conjunto com um script para gerenciar a abertura e fecho das opções. O atributo deve ser inserido no botão.
    • As subopções devem ser apresentadas apenas quando o utilizador abrir as subopções. Para mais informações consultar também a issue #52

  • issue #48 Os menus 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.

    Evidências:

    Verifica-se que não está a ser utilizado a tag nav em nenhum menu de navegação, excepto os breadcrumbs. 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 principal não identificado como nav

    Image

    Menu secundário não identificado como nav

    Image

    Menu mobile não identificado como nav

    O menu "Machico Digital" encontra-se identificado como um elemento de navegação do website. No entanto, por agregar ligações para plataformas e websites externos relacionados, este não deve ser tratado como um menu de navegação interna, mas sim como um portal de acesso a serviços e websites adjacentes.

    Image

    Imagem do "Machico Digital" inapropriadamente identificado como nav

    URLs a verificar:

    Recomendações:

    • O menu lateral e principal devem estar estruturados dentro de uma tag nav.
    • O portal "Machico Digital" deve ser retirado da tag nav.
    • Garantir que o borão de fechar e abrir menu na versão mobile esteja dentro da tag nav.
    • Deve ser possível distinguir as nav do menu principal, lateral e breadcrumb. Para isso, utilizem o atributo aria-label para nomeá-los, como por exemplo: aria-label="Menu", aria-label="Subopções da página" e aria-label="Caminho de navegação".

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 #49 O menu mobile está com texto alternativo inapropriado

    etiqueta: chk 10 webetiqueta: R 1.3etiqueta: NOK

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

    Evidências:

    Quando o menu mobile é aberto, a respectiva imagem do menu se altera para o fechar (X). No entanto, o seu nome acessível não se altera:

    Image

    Imagem do menu para fechar com o label "Open mobile menu"

    Outro cenário acontece no menu, o leitor de ecrã está a anunciar o menu mobile como "Open mobile menu". Isso acontece porque o seu nome acessível está em inglês:

    Image

    Imagem do botão de fechar do menu com a aria-label="Open mobile menu"

    Adicionalmente, foi verificado que o botão utilizado para expandir e recolher as opções do menu lateral não apresenta um ícone visível que permita identificar claramente a sua funcionalidade. Adicionalmente, o controlo não possui um nome acessível que descreva a ação que será executada.

    Image

    Imagem do botão de abrir subopções do menu lateral sem texto alternativo ou visibilidade.

    URLs a verificar:

    Recomendações:

    • Alterar o nome acessível para aria-label="Menu".
    • Garantir que o controlo do botão do menu lateral é implementado através de um elemento <button>, conforme recomendado para componentes interativos.
    • O ícone do botão (▾) deve possuir um texto alternativo apropriado, como por exemplo: "Abrir subopções de Machico Ambiente".
    • Apresentar um ícone visível que permita identificar a funcionalidade de expandir ou recolher subopções.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    etiqueta: chk 10 webetiqueta: R 2.1etiqueta: NOK

    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://machicoambiente.pt/acessibilidade

    Recomendações:

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

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 #61 Não foram identificadas tabelas

    etiqueta: chk 10 webetiqueta: N/Aetiqueta: 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 identificadas tabelas no website, tornando este critério N/A.

    URLs a verificar:

    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 #60 Não foram identificadas tabelas

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

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

    Evidências:

    Não foram identificadas tabelas no website, tornando este critério N/A.

    URLs a verificar:

    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 #30 Etiqueta do campo de pesquisa não visível

    etiqueta: chk 10 webetiqueta: R 4.1etiqueta: NOK

    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 que o campo de pesquisa do website possui uma etiqueta (label) programaticamente associada, mas cujo texto se encontra oculto visualmente através de regras CSS (por exemplo, display: none).

    Como consequência, do ponto de vista visual, o campo é apresentado sem uma etiqueta visível, dificultando a identificação imediata da sua finalidade pelos utilizadores.

    Adicionalmente, verificou-se a utilização de um elemento fieldset com uma legend (“Search Form”) aplicada a um único campo de pesquisa. Esta implementação não é semanticamente adequada, uma vez que o elemento fieldset deve ser utilizado para agrupar múltiplos campos relacionados sob um mesmo conceito ou pergunta.

    A ausência de uma etiqueta visível reduz a área de interação disponível (não permitindo focar o campo através do clique na etiqueta) e pode comprometer a consistência da experiência para utilizadores de tecnologias de apoio.

    Image

    Figura 1 - Campo de pesquisa com etiqueta visualmente oculta

    Os utilizadores podem ter maior dificuldade em identificar a finalidade do campo de pesquisa, particularmente em contextos de navegação visual, ampliação de ecrã ou dificuldades cognitivas.

    A utilização inadequada de fieldset e legend pode ainda introduzir redundância semântica desnecessária para tecnologias de apoio.

    URLs a verificar:

    Recomendações:

    • Garantir que todos os campos de formulário possuem etiquetas (label) visíveis no ecrã;
    • Evitar ocultar visualmente etiquetas relevantes através de display: none ou técnicas equivalentes;
    • Associar corretamente o texto da etiqueta ao respetivo campo através do atributo for;
    • Remover o elemento fieldset e a respetiva legend quando aplicados a um único campo sem necessidade de agrupamento semântico.

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 #15 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árioss "Elogios e Reclamações" e "A minha ideia para o Machico Ambiente" não existe informação sobre o significado do asterisco (*) colocado à frente dos campos.

    Image

    Figura 1 - Formulário da página Elogios e Reclamações. 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 4.3 - É possível localizar e ler as mensagens de erro usando apenas um leitor de ecrã

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    etiqueta: chk 10 webetiqueta: R 5.2etiqueta: NOK

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

    Evidências:

    Verifica-se que embora a página apresente conteúdo relevante sobre o Programa de Vigilância da Gripe Aviária e instruções importantes sobre o que fazer ao encontrar aves selvagens doentes ou mortas, a informação essencial está disponibilizada apenas em formato de imagem/cartaz, sem alternativa textual equivalente na página.

    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 de leitores de ecrã,

    Image

    O mesmo ocorre com as imagens presentes na página “Praia acessível”: a maior parte da informação é apresentada apenas em formato de imagem, sem texto associado que represente adequadamente o seu conteúdo. Esta implementação dificulta o acesso à informação por utilizadores de leitores de ecrã, uma vez que o conteúdo visual não é disponibilizado em formato textual equivalente.

    Image

    URLs a verificar:

    Recomendações:

    • A imagem deve ser acompanhado de uma descrição longa que pode ser associada ao texto já existente na página.

    Para as imagens que permitem visualização ampliada (ex.: imagens da página "Praia acessível"):

    • Recomenda-se que o conteúdo atualmente apresentado na imagem seja disponibilizado numa página do website. Desta forma, a informação passa a estar acessível diretamente na estrutura da página.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #11 Imagem link têm um equivalente alternativo incorreto

    etiqueta: chk 10 webetiqueta: R 5.3etiqueta: NOK

    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.

    Também foi verificado que o nome acessível está a ser fornecido de forma redundante. Em alguns casos, o elemento <a> apresenta simultaneamente os atributos aria-label e title; noutros casos, o elemento <img> apresenta simultaneamente os atributos alt e title. Esta duplicação pode gerar informação repetida ou desnecessária para utilizadores de tecnologias de apoio.
    Neste caso, o elemento principal que deve conter o nome acessível é a própria imagem (<img>), através do atributo alt, uma vez que é ela que representa visualmente o logotipo/imagem e identifica o destino do link.

    Image Image

    URLs a verificar:
    https://machicoambiente.pt/ambiente-online/informacoes/noticias
    https://machicoambiente.pt/atividades-municipais/projetos-e-atividades/praia-acessivel

    Recomendações:

  • issue #8 Imagem-link com nome acessível definido incorretamente através de title

    etiqueta: chk 10 webetiqueta: R 5.3etiqueta: NOK

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

    Evidências:
    Verifica-se que a imagens-link da pesquisa no modo mobile, estão a depender exclusivamente do atributo title para fornecer o seu nome acessível. Nesse caso o equivalente alternativo deve ser disponibilizado no mecanismo acessível principal através do aria-label.

    Image

    Verifica-se que o nome acessível da imagem-link que direciona para a Câmara municipal de Machico, está a ser fornecido de forma redundante no elemento <a>, por meio dos atributos aria-label e title. Neste caso, o elemento principal que deve conter o nome acessível é a própria imagem (<img>), através do atributo alt, uma vez que é ela que representa visualmente o logotipo e identifica o destino do link.

    Verifica-se também que o nome acessível disponibilizado no atributo alt da imagem ("LogoMachico") , não descreve claramente o destino ou a finalidade da hiperligação. Recomenda-se inserir uma descrição que indique corretamente o destino da hiperligação.

    Image

    URLs a verificar:
    https://machicoambiente.pt/

    Recomendações:

    • O title deve ser utilizado para informações complementares, ou seja, não devem utilizar para fornecer o nome acessível do link ou da imagem.
    • Para as imagens/ícones presentes no cabeçalho, recomenda-se definir um nome acessível por meio do atributo aria-label, garantindo que a finalidade de cada link seja corretamente comunicada às tecnologias de apoio. Também recomenda-se também remover o atributo title.

    Para a imagem logotipo utilizada como link para a página inicial:

    • Recomenda-se remover os atributos aria-label e title do elemento <a>, manter o nome acessível através do atributo alt.
    • Ajustar o nome acessível para identificar a finalidade e o destino do link, por exemplo: alt="Acesso à página Município de Machico | Governação Local".

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 #69 Texto normal não tem contraste suficiente no website

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

    A avaliação com as ferramentas Colour Contrast Analyser e WAVE revelam problemas relacionados com insuficiência de contraste, afetando diretamente a legibilidade.

    O website apresenta problemas de contraste no texto normal em formulários, nomeadamente nas mensagens de erro, por exemplo no formulário nde 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

    Além disso, há problemas de contraste em textos de imagens em componentes fixas e disponíveis em várias páginas do website, por exemplo na secção “Machico Lifestyle | #VISIT MACHICO” onde os textos são pouco visíveis sobre o fundo com imagem. (Figura 2)

    Image

    Figura 2- Texto sobre imagens com problemas de contraste e texto pouco visíveis

    Na página Praia Acessível, todas as imagens com textos normais, apresentam problemas na avaliação de contraste e dificultam a leitura do conteúdo para pessoas com baixa visão. (Figura 3)



    Image

    Figura 3 - Mapas de acessibilidade com problema de contraste no texto normal

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

    URLs a verificar

    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;

    • Sugerimos que escureçam as imagens da secção "Machico Lifestyle", colocando um filtro por exemplo, para que os textos fiquem mais legíveis.
    • Assegurar que a combinação de cores fundo em relação a textos sobre imagens informativas, cumprem a avaliação mínima recomendada

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 #44 Filtros de pesquisa expostos ao leitor de ecrã antes de estarem visíveis

    etiqueta: chk 10 webetiqueta: R 8.2etiqueta: NOK

    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 #43 Estrutura hierárquica de conteúdos sem 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:
    Foi identificada uma estrutura de navegação hierárquica apresentada visualmente como árvore expansível.

    Contudo, os itens da árvore encontram-se implementados com elementos genéricos, sem uma estrutura semântica que identifique programaticamente a hierarquia entre níveis nem os estados de expansão e recolha dos diferentes grupos.

    Quando os estilos visuais são removidos, a relação hierárquica entre os elementos deixa de ser claramente percetível, dificultando a compreensão da organização da informação.

    Como consequência, tecnologias de apoio podem não conseguir interpretar corretamente a estrutura do componente nem transmitir ao utilizador a organização e o estado dos conteúdos apresentados.

    Image

    Figura 1 – Estrutura hierárquica apresentada visualmente sem semântica adequada no HTML

    URLs a verificar:

    Recomendações:

    • Deve ser verificado este padrão em todo o website.
    • Estruturas hierárquicas devem ser implementadas com elementos HTML semanticamente adequados.
    • Os diferentes níveis de conteúdos devem ser identificáveis programaticamente.
    • Os estados expandido e recolhido dos elementos devem ser expostos de forma acessível.
    • Deve ser validado que a hierarquia continua percetível quando os estilos visuais são desativados.

  • issue #42 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 #41 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 #40 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.

  • issue #21 Existem cards que não são clicáveis

    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:
    O link do card está implementado com um título que está sendo escondido visualmente mas acessível para leitores de ecrã. Isso faz com que a área clicável do link seja delimitada apenas pela faixa selecionada na imagem, não sendo possível clicar no card com o rato. Com o teclado, não é possível localizar aonde está o foco, o que dificulta o entendimento da onde será clicado:

    Image

    URLs a verificar:
    https://machicoambiente.pt/atividades-municipais/principios-e-valores/ecos-machico
    https://machicoambiente.pt/atividades-municipais/projetos-e-atividades/dia-europeu-sem-carros

    Recomendações:

    • O link deve estar atribuído ao título que está visível
    • Toda a área do card deve ser clicável com o rato. Para isso, recomendado utilizarem a técnica do streched link. Partilhamos o link do bootstrap que tem um exemplo de construção: https://getbootstrap.com/docs/4.4/utilities/stretched-link/

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #50 Filtros de navegação indisponíveis na versão mobile

    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 página observada, existe uma estrutura de filtros/categorias que permite navegar pelos diferentes grupos de documentos disponíveis.

    Contudo, na versão mobile, estes filtros não são apresentados ao utilizador, deixando de estar disponível uma funcionalidade que existe na versão desktop.

    Como consequência, os utilizadores de dispositivos móveis ficam impedidos de utilizar o mesmo mecanismo de navegação e filtragem disponibilizado noutras versões da interface, dificultando a localização e exploração dos conteúdos.

    Image

    Figura 1 - Filtros de navegação disponíveis em desktop mas não apresentados na versão mobile

    URLs a verificar:

    Recomendações:

    • Garantir que os filtros de navegação permanecem disponíveis em dispositivos móveis.
    • Caso seja utilizada uma apresentação diferente em mobile, assegurar que todas as funcionalidades existentes na versão desktop continuam acessíveis.
    • Validar a página em diferentes larguras de ecrã para confirmar que não ocorre ocultação indevida de funcionalidades.

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

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.4

    Evidências:

    Na homepage foi identificado um ticker de notícias/eventos 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" style="visibility:hidden">
    <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:

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 #28 O foco não fica limitado a caixa de diálogo

    etiqueta: chk 10 webetiqueta: R 9.2etiqueta: NOK

    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://machicoambiente.pt/participacao/a-minha-ideia-para-o-machico-ambiente

    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:

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

    etiqueta: chk 10 webetiqueta: R 9.4etiqueta: NOK

    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:
    Verifica-se que, ao fechar a modal de aviso, o foco é encaminhado automaticamente para os campos do formulário que apresentam erro, permitindo ao utilizador revê-los e corrigi-los. Se este comportamento for mantido, recomenda-se substituir o botão “Fechar” apresentado actualmente por um botão com texto descritivo, que indique claramente a acção seguinte, por exemplo: “Fechar e corrigir campos assinalados”.

    Caso se opte por manter o botão atual, o comportamento mais adequado será devolver o foco ao botão “Enviar”, que foi o elemento que accionou a modal. Desta forma, evita-se uma mudança inesperada de contexto e garante-se uma navegação mais previsível e coerente para o utilizador.

    Image

    URLs a verificar:

    Recomendações:
    Recomenda-se inserir um botão com texto descritivo que indique claramente a acção seguinte após o fecho da modal ou, em alternativa, ajustar o comportamento para que o foco regresse ao botão “Enviar”, que accionou a modal.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #58 Nos ficheiros PDF não é possível, extrair o conteúdo textual para formato TXT

    etiqueta: chk 10 webetiqueta: R 10.1etiqueta: NOK

    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:

    Image

    Figura 1 - Exemplo de documento PDF em que não foi possível extrair o conteúdo textual .

    Foi verificado que, nos documentos PDF avaliados, não é possível extrair o conteúdo textual para formato TXT.

    Esta situação indica que os documentos poderão ter sido disponibilizados como imagens digitalizadas ou sem uma camada de texto acessível, impedindo a seleção, cópia e extração do conteúdo textual.

    A ausência de texto extraível dificulta o acesso à informação por utilizadores de tecnologias de apoio, bem como a reutilização do conteúdo através de ferramentas de leitura e processamento de texto.

    URLs a verificar:

    Verificar todos os PDFs na secção dos PDFs: https://machicoambiente.pt/ambiente-online/informacoes/diretorio-documentos

    PDF 1

    PDF 2

    PDF 3

    Recomendações:

    • Garantir que os documentos PDF disponibilizados permitem a extração do conteúdo textual para formato TXT.
    • Aplicar Reconhecimento Ótico de Caracteres (OCR) aos documentos que se encontrem em formato de imagem digitalizada.
    • Validar, após a conversão, que o texto pode ser selecionado, copiado e extraído por tecnologias de apoio e ferramentas de leitura.
    • Sempre que possível, gerar os ficheiros PDF diretamente a partir dos documentos de origem, preservando a camada de texto acessível.

Checklist Conteúdo

etiqueta: NOK

Nível de conformidade:

  • Checklist Conteúdo: 17.6% (3/17)
    • Requisitos avaliados: 17 (17 aplicáveis)
    • Requisitos OK: 3
    • Requisitos NOK: 14

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 #16 Falta de resumo na página inicial do website

    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 da Machico Ambiente, não aparece presente um resumo breve do próposito do site.

    Image

    Imagem da página principal sem fazer scroll

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

Requisito 2.2 - A informação secundária (datas, autores) utiliza, no mínimo, um tamanho de letra de 10 pontos

etiqueta: NOK

Lista de evidências recolhidas:

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 #57 O espaçamento entre linhas está abaixo do recomendado

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

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

    Evidências:

    Verificámos que, na página inicial do website Machico Ambiente, alguns blocos de texto apresentam um espaçamento entre linhas inferior ao recomendado.

    Na secção "Ambiente Online", o elemento "Limpeza de Terrenos" apresenta um espaçamento entre linhas de 24 px para um tamanho de letra de 20 px. (Figura 01)

    Image

    Figura 01 — Texto "Limpeza de Terrenos" com espaçamento 24px para um tamanho de letra 20px.

    Na secção "Flash Ambiente", a descrição do vídeo "Tempo de Decomposição do Lixo no Mar" apresenta um espaçamento entre linhas de 20 px para um tamanho de letra de 20 px. (Figura 02)

    Image

    Figura 02 — Descrição de vídeo "Tempo de Decomposição do Lixo no Mar" com um espaçamento entre linhas de 20 px para um tamanho de letra de 20 px.

    Na secção "Documentos Ambiente", o elemento "Taxas e Tarifários Municipais" apresenta um espaçamento entre linhas de 20 px para um tamanho de letra de 20 px. (Figura 03)

    Image

    Figura 03 — Elemento interativo "Taxas e Tarifários Municipais" com um espaçamento entre linhasde 20 px para um tamanho de letra de 20 px.

    Verificámos que, na página Desenvolvimento Sustentável, alguns blocos de texto apresentam um espaçamento entre linhas inferior ao recomendado.

    A título de exemplo, o bloco de texto da secção #Ambiente, associado à notícia "Os Suspeitos do Costume – da Bandeira Azul", apresenta um espaçamento entre linhas de 18 px para um tamanho de letra de 18 px. (Figura 04)

    Image

    Figura 04 — Bloco de texto da secção #Ambiente com espaçamento entre linhas inferior ao recomendado.

    **URLs a verificar:

    Recomendações:

    Para as evidências apresentadas nas figuras 01, 02 e 03, o espaçamento entre linhas deverá ser ajustado para, no mínimo, 30 px, de forma a cumprir a relação mínima de 1.5x face ao tamanho de letra utilizado (20 px).

    Relativamente à evidência apresentada na figura 04, o espaçamento entre linhas deverá ser ajustado para, no mínimo, 27 px, considerando o tamanho de letra de 18 px.

    Recomenda-se ainda a revisão dos restantes blocos de conteúdo do website, de forma a garantir que o espaçamento entre linhas respeita o valor mínimo recomendado em função do tamanho da letra utilizada, contribuindo para uma melhor legibilidade dos conteúd

Requisito 3.1 - Nenhum nível de navegação tem mais de 9 opções

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #35 Excesso de opções no menu principal

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 3.1

    Nenhum nível de navegação tem mais de 9 opções.
    – ver requisito 3.1 na lista Conteúdo

    Evidências:

    Os menus de navegação devem se manter equilibrado, nem com demasiadas opções de topo sem opções secundárias, nem com poucas opções de topo e muitas opções secundarias. Nenhum nível de navegação deve ter mais de 9 opções, mas neste caso a subopção "Projetos e Atividades" da opção "Atividades Municipais" do menu principal contêm 11 opções.

    Image

    URLs a verificar:

    Recomendações:

    Recomenda-se a reorganização destes menus, de forma a reduzir o número de itens apresentados e a estruturar a informação de modo mais claro, simples e intuitivo, promovendo uma melhor experiência de utilização e conformidade com os princípios de acessibilidade.

    Com vista à melhoria da usabilidade e conformidade com os princípios de acessibilidade, recomenda-se:

    • Reduzir o número de opções no subnível, agrupando conteúdos relacionados sob categorias mais abrangentes.
    • Utilizar rótulos claros e consistentes que facilitem a identificação rápida das secções.

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

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

    Image

    Links do breadcrumb sem idicaçã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:

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

    Verificámos que o breadcrumb não se encontra visível em algumas visualizações móveis do website. A título de exemplo, na página O que é o Portal Machico Online, este elemento deixa de ser apresentado, dificultando a perceção da localização atual e da hierarquia de navegação do website. (Figura 01)

    Image

    Figura 1 — Breadcrumb não visível na versão móvel da página "O que é o Portal Machico Online".

    Verificámos que, na página Pedido de Esterilização, os textos associados às opções de consentimento não se encontram corretamente alinhados com as respetivas caixas de seleção em algumas visualizações móveis, dificultando a leitura e associação entre os elementos do formulário. (Figura 02)

    Image

    Figura 02 — Opções de consentimento desalinhadas em visualização móvel.

    URLs a verificar:

    Recomendações:

    Recomenda-se rever a apresentação dos conteúdos em dispositivos móveis, garantindo que elementos de navegação, como o breadcrumb, permanecem visíveis e que os componentes dos formulários mantêm um alinhamento consistente nas diferentes larguras de ecrã.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

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

    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 Machico Ambiente 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.

    URLs 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 #23 Elementos interativos com área clicável inferior à dimensão mínima recomendada de 44px CSS

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

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

    Evidências:

    Verificámos que, na página inicial do website Machico Ambiente, o ícone de acesso ao menu do Machico Digital apresenta uma dimensão de 31,08 × 40 px, inferior ao mínimo recomendado de 44 × 44 px para elementos interativos. (Figura 01)

    Image

    Figura 01 — Ícone do menu do Machico Digital com dimensão inferior à recomendada.

    Verificámos que, na página A minha ideia para o Machico Ambiente, alguns controlos de formulário apresentam uma área clicável inferior à dimensão mínima recomendada de 44 × 44 px.

    Os botões de opção "Sugestão" e "Informação" apresentam uma altura de 20 px. (Figura 02)

    Image

    Figura 02 — Botões de opção com dimensão inferior à recomendada.

    A caixa de seleção associada à declaração de consentimento "Declaro ter conhecimento da política de privacidade da Câmara Municipal de Machico" apresenta uma altura de 22,61 px. (Figura 03)

    Image

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

    Adicionalmente, os ícones de partilha em redes sociais apresentam dimensões inferiores ao mínimo recomendado. A título de exemplo, o ícone do Facebook apresenta uma dimensão de 30 × 32 px. (Figura 04)

    Image

    Figura 04 — Ícone de partilha em rede social com dimensão inferior à recomendada.

    Verificámos que, na página Notícias, alguns elementos interativos apresentam dimensões inferiores ao mínimo recomendado de 44 × 44 px.

    Os botões "Anterior" e "Seguinte" apresentam uma altura de 30 px.(Figura 05)

    Image

    Figura 05 — Botões "Anterior" e "Seguinte" com dimensão inferior à recomendada.

    Adicionalmente, os botões de numeração da paginação apresentam uma dimensão de 30 × 30,45 px. (Figura 06)

    Image

    Figura 06 — Botões de paginação com dimensão inferior à recomendada.

    Verificámos que, na página Limpeza Urbana, o botão de remoção de ficheiros (ícone "X") da área de carregamento de documentos apresenta uma dimensão de apenas 9 × 9 px, valor significativamente inferior à dimensão mínima recomendada de 44 × 44 px. (Figura 07)

    Image

    Figura 07 — Botão de remoção de ficheiros com dimensão inferior à recomendada.

    URLs a verificar:

    Recomendações:

    Recomenda-se aumentar a área clicável dos elementos identificados, garantindo uma dimensão mínima de 44 × 44 px e uma utilização mais confortável em dispositivos de toque.

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:

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

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

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

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

    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 Machico Ambiente. 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: OK (no entanto contém 1 melhoria que se recomenda efetuar)

Lista de evidências recolhidas:

  • issue #75 Não existem restrições do número de caracteres a inserir nos campos

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

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

    Notas gerais:
    Os campos de formulário, que têm um limite máximo de números (ex: número de telefone, código postal…), devem limitar a quantidade de caracteres a inserir. Desta forma, garantimos que não são inseridos mais caracteres do que o necessário, evitando possíveis erros.

    Evidências:
    Nos campos “NIF e “Contacto de telefone”, das páginas A Minha Ideia para o Machico Ambiente e Elogios e Reclamações, não parece haver um limite para o número máximo de dígitos que estão a aceitar.

    Image

    Figura 1 - Teste dos campos “NIF e “Contacto de telefone” na página A Minha Ideia para o Machico Ambiente

    Image

    Figura 2 - Teste dos campos “NIF e “Contacto de telefone” na página Elogios e Reclamações.

    URLs a verificar:

    Recomendações:
    O NIF é constituído por 9 dígitos, enquanto um contacto de telefone pode ir até um máximo de 14 dígitos com indicativo (por exemplo, 00 351 911 111 111).

    Recomendamos a revisão dos campos de escrita para limitar o número máximo de caracteres que é possível inserir.

    Para campos muito grandes, como campos de mensagem de escrita livre, pode ainda ser dada a visibilidade do número máximo de caracteres que é possível inserir.

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

etiqueta: N/A

Lista de evidências recolhidas:

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

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

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

    No site de Manchico Ambiente 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”.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #72 Existem campos do formulário cuja legenda não é clara

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

    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 o campo “Cartão de Cidadão” das páginas Queimadas, Limpeza de Terrenos e Corte de Árvores, não é claro.

    Image

    Figura – Formulário da página Queimadas. Campo “Cartão de Cidadão” está destacado através de um retângulo de borda preta.

    URLs a verificar:
    Páginas Queimadas, Limpeza de Terrenos e Corte de Árvores – Campo “Cartão de Cidadão”.

    Recomendações:
    A legenda do campo deve ser alterada para deixar mais claro a informação que deve ser inserida. Por exemplo, “Número do Cartão de Cidadão” ou “Número de Identificação Civil (NIC)”.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

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

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

    Evidências:
    Verificámos que nos formulários das páginas Remoção de Veículos, Corte de Árvores, Queimadas e Limpeza de Terrenos, não há indicação do significado do símbolo asterisco (*) utilizado após os rótulos para indicar que se trata de um campo de preenchimento obrigatório.

    Image

    Figura - Análise do formulário da página Queimadas.

    URLs a verificar:

    Recomendações:
    Recomendamos que seja adicionada uma legenda no início dos formulários em questão a explicar, de forma breve e clara, o significado do *. Por exemplo, “* Campo de preenchimento obrigatório”.

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

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

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

    Evidências:
    Verificámos que, nos formulários das páginas A minha ideia para o Machico Ambiente e Remoção de Veículos há campos que não estão programaticamente identificados como obrigatórios através do atributo required.

    Image

    Figura – Análise do campo “O que pretende fazer?” do formulário da página A minha ideia para o Machico Ambiente.

    URLs a verificar:

    Recomendações:
    Recomendamos que, além de utilizar o asterisco (*) após o rótulo e da respetiva legenda no início do formulário que explica o significado desse símbolo, seja também aplicado o atributo required nos elementos de controlo do formulário (como input, select, entre outros).
    Desta forma, os utilizadores que recorrem a tecnologias de apoio recebem uma indicação programática clara de que o campo é de preenchimento obrigatório.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

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

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

    Evidências:

    Ao submeter um formulário como o de "Corte de Árvores", é apresentada uma mensagem de erro do navegador com a indicação "Erro ao gravar".

    Contudo, após o aparecimento desta mensagem, a interface mantém o estado de carregamento ativo indefinidamente, sem fornecer qualquer informação adicional sobre o resultado da operação.

    Durante este estado:

    • não é apresentada uma mensagem clara sobre o motivo da falha;
    • não existe confirmação de que o pedido foi rejeitado;
    • o indicador de carregamento permanece ativo sem atualização de estado;
    • o utilizador não consegue perceber se a operação terminou, falhou ou continua em processamento.

    Como consequência, é gerada incerteza relativamente ao resultado da submissão, podendo o utilizador repetir a operação ou abandonar o processo sem saber se o pedido foi efetivamente registado.

    Image

    Figura 1 - Mensagem de erro apresentada após submissão do formulário, mantendo-se simultaneamente o estado de carregamento

    Sempre que ocorre um erro durante uma transação, o sistema deve comunicar de forma clara e inequívoca o resultado da operação.

    A apresentação simultânea de uma mensagem de erro e de um estado de carregamento contínuo transmite informação contraditória, dificultando a compreensão do estado real do processo.

    URLs a verificar:

    Recomendações:

    • Interromper imediatamente o estado de carregamento quando ocorre um erro;
    • Apresentar uma mensagem de erro clara e contextualizada;
    • Garantir que o utilizador consegue distinguir entre estados de processamento, sucesso e falha;
    • Comunicar programaticamente as mensagens de erro às tecnologias de apoio (ex.: role="alert" ou aria-live);
    • Evitar estados de carregamento permanentes após a conclusão ou falha da operação.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #9 Ausência de mensagem de confirmação após submissão bem-sucedida de formulário

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

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

    Evidências:

    Após a submissão dos formulários do Serviço Online, o sistema permanece no estado de carregamento indefinido (loader), sem apresentar qualquer mensagem visual de sucesso ao utilizador.

    Embora seja indicado que a informação pode ser atualizada para leitores de ecrã, não existe uma confirmação visível e percetível na interface.

    O utilizador não recebe:

    • mensagem de sucesso;
    • confirmação de submissão;
    • indicação de conclusão do processo.

    Como consequência:

    • não é possível confirmar visualmente se a operação foi concluída com sucesso;
    • o estado final da ação permanece ambíguo;
    • a experiência depende exclusivamente de feedback não visual.
    Image

    Figura 1 - Estado de carregamento após submissão do formulário, sem mensagem de confirmação de sucesso visível ao utilizador

    Após a conclusão de uma transação ou submissão de formulário, o sistema deve fornecer uma confirmação clara e acessível do sucesso da operação.

    Essa confirmação deve ser:

    • visível na interface;
    • consistente para todos os utilizadores;
    • complementar ao feedback fornecido por tecnologias de apoio.

    A ausência de mensagem de sucesso cria incerteza quanto ao resultado da ação e afeta a confiança na interação.

    URLs a verificar:

    Recomendações:

    • Implementar mensagem de sucesso visível após submissão do formulário.
    • Garantir que a mensagem é clara.
    • Remover estado de loading quando a operação termina.
    • Garantir consistência entre feedback visual e feedback acessível.
    • Validar que a confirmação é percebida tanto visualmente como por leitores de ecrã.

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 #68 Não existem formulários que permitam ações destrutivas pelo utilizador

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

    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.3 - As mensagens de erro são claramente identificadas junto aos campos de origem

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #34 As mensagens de erro não são apresentadas junto aos campos de origem

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

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

    Evidências:

    Verifica-se que, na estrutura analisada, não estão implementadas mensagens de erro associadas aos campos do formulário. Assim, quando ocorre um erro de validação, não é apresentada uma mensagem visível na proximidade do campo que permita ao utilizador identificar o problema e perceber como o corrigir.

    Image

    Figura 1 - Formulário Queimadas

    URL a verificar

    Recomendações

    • Recomenda-se a implementação de mensagens de erro para os campos de formulário, de forma que, sempre que ocorra um erro de validação, seja apresentada uma mensagem visível na proximidade do respetivo campo. Cada mensagem deve identificar claramente o erro ocorrido e, sempre que aplicável, indicar ao utilizador como o pode corrigir.
    • As mensagens de erro implementadas devem ainda ser associadas programaticamente aos respetivos campos. Para essa associação, pode ser utilizado o atributo aria-describedby, garantindo que o valor deste atributo corresponde ao id do elemento que contém a mensagem de erro aplicável. Em alternativa, pode ser utilizado o atributo aria-errormessage, igualmente preenchido com o id do elemento que contém a mensagem de erro.
    • Nos campos com erro, deve também ser utilizado aria-invalid="true", de forma a indicar programaticamente que o campo contém um valor inválido.

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:

Outras violações

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

Lista de evidências recolhidas:

  • issue #66 Outras Violações - Ligações para documentos redirecionam incorretamente para a página inicial

    etiqueta: outras violaçõesetiqueta: melhoria

    Evidências:

    Na página observada, foram identificadas várias ligações para documentos que não permitem o acesso ao conteúdo pretendido.

    Ao ativar qualquer uma das hiperligações apresentadas na página, o utilizador é redirecionado para a página inicial do website, em vez de ser encaminhado para o documento correspondente.

    Como consequência, os conteúdos referenciados deixam de estar acessíveis através das ligações disponibilizadas na página.

    Image

    Figura 1 - Ligações para documentos a redirecionar incorretamente para a página inicial

    URLs a verificar:

    Recomendações:

    • Verificar a validade dos endereços associados às hiperligações disponibilizadas.
    • Garantir que cada ligação encaminha para o documento correspondente.
    • Validar periodicamente as referências para prevenir a existência de ligações quebradas ou redirecionamentos incorretos.
    • Assegurar que os documentos referenciados permanecem acessíveis aos utilizadores.

  • issue #65 Outras Violações - Texto truncado no filtro de seleção por ano

    etiqueta: outras violaçõesetiqueta: melhoria

    Evidências:

    Na página observada, o controlo de seleção utilizado para filtrar conteúdos por ano apresenta o texto da opção selecionada de forma truncada, não permitindo visualizar integralmente o respetivo conteúdo.

    A análise efetuada indica que o problema está relacionado com a largura fixa atribuída ao componente (width: 31%), que não disponibiliza espaço suficiente para a apresentação adequada do texto.

    Como consequência, a informação apresentada no filtro pode tornar-se mais difícil de interpretar pelos utilizadores.

    Image

    Figura 1 - Texto da opção selecionada apresentado de forma truncada no filtro por ano

    URLs a verificar:

    Recomendações:

    • Rever a largura atribuída ao controlo de seleção, garantindo que o conteúdo é apresentado integralmente.
    • Evitar a utilização de larguras fixas que possam provocar truncamento do texto em diferentes resoluções ou níveis de ampliação.
    • Validar a apresentação dos filtros em diferentes tamanhos de ecrã para garantir a correta visualização das opções selecionadas.

  • issue #64 Outras Violações - Sobreposição de elementos na informação de atualização da página

    etiqueta: outras violaçõesetiqueta: melhoria

    Evidências:

    Na página observada, os ícones de partilha em redes sociais sobrepõem-se à informação relativa à data de atualização do conteúdo.

    Esta situação compromete a legibilidade da informação apresentada e afeta a organização visual da interface, podendo dificultar a perceção correta da data de atualização por parte dos utilizadores.

    Image

    Figura 1 - Ícones de partilha sobrepostos à data de atualização da página

    URLs a verificar:

    Recomendações:

    • Garantir que os elementos da interface não se sobrepõem entre si em diferentes resoluções e níveis de ampliação.
    • Assegurar espaçamento adequado entre os ícones de partilha e a informação relativa à atualização da página.
    • Validar o comportamento da página em diferentes tamanhos de ecrã para garantir a correta apresentação dos conteúdos.

Significado das etiquetas utilizadas