Relatório Avaliação de Candidatura
Câmara Municipal de Machico

Introdução

O website https://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 aspetos25.9% (7/27)etiqueta: Não passa
Conteúdo23.5% (4/17)etiqueta: Não passa
Transação77.8% (7/9)etiqueta: 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: 25.9% (7/27)
    • Requisitos avaliados: 27 (27 aplicáveis)
    • Requisitos OK: 7
    • Requisitos NOK: 20

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

    etiqueta: NOKetiqueta: R 1.1etiqueta: chk 10 web

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

    Evidências:

    Quando navegamos com o leitor de ecrã pelas subopções de “Institucional”, o leitor anuncia que as opções estão dentro de “grupos”, não existindo qualquer indicação de que se trata de uma lista de opções ou a informação sobre o número de opções disponíveis:

    Image

    Isso ocorre porque, apesar de estarem a utilizar a semântica de lista com ul e li, foi utilizado atributos como o role="menu",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:

    Image

    URLs a verificar:

    Recomendações:

    • Remover os atributos role="menu",role="menubar", role="menuitem" e aria-haspopup de todas as opções do menu desktop e mobile.

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 #61 Não é possível navegar para a opção seguinte do menu sem percorrer as subopções

    etiqueta: melhoriaetiqueta: chk 10 webetiqueta: 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 #60 O menu principal não está estruturado como uma navegação

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.2

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

    Evidências:

    Os menus de navegação não estão estruturados como uma navegação utilizando a tag nav. Ao utilizar 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

    Image

    Menu secundário

    Image

    Menu mobile

    URLs a verificar:

    Recomendações:

    • Inserir o menu principal dentro de uma tag nav. Essa alteração deve ser feita no menu desktop e mobile.
    • O botão de fechar e abrir o menu da versão mobile deve estar incluido na tag nav.
    • Visto que inclui mais do que uma navegação, denominar na tag nav com o atributo aria-label cada menu.

  • issue #58 Não é possível identificar opções que contém subopções com o leitor de ecrã

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.2

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

    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

    Image

    Na estrutura não é localizado o atributo aria-expanded

    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:

    • Utilizar o atributo aria-expanded em conjunto com um script para gerenciar a abertura e fecho das opções.
    • As subopções devem ser apresentadas apenas quando o utilizador abrir as subopções. Para mais informações consultar também a issue #61

  • issue #57 Não é possível fechar as opções do menu com o leitor de ecrã

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.2

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

    Evidências:

    Quando abrimos uma opção do menu com o teclado, as suas opções são automaticamente fechadas quando o foco retorna para a opção de 1º nível. Contudo, essa construção gera problemas quando navega-se com o leitor de ecrã. Por exemplo, ao retornar a opção de 1º nível utilizando as setas direcionais (VO+setas direcionais) não é possível fechar a opção com o VO + Espaço ou o ENTER:

    Image

    Quando o foco retorna para a opção de 1º nível as subopções são automaticamente fechadas com o teclado

    Adicionalmente, apenas utilizando o teclado não é possível abrir as subopções do "Municipal".

    Image

    O leitor de ecrã confirma que tentou expandir o "Municipal" mas o menu não foi aberto.

    URLs a verificar:

    Recomendações:

    • As opções de 1º nível devem abrir ou fechar conforme a ação do utilizador.
    • 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.
    • Revisar a abertura da opção "Municipal"
    • 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

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

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.3

    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

    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

    URLs a verificar:

    Recomendações:

    • Alterar o nome acessível para aria-label="Menu".

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    etiqueta: NOKetiqueta: chk 10 webetiqueta: 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://cm-machico.pt/acessibilidade

    Recomendações:

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

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 4.1

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

    Evidências:

    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 #66 Não há informação clara sobre o que é o asterisco nos campos de preenchimento obrigatório

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 4.2

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

    Evidências

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

    Verificámos que nos formulários "Fale com o Executivo" e "Reuniões de Câmara" não existe informação sobre o significado do asterisco (*) colocado à frente dos campos.

    Image

    _Figura 1 - Formulário da página Fale com o Executivo. 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:

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    etiqueta: NOKetiqueta: chk 10 webetiqueta: 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 a imagem referente aos contactos de emergência apresenta informação textual relevante, como entidades e respetivos números de telefone, porém essas informações estão disponibilizadas apenas na imagem. Não foi identificado texto associado na página que reproduza o conteúdo apresentado.

    Image
    • Imagem/gráfico da galeria de imagens

    Verifica-se que o texto alternativo definido no atributo alt é insuficiente para descrever adequadamente a imagem. No entanto, o texto presente no atributo title apresenta uma descrição mais adequada e deve ser transferido para o atributo alt. Recomenda-se, após essa alteração, remover o atributo title, evitando redundância e garantindo que o nome acessível da imagem seja fornecido corretamente pelo alt.

    Image
    • Imagem ampliada da galeria

    A imagem ampliada deve apresentar o mesmo texto alternativo da imagem/gráfico, garantindo consistência na identificação do conteúdo visual. No entanto, nesse caso, o alt não deve incluir a indicação “clique para visualizar", uma vez que a ação já foi executada e a imagem ampliada deve apenas descrever o conteúdo efetivamente apresentado.

    Image

    URLs a verificar:

    Recomendações:

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

    Para as imagens da galeria:

    • Deve ser removido o atributo title da imagem/gráfico e integrada no atributo alt o texto alternativo e a indicação da ação disponível, isto é, que a imagem permite abrir a galeria.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #40 Imagens-link com estrutura semântica incorreta

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 5.3

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

    Evidências:

    Verificado que a galeria de imagens apresenta comportamento visual de elemento clicável, semelhante a um link de galeria. No entanto, a sua estrutura HTML não utiliza elementos semânticos adequados para esse tipo de interação.

    Atualmente, as imagens estão inseridas diretamente na página sem estarem envolvidas por uma tag <a> ou por um elemento interativo apropriado, como <button>. Essa implementação compromete a identificação das imagens como elementos clicáveis por tecnologias de apoio.

    Image

    URLs a verificar:
    https://cm-machico.pt/municipal/machico-atua/turismo

    Recomendações:
    Recomenda-se ajustar a estrutura HTML da galeria para que as imagens clicáveis utilizem elementos semânticos adequados, como <a> quando direcionarem para uma imagem ampliada ou outro recurso.

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

    etiqueta: NOKetiqueta: chk 10 webetiqueta: 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 as imagens utilizadas como links para redes sociais possuem o atributo title, além do atributo alt, para informar seu nome acessível. Nesse caso, o texto alternativo equivalente deve ser fornecido apenas no atributo alt da imagem, sendo recomendada a remoção do atributo title para evitar redundância na experiência de usuários de tecnologias assistivas.

    Image

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

    Image

    Verifica-se que no cabeçalho da página, existem imagens/ícones que 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 Image

    Também foi verificado que algumas imagens/ícones, abrem numa nova janela (target="_blank") porém não informa explicitamente o utilizador, o que pode causar desorientação, especialmente para utilizadores de tecnologias de apoio. Recomenda-se que a imagem-link possua um nome acessível que descreva claramente a finalidade do link e informe que o conteúdo será aberto num novo separador, por exemplo: aria-label ="Machico informa | Comunicação e gestão de ocorrências e alertas no concelho de Machico (abre num novo separador)"

    Image

    URLs a verificar:

    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="Município de Machico | Governação Local - acesso a 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 #30 O texto normal não têm contraste suficiente em certos estados

    etiqueta: melhoriaetiqueta: chk 10 webetiqueta: R 6.1

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

    Evidências:

    • O contraste no texto normal (menor que 18 pontos ou menor que 14 pontos negrito) das páginas deve ser, no mínimo 4,5:1, para que as pessoas com baixa visão consigam ler o texto. Este contraste é aplicado a todos os estados dos elementos (normal, hover, focus, etc).

    A avaliação com a ferramenta Colour Contrast Analyser revela que há elementos de texto com pouco contraste no estado hover.

    O website disponibiliza em todo website o menu “Machico Digital” para aceder a “Portais e Serviços da Câmara Municipal de Machico”, identificamos nos cartões dos Portais que o texto normal apresenta problemas de contraste na combinação de cores #FFFFFF(cor de primeiro plano) e #0098d8(cor de plano de fundo) o que torna os textos pouco visíveis. (Figura 1)

    Image

    Figura 1- Texto normal com problemas de contraste, com uma taxa de apenas 3,2:1

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

    Image

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

    Image

    Figura 3- Estado de hover dos textos da secção “Machico Informa” na página incial e páginas interiores com baixo contraste

    Image

    Figura 4- Logotipo com problemas de contraste, disponível na página inicial, durante carregamentos e em páginas interiores como na Machico Apoia

    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 de todos textos normais da páginas no website para garantir os valores mínimos de contraste do texto normal. Garantir consistência nos estados visuais (normal, hover, foco) com contraste adequado;

    • Caso exista texto normal com pouco contraste, em que as cores utilizadas sejam as mesmas do logótipo da entidade, recomendamos a substituição dessas cores por outras que garantam um contraste mínimo de 4,5:1. Por exemplo, podem ser usados tons semelhantes ao do logotipo ou outras cores da identidade gráfica da marca.

  • issue #29 Texto normal não têm contraste suficiente

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 6.1

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

    Evidências

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

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

    O website apresenta problemas de contraste no texto normal da modal de cookies da versão para dispositivos móveis na combinação de cores #FFFFFF(cor de primeiro plano) e #319DC8(cor de plano de fundo) que torna os textos pouco visíveis. (Figura 1)

    Image

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

    Além disso, há problemas de contraste nas mensagens de erro, por exemplo no formulário Fale com o Executivo onde 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 2)

    Image

    Figura 2- Mensagens de erro com problemas de contraste, com uma taxa de apenas 4,06:1

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

    URLs a verificar

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

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

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #70 Players sem legendas audiodescritivas

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 7.2

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

    Evidências:

    Foram identificados conteúdos multimédia (vídeo) sem legendas fechadas sincronizadas.

    A ausência de legendas limita o acesso à informação por utilizadores com dificuldades auditivas, bem como em contextos em que não seja possível utilizar o áudio, comprometendo a acessibilidade do conteúdo multimédia.

    Image

    Figura 1 - Página com conteúdo vídeo sem disponibilização de legendas fechadas sincronizadas .

    URLs a verificar:

    Verificar todas as noticias com players multimédia.

    Recomendações:

    • Disponibilizar legendas fechadas sincronizadas para todos os conteúdos multimédia que incluam áudio relevante.
    • Sempre que possível, garantir que as legendas são precisas e sincronizadas com o conteúdo falado.
    • Quando não existe coneúdo falado, as legendas podem descrever o que decorre no vídeo.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.2

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

    Evidências:

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

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

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

    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 o painel é aberto ou fechado.
    • Garantir que a ordem de leitura anunciada pelos leitores de ecrã corresponde à ordem visual apresentada ao utilizador.
    • Validar o comportamento com navegação assistiva em dispositivos móveis.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #50 Estrutura hierárquica de conteúdos sem semântica adequada

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.3

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

    Evidências:
    Foi 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 #47 Modal sem papel semântico de diálogo e sem nome acessível

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.3

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

    Evidências

    Foi identificada uma janela modal de galeria de fotos implementada com elementos genéricos <div>, sem definição semântica de diálogo.

    O contentor principal da modal é apresentado como:

    <div id="estatistica1Modal" class="estatistica1Modal" style="display: block;">

    No entanto:

    • não existe role="dialog" nem aria-modal="true";
    • a janela modal não possui nome acessível programaticamente determinável;
    • não existe associação a um título visível através de aria-labelledby;
    • também não existe alternativa com aria-label.

    Quando a modal é aberta, leitores de ecrã podem não anunciar corretamente que foi iniciado um novo contexto de interação.

    Image

    Figura 1 – Modal de galeria de fotos 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, 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.

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

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.3

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

    Evidências:

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

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

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

    Image

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

    URLs a verificar:

    Recomendações:

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

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

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.3

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

    Evidências

    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 #17 Listagem de conteúdos sem estrutura semântica adequada

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.3

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

    Evidências:

    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.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

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

  • issue #22 Quando a caixa de diálogo é aberta, o foco não move-se para um elemento dentro da caixa de diálogo

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

    Validado que ao abrir a caixa de diálogo o cursor não se move automaticamente pra dentro da caixa de diálogo.

    Image Image

    URLs a verificar:

    Recomendações:

    Quando a caixa de dialogo é aberta o foco deve ser posicionado no primeiro elemento interativo.

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:

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 #24 A caixa de diálogo tem de ter um mecanismo que permita sair ou fechar a caixa

    etiqueta: NOKetiqueta: chk 10 webetiqueta: 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://cm-machico.pt/municipal/machico-atua/turismo

    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:

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 #38 Nos ficheiros PDF não é possível, extrair o conteúdo textual para formato TXT

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 10.1

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

    Evidências:

    Verifica-se que em vários ficheiros PDF do website, não é possível extrair o conteúdo textual para formato TXT.

    Image

    Figura 1 - Primeiro exemplo.

    Image

    Figura 2 - Segundo exemplo.

    URLs a verificar:

    https://cm-machico.pt/institucional/consulta-publica/diretorio-de-documentos

    Recomendações:

    • Devem garantir que os ficheiros PDF são otimizados para que seja possível extrair a informação para um processador de texto. Desta forma, garante-se que o texto pode ser lido por leitores de ecrã na ordem correta. No caso de documentos que são fotocópias, contendo apenas imagens, é possível converter os documentos para texto através do Reconhecimento Óptico de Caracteres (OCR) da Adobe.

Checklist Conteúdo

etiqueta: NOK

Nível de conformidade:

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

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #4 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 Cãmara Municipal de Machico, 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: OK (no entanto contém 1 melhoria que se recomenda efetuar)

Lista de evidências recolhidas:

  • issue #34 Legibilidade insuficiente do texto presente em logótipos institucionais e de distinções

    etiqueta: chk conteúdoetiqueta: melhoriaetiqueta: R 2.2

    A informação secundária (datas, autores) utiliza, no mínimo, um tamanho de letra de 10 pontos.
    – ver requisito 2.2 na lista Conteúdo

    Evidencias:

    Verificámos que vários logótipos apresentados na página inicial do website Município de Machico, nomeadamente os da "Região Autónoma da Madeira", "Assembleia Legislativa da Região Autónoma da Madeira", "AMRAM", "Bandeira Azul" e "Município Amigo do Desporto", contêm texto com dimensão reduzida, dificultando a sua leitura e identificação pelos utilizadores. (Figura 01)

    Image

    Figura 01 — Alguns logótipos apresentados na página inicial contêm texto com dimensão reduzida.

    URLs a verificar:

    Recomendações:

    Garantir que o texto presente nos logótipos mantém uma dimensão adequada à sua leitura, assegurando a legibilidade da informação apresentada. Sempre que necessário, disponibilizar a mesma informação em formato textual complementar.

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:

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #64 Excesso de opções no subnível do menu de navegação

    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:

    O menu de navegação principal inclui um subnível com 12 opções disponíveis, ultrapassando o número recomendado para uma navegação clara e eficiente. Este excesso de escolhas pode dificultar a compreensão da estrutura do website, aumentar a carga cognitiva dos utilizadores e tornar a localização de conteúdos mais lenta e confusa.

    Image

    Imagem do subnível do menu principal com 12 opções.

    Image

    Imagem do menu do rodapé com 11 e 12 opções nos seus links

    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.

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

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

Lista de evidências recolhidas:

  • issue #74 Destino da navegação não corresponde ao percurso selecionado

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

    Ao efetuar o percurso Investir → Financiamento e Benefícios → Financiamento IFRRU, o utilizador é redirecionado para a página Investir → Oportunidades → IFRRU 2020.

    O destino apresentado não corresponde à estrutura de navegação escolhida pelo utilizador, criando uma inconsistência entre o percurso selecionado e a localização final da página. Esta situação pode gerar confusão relativamente à organização dos conteúdos e dificultar a compreensão da arquitetura de informação do website.

    Image

    URLs a verificar:

    Recomendações:

    • Garantir que o destino das opções de navegação corresponde ao percurso selecionado pelo utilizador.
    • Rever a estrutura de navegação e a categorização do conteúdo relacionado com o IFRRU, assegurando consistência entre menus, breadcrumbs e páginas de destino.
    • Caso a página pertença efetivamente à secção "Oportunidades", ajustar o menu para refletir essa organização ou disponibilizar um percurso de navegação coerente.
    • Validar que a localização apresentada ao utilizador corresponde sempre ao caminho utilizado para aceder ao conteúdo.

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 #63 Hiperligações percetíveis apenas com hover

    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:

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

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

    Image

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

    Image

    Imagem dos breadcrumbs sem indicação visual de hiperligação

    URLs a verificar:

    Recomendações:

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

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:

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: 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 Município de 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.

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

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.2

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

    Evidências:

    Verificámos que, na página inicial do website do Município de Machico, alguns elementos interativos apresentam dimensões inferiores aos 44px × 44px recomendados.

    Entre os casos identificados encontram-se os acessos a "Machico Informa", "Pesquisa", "Documentos", "Facebook", "Nossos Vídeos", "Contactos" e "Área Pessoal".

    A título de exemplo, o acesso ao Facebook apresenta uma largura de 18px, valor inferior à dimensão mínima recomendada para elementos interativos. (Figura 01)

    Image

    Figura 01 — O acesso ao Facebook apresenta uma largura de 18px, inferior à dimensão mínima recomendada de 44px.

    Verificámos que o botão "Voltar ao topo" apresenta uma dimensão de 40px × 40px, valor inferior à dimensão mínima de 44px × 44px recomendada para elementos interativos. (Figura 02)

    Image

    Figura 02 — O botão "Voltar ao topo" apresenta uma dimensão de 40px × 40px.

    Os indicadores de navegação do banner principal com uma dimensão de 20px × 8px, dificultando a sua utilização, especialmente em dispositivos de toque. (Figura 03)

    Image

    Figura 03 — Um dos indicadores de navegação do banner principal apresenta uma dimensão de 20px × 8px.

    Verificámos que, na página Reabilitação Urbana, os ícones das redes sociais apresentam dimensões inferiores aos 44px × 44px recomendados para elementos interativos.
    Foi identificado um ícone com uma dimensão de 30px × 34,70px, valor inferior ao mínimo recomendado. (Figura 04)

    Image

    Figura 04 — Um dos ícones das redes sociais apresenta uma dimensão de 30px × 34,70px.

    Verificámos que, na página O Presidente da Câmara, a caixa de seleção utilizada para aceitação da política de privacidade apresenta uma altura de 28,36px, valor inferior à dimensão mínima de 44px × 44px recomendada para elementos interativos. (Figura 05)

    Image

    Figura 05 — A caixa de seleção da política de privacidade apresenta uma altura de 28,36px.

    Verificámos que, na página Reuniões de Câmara, os botões de radio buttons apresentam dimensões inferiores aos 44px × 44px recomendados para elementos interativos.
    Foi identificado um botão com uma altura de 22,4px, valor inferior ao mínimo recomendado. (Figura 06)

    Image

    Figura 06 — Um dos botões de opção apresenta uma altura de 22,4px.

    Verificámos que, na página Notícias e Destaques, os elementos de paginação apresentam dimensões inferiores aos 44px × 44px recomendados para elementos interativos.
    Foi identificado um elemento de paginação com uma dimensão de 27px × 28,95px, valor inferior ao mínimo recomendado. (Figura 07)

    Image

    Figura 07 — Um dos elementos de paginação apresenta uma dimensão de 27px × 28,95px.

    URLs a verificar:

    Recomendações:

    Aumentar a área de interação dos elementos identificados, garantindo que podem ser acionados com maior facilidade em dispositivos de toque. Sempre que necessário, a área clicável deverá ser ajustada de forma a cumprir a dimensão mínima recomendada de 44px × 44px, mesmo nos casos em que a dimensão visual do elemento se mantenha inalterada.

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 #51 Hierarquia visual insuficiente entre ações principais e elementos informativos

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.3

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

    Evidências:

    Verificámos que, na janela de gestão de cookies do website Município de Machico, o botão "Guardar e Fechar" não se destaca de forma suficiente dos restantes elementos interativos disponíveis, nomeadamente das opções de seleção das categorias de cookies. Esta situação pode dificultar a identificação da ação principal da interface. (Figura 01)

    Image

    Figura 01 — O botão "Guardar e Fechar" apresenta o mesmo estilo visual dos restantes elementos interativos da janela de gestão de cookies.

    Verificámos que, na página Notícias e Destaques, a hierarquia visual das ações de filtragem não é clara.

    A ação principal "Limpar filtro" é apresentada apenas como texto, enquanto a ação secundária "Voltar atrás" surge destacada sob a forma de botão. (Figura 02)

    Image

    Figura 02 — A ação principal "Limpar filtro" apresenta menos destaque visual do que a ação secundária "Voltar atrás".

    URLs a verificar:

    Recomendações:
    Garantir que a ação principal de cada interface se destaca visualmente das restantes ações disponíveis.
    Os botões principais deverão apresentar maior destaque visual do que ações secundárias ou elementos auxiliares, permitindo aos utilizadores identificar facilmente a ação prioritária em cada contexto.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #52 Elementos interativos com contraste insuficiente relativamente ao fundo

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.4

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

    Evidências:

    Verificámos que, na janela de gestão de cookies do website Município de Machico, nomeadamente na secção "Mostrar Detalhes", os seletores das categorias de cookies apresentam um contraste insuficiente face ao fundo onde se encontram inseridos.
    Foi identificado um rácio de contraste de 2.76:1, valor inferior ao mínimo recomendado. (Figura 01)

    Image

    Figura 01 — Os seletores das categorias de cookies apresentam um rácio de contraste de 2.76:1.

    Verificámos que alguns botões da página inicial do website Município de Machico, nomeadamente os botões "Ver Eventos", "Contactos" e os botões da secção "Consulta Pública - Machico Informa", apresentam um contraste insuficiente no estado hover.

    A título de exemplo, o botão "Ver Todos" apresenta um rácio de contraste de 2.45:1 quando se encontra em estado hover, valor inferior ao mínimo recomendado. (Figura 02)

    Image

    Figura 02 — O botão "Ver Todos" apresenta um rácio de contraste de 2.45:1 no estado hover.

    Os indicadores de navegação do banner principal apresentam um contraste insuficiente face ao fundo onde se encontram inseridos. Foi identificado um rácio de contraste de 2.28:1, valor inferior ao mínimo recomendado. (Figura 03)

    Image

    Figura 03 — Um dos indicadores de navegação do banner principal apresenta um rácio de contraste de 2,28:1.

    URLs a verificar:

    Recomendações:

    Garantir que os elementos gráficos interativos mantêm um contraste suficiente face ao fundo onde se encontram inseridos, incluindo diferentes estados de interação, como o estado hover.
    Esta verificação deverá abranger indicadores de navegação, seletores, botões e outros controlos gráficos, assegurando a sua identificação e utilização em todas as situações.

  • issue #46 Elementos interativos sem diferenciação visual clara ou comportamento consistente de interação

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.4

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

    Evidências:

    Verificámos que, na página inicial do website Município de Machico, existem alguns elementos gráficos interativos que não apresentam indicadores visuais suficientes da sua interatividade, dificultando a identificação da sua funcionalidade por parte dos utilizadores.

    Os logótipos das distinções e certificações apresentados na área inferior do destaque principal funcionam como hiperligações, mas são apresentados apenas como imagens, sem qualquer elemento visual que indique a sua interatividade.
    Esta situação pode dificultar a identificação destes elementos como clicáveis. (Figura 01)

    Image

    Figura 01 — Os logótipos funcionam como hiperligações, mas não apresentam elementos visuais que indiquem a sua interatividade.

    As imagens apresentadas na secção "Machico Apoia" funcionam como hiperligações para conteúdos relacionados, mas não apresentam elementos visuais que permitam identificar a sua interatividade. (Figura 02)

    Image

    Figura 02 — As imagens da secção "Machico Apoia" funcionam como hiperligações, mas não apresentam indicadores visuais de interatividade.

    Verificámos que, na página Turismo, existem imagens interativas que não apresentam indicadores visuais suficientes da sua interatividade.
    Apesar da indicação textual "Clique nas imagens abaixo para visualizar as estatísticas", as imagens apresentam-se como conteúdo estático, dificultando a sua identificação como elementos clicáveis. (Figura 03)

    Image

    Figura 03 — As imagens não apresentam indicadores visuais suficientes da sua interatividade.

    Verificámos que, na página Regimento Municipal, o botão "Regimento (brevemente...)" apresenta-se como um elemento interativo, mas ao ser acionado não produz qualquer resultado nem fornece informação adicional ao utilizador.
    Esta situação pode gerar expectativas incorretas relativamente à disponibilidade do conteúdo associado. (Figura 04)

    Image

    Figura 04 — O botão "Regimento (brevemente...)" não produz qualquer resultado quando acionado.

    Verificámos que, na página Notícias e Destaques, a ação "Limpar Filtro" é apresentada com uma aparência semelhante à de um elemento textual, não apresentando indicadores visuais suficientes da sua interatividade.
    Esta situação pode dificultar a identificação da funcionalidade por parte dos utilizadores. (Figura 05)

    Image

    Figura 05 — A ação "Limpar Filtro" não apresenta indicadores visuais suficientes da sua interatividade.

    Verificámos que, no rodapé da página inicial do website Município de Machico, os textos "Telefones/Fax", "Funcionamento" e "Dia do Concelho" são apresentados com sublinhado, apesar de não possuírem qualquer funcionalidade associada.
    Esta apresentação pode levar os utilizadores a interpretá-los como hiperligações ou elementos interativos, criando expectativas de interação que não são correspondidas. (Figura 06)

    Image

    Figura 06 — Alguns textos do rodapé são apresentados com sublinhado, apesar de não possuírem qualquer funcionalidade associada.

    URLs a verificar:

    Recomendações:

    Garantir que os elementos interativos apresentam indicadores visuais claros da sua funcionalidade, permitindo aos utilizadores identificar facilmente os conteúdos clicáveis. Da mesma forma, elementos sem qualquer ação associada não devem utilizar estilos visuais normalmente reservados a hiperligações ou controlos interativos, evitando criar expectativas de interação que não são correspondidas.

Checklist Transação

etiqueta: NOK

Nível de conformidade:

  • Checklist Transação: 77.8% (7/9)
    • Requisitos avaliados: 13 (4 N/A excluídos, 9 aplicáveis)
    • Requisitos OK: 7
    • Requisitos NOK: 2
    • 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 #9 Não foram encontrados formulários com mais de 2 ecrãs no website

    etiqueta: R 1.2etiqueta: chk transaçãoetiqueta: 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 Câmara Municipal de 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 #10 Não foram encontrados formulários com mais de uma página

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

    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 Câmara Municipal de 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: OK (no entanto contém 1 melhoria que se recomenda efetuar)

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #13 Não é possível identificar campos obrigatórios nos formulários em PDF

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

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

    Evidências:

    Verificámos que, no Formulário de Candidatura, os campos de preenchimento obrigatório não se encontram identificados de forma clara.

    Não é disponibilizada qualquer indicação visual que permita distinguir os campos obrigatórios dos restantes campos do formulário, dificultando a identificação da informação que deve obrigatoriamente ser fornecida pelos utilizadores.

    Sempre que possível, recomenda-se a disponibilização destes formulários diretamente em páginas web, em vez de exclusivamente em formato PDF. Em formulários web, os campos obrigatórios devem ser corretamente identificados através de atributos como required ou aria-required="true", garantindo a sua perceção por tecnologias de apoio.

    Adicionalmente, deve também ser apresentada uma indicação visual clara junto ao rótulo — por exemplo, “(Campo obrigatório)” — para que todos os utilizadores consigam identificar facilmente os campos que têm obrigatoriamente de preencher

    Image

    Figura 01 — O formulário não apresenta uma identificação clara dos campos de preenchimento obrigatório.

    URLs a verificar:

    Recomendações:

    Recomenda-se que os campos obrigatórios dos formulários PDF sejam identificados de forma clara e consistente, tanto visualmente como para tecnologias de apoio, permitindo a sua correta perceção por todos os utilizadores.

    Uma sugestão é ser disponibilizar os formulários diretamente em páginas web, garantindo melhor compatibilidade com leitores de ecrã e restantes requisitos de acessibilidade.

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

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

    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 3.2 - Deve ser confirmado o sucesso da transação/envio de informação

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

Lista de evidências recolhidas:

  • issue #6 Feedback após submissão não anunciado de forma imediata

    etiqueta: melhoriaetiqueta: R 3.2etiqueta: 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 submissão do formulário, a mensagem de confirmação é disponibilizada na página e posteriormente anunciada pelo leitor de ecrã.

    Contudo, antes da leitura da mensagem de resposta, o leitor de ecrã anuncia conteúdos intermédios não relacionados, atrasando o acesso imediato ao feedback da submissão. A mensagem de sucesso deveria ser apresentada e anunciada de forma imediata e contextual ao utilizador.

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

    Image

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

    URL a verificar:

    Recomendações:

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

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

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

    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 #68 Existem mensagens de erro que não ajudam na resolução do problema

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

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

    Evidências:

    Validado que a mensagem de erro apresentada no campo “Contacto de telefone”, no formulário indica apenas que “O contacto está incorreto.” No entanto, a mensagem não informa de forma clara quais os passos necessários para corrigir o erro. As mensagens de erro devem ser claras, sucintas e indicar concretamente como o utilizador pode resolver o problema.

    Image

    URLs a verificar:
    https://cm-machico.pt/municipal/machico-envolve/elogios-e-reclamacoes

    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:

  • issue #78 Outras Violações - Problemas de contraste na Revista online

    etiqueta: melhoriaetiqueta: outras violações

    Evidências:

    Na página da Revista Municipal, os ficheiros disponibilizados da revista online, disponibilizam conteúdos com textos em imagens que apresentam problemas de contraste. Por exemplo, os textos inseridos na secção “Ambiente” da 5º Edição apresentam problemas de contraste, a análise de contraste evidencia a taxa de contraste de apenas 2:1, e compromete a legibilidade dos conteúdos textuais. (Figura 1)

    Image

    Figura 1 - Revista Municipal com problemas de contraste.

    URLs a verificar

    Recomendações:

    Sugerimos revisar as combinações de cores para que os textos fiquem mais legíveis. Em alguns casos, é necessário alterar a cor de plano de fundo para garantir as boas práticas e garantir a boa legibilidade do conteúdo.

    • Caso exista texto grande com pouco contraste, em que as cores utilizadas sejam as mesmas do logótipo da entidade, recomendamos a substituição dessas cores por outras que garantam um contraste mínimo de 3:1. Por exemplo, podem ser usados tons semelhantes ao do logotipo ou outras cores da identidade gráfica da marca.

  • issue #77 Outras Violações - Política de cookies disponibilizada em formato PDF através de viewer externo

    etiqueta: melhoriaetiqueta: outras violações

    Evidências:

    No rodapé do website, o link para a Política de Cookies não direciona para uma página HTML dedicada, mas sim para um ficheiro PDF aberto através de um viewer externo:

    <a href="https://balcaomunicipal.cm-machico.pt/templates/viewer/js/pdfjs/web/viewer.html?...">

    Este comportamento faz com que o utilizador seja redirecionado para uma interface externa de visualização de PDF, em vez de uma página web estruturada dentro do próprio website.

    Image

    Figura 1 - Acesso à Política de Cookies através de viewer PDF externo

    A disponibilização de conteúdos legais em formato PDF pode limitar a acessibilidade e a navegação, uma vez que estes documentos não beneficiam da estrutura semântica de uma página HTML (títulos, landmarks, navegação por teclado e adaptação responsiva). Adicionalmente, a utilização de um viewer externo introduz uma mudança de contexto na navegação.

    URLs a verificar:

    Recomendações:

    • Disponibilizar a Política de Cookies em formato de página HTML dedicada;
    • Garantir que o conteúdo é estruturado semanticamente (títulos, secções e navegação por teclado);
    • Opcionalmente, manter o PDF como formato alternativo para download, mas não como formato principal de leitura;
    • Evitar a utilização de viewers externos como ponto de acesso principal a conteúdos institucionais.

  • issue #75 Outras Violações - Menu secundário não reaparece após interação de scroll em páginas curtas

    etiqueta: melhoriaetiqueta: outras violações

    Evidências:

    Em determinadas páginas interiores, verifica-se que o menu secundário (barra lateral) deixa de ser apresentado após interação de scroll. Após o utilizador navegar até ao rodapé e regressar ao topo da página, o menu lateral não volta a ser exibido, sendo necessário recarregar a página para restaurar o seu estado inicial.

    Foi identificado que o elemento responsável pela sidebar (<section id="g-sidebar-a">) passa a apresentar a propriedade inline display: none, permanecendo oculto após a interação:

    <section id="g-sidebar-a" style="display: none;">

    Este comportamento indica uma alteração dinâmica do estado de visibilidade do elemento que não é revertida após o evento de scroll ou reposicionamento na página.

    Image

    Figura 1 - Elemento da sidebar com display: none aplicado após interação de scroll

    A ausência do menu secundário compromete a consistência da navegação e o acesso a conteúdos estruturantes da página. O utilizador pode deixar de ter acesso a opções contextuais importantes sem uma ação adicional (recarregamento da página), afetando a previsibilidade da interface.

    URLs a verificar:

    Recomendações:

    • Rever o comportamento dinâmico que aplica display: none ao elemento da sidebar;
    • Garantir que o estado de visibilidade do menu secundário é corretamente restaurado após eventos de scroll;
    • Assegurar consistência na renderização da barra lateral sem necessidade de recarregamento da página;
    • Validar o comportamento em diferentes alturas de conteúdo e resoluções de ecrã.

  • issue #73 Outras Violações - Conteúdos incompletos/vazios nas páginas interiores

    etiqueta: melhoriaetiqueta: outras violações

    Evidências:

    Na página “Membros do Executivo”, verificam-se conteúdos com informação incompleta ou não desenvolvida, nomeadamente na secção de “Notas Biográficas”.

    Em alguns perfis de membros do executivo, a área destinada à biografia apresenta apenas o texto “Brevemente...”, sem conteúdo informativo adicional disponível para o utilizador.

    Esta situação resulta na apresentação de uma secção estruturalmente existente, mas semanticamente vazia do ponto de vista informativo, podendo gerar expectativas de conteúdo que não se encontram cumpridas.

    Image

    Figura 1 - Secção de Notas Biográficas com conteúdo não desenvolvido (“Brevemente...”)

    A presença de conteúdos incompletos pode afetar a experiência de utilização, uma vez que o utilizador é exposto a uma área de informação que aparenta estar em falta ou em desenvolvimento. Em contexto institucional, este tipo de ausência de conteúdo pode comprometer a clareza e a completude da informação disponibilizada.

    URLs a verificar:

    Recomendações:

    • Garantir que todas as secções de conteúdo visíveis possuem informação efetiva e completa;
    • Substituir mensagens temporárias como “Brevemente...” por conteúdo informativo real ou remover a secção até existir informação disponível;
    • Caso o conteúdo ainda esteja em desenvolvimento, considerar ocultar a secção para evitar exposição de áreas vazias na interface.

Significado das etiquetas utilizadas