Relatório Avaliação de Candidatura
Assembleia Municipal de Machico

Introdução

O website https://am.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: OK
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 aspetos37.0% (10/27)etiqueta: Não passa
Conteúdo17.6% (3/17)etiqueta: Não passa
Transação55.6% (5/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: OK

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: 37.0% (10/27)
    • Requisitos avaliados: 27 (27 aplicáveis)
    • Requisitos OK: 10
    • Requisitos NOK: 17

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

    etiqueta: chk 10 webetiqueta: R 1.1etiqueta: NOK

    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:

    Image

    Opção do menu "Assembleia Informa" 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 #68 Menu mobile/tablet não acessível por teclado e leitores de ecrã

    etiqueta: R 1.2etiqueta: chk 10 webetiqueta: NOK

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

    Evidências:

    Nos menus de navegação (versão mobile), verificámos que alguns controlos utilizados para expandir ou colapsar o menu foram implementados através de elementos genéricos <div>, apesar de representarem ações de interface.

    Foram observados, por exemplo, controlos para abrir/fechar e fechar o menu mobile estruturados com elementos <div> clicáveis, em vez de elementos semanticamente adequados para ações, como <button>.

    Como consequência, a função destes controlos não é transmitida nativamente às tecnologias de apoio, dependendo de comportamento JavaScript adicional para simular interatividade. Quando os estilos CSS são removidos, também não é possível reconhecer claramente que estes elementos representam ações acionáveis.

    Image

    Imagem do botão do menu como <div> em vez de botão

    URLs a verificar:

    Recomendações:

    Recomendamos a substituição dos elementos <div> utilizados como controlos de interface por elementos semânticos <button type="button">, adequados a ações de expansão, colapso e fecho de menus.

    Garantir que os botões mantêm toda a funcionalidade existente, incluindo:

    • foco acessível e visível;
    • comportamento consistente em diferentes tecnologias de apoio;
    • identificação clara do propósito do controlo através de nome acessível apropriado.

    Adicionalmente, recomendamos a exposição programática do estado expandido/recolhido dos menus através de atributos adequados, como aria-expanded, sempre que aplicável.

    Validar o comportamento com navegação por teclado e leitores de ecrã para garantir que a função dos controlos é corretamente anunciada e operável.

  • issue #64 Os menus não estão estruturados como uma navegação de forma apropriada

    etiqueta: R 1.2etiqueta: chk 10 webetiqueta: NOK

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

    • Todos os menus 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 #69 O menu mobile não contêm texto alternativo

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.3

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

    Evidências:

    O botão utilizado na versão mobile para abrir e fechar o menu não possui texto alternativo acessível. Como consequência, os leitores de ecrã não conseguem identificar nem anunciar corretamente a sua presença ou função, dificultando a navegação para utilizadores de tecnologias de apoio.

    Image

    Imagem do botão do menu sem qualquer texto alternativo.

    URLs a verificar:

    Recomendações:

    • Adicionar o nome acessível como aria-label="Menu" e aria-label="Fechar".
    • Alterar o botão para

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #49 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://am.cm-machico.pt/acessibilidade

    Recomendações:

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

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

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

    etiqueta: R 4.1etiqueta: chk 10 webetiqueta: 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 #23 Não há informação clara sobre o que é o asterisco nos campos de preenchimento obrigatório

    etiqueta: R 4.2etiqueta: chk 10 webetiqueta: NOK

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

    Evidências:

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

    Verificámos que no formulários "Fale com a Assembleia" não existe informação sobre o significado do asterisco (*) colocado à frente dos campos.

    Image

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

    URLs a verificar:

    Recomendações:

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

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #19 Imagens decorativas não possuem atributo alt=""

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.1

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

    Evidências:

    Verifica-se que algumas imagens decorativas não possuem o atributo alt definido. Mesmo quando a imagem não transmite informação relevante, o atributo alt deve estar presente e nulo (alt="").

    Image

    URLs a verificar:
    https://am.cm-machico.pt/parlamento-jovem/parlamento-jovem-municipal-de-machico

    Recomendações:
    Quando as imagens forem decorativas e não transmitirem informação relevante, o atributo alt deve estar presente e vazio (alt=""). Por outro lado, quando as imagens transmitirem informação necessária para a compreensão do conteúdo, o atributo alt deve ser preenchido com uma descrição adequada e significativa.

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

    etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 5.1

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

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

    Image

    Verifica-se que algumas imagens também possuem nome acessível por meio do atributo title. Nesses casos, além de definir o atributo alt como nulo (alt=""), quando a imagem for meramente decorativa, recomenda-se remover o atributo title, evitando que tecnologias assistivas anunciem informações redundantes ou desnecessárias.

    Image

    URLs a verificar:

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

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.2

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

    Evidências:

    Verificou-se que a imagem apresenta informação textual relevante sobre as comemorações do Dia do Concelho de Machico, incluindo data, enquadramento e programação do evento. No entanto, essa informação encontra-se apenas incorporada na própria imagem, sem texto associado na página que reproduza ou descreva integralmente o conteúdo apresentado.

    Image

    URLs a verificar:
    https://am.cm-machico.pt/assembleia-informa/noticias/detalhe/757-dia-do-concelho-de-machico-8-de-maio

    Recomendações:
    A imagem deve ser acompanhada de uma descrição longa, disponibilizada como texto na própria página, de modo a transmitir todas as informações relevantes presentes no conteúdo visual.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #58 Imagem estruturada indevidamente como item de navegação

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.3

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

    Evidências:
    Verifica-se que a imagem estruturada como link para o “Portal da Assembleia” não direcciona o utilizador para uma página específica. A imagem aparenta ter uma função meramente visual ou decorativa, funcionando como elemento de contexto para o link “Fale com a Assembleia”.

    Também verifica-se que a imagem do “Portal da Assembleia” e o link “Fale com a Assembleia” estão estruturados como elementos separados dentro da lista, em itens <li> distintos. No entanto, visualmente aparentam fazer parte do mesmo bloco de conteúdo, o que pode causar ambiguidade para utilizadores de tecnologias de apoio, ao serem apresentados como opções independentes.

    Image

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

    Recomendações:

    • Recomenda-se que a imagem-link seja reestruturada como uma imagem decorativa, uma vez que não representa uma opção de navegação autónoma. Para isso, a tag <a> que contém a imagem e seus respectivos textos deve ser substituída por uma <div> com o atributo aria-hidden="true".
    • Adicionalmente, deverá ser removido do CSS o atributo cursor: pointer, uma vez que o elemento deixa de ser interactivo.
    • A nova <div> deverá ser posicionada estruturalmente dentro do mesmo item de lista <li> do link “Fale com a Assembleia”. Desta forma, a lista passará a apresentar apenas uma opção de navegação, evitando que a imagem seja interpretada como um link separado por tecnologias de apoio.

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

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.3

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

    Evidências:
    Verifica-se que no cabeçalho da página, as imagens/ícones de acesso à Pesquisa e Contactos 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. 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.

    Image

    Verifica-se que as imagens-link de logótipos institucionais, apresentam um atributo alt insuficiente ou abreviado (“RAM”), que não descreve claramente o destino ou finalidade do link (ex.: alt="Região Autônoma da Madeira").

    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 (), através do atributo alt, uma vez que é ela que representa visualmente o logotipo e identifica o destino do link.

    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. Por exemplo: alt="Assembleia Municipal de Machico | Governação Local – página inicial".
    Também foi identificado que o nome acessível está a ser definido de forma redundante através dos atributos title e aria-label no elemento <a>. O nome acessível deve ser mantido apenas no atributo alt da imagem.

    Image

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

    Recomendações:

    • O texto alternativo deve transmitir claramente o destino ou finalidade do link.
    • Para as imagens de logotipo utilizadas como link, recomenda-se remover o atributo title do elemento <a>, manter o nome acessível através do atributo alt.
    • 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.

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 #66 O texto normal não têm contraste suficiente em certos estados

    etiqueta: R 6.1etiqueta: chk 10 webetiqueta: melhoria

    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 apresenta problemas de contraste no estado de hover do menu principal, onde texto normal utiliza a combinação de cores #009ddc(cor de primeiro plano) e #FFFFFF(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,1:1

    Além disso, há problemas de contraste nos estados de hover das hiperligações, por exemplo na página Diretório de documentos onde utilizam no texto normal as cores #0099D9(cor de primeiro plano) e #E1E1E1(cor de plano de fundo). Segue alguns exemplos de problemas de contrastes nas hiperligações (Figura 2 e 3)

    Image

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

    Image

    Figura 3- Estado de hover dos textos da página Diretório de Documentos com baixo contraste

    Image

    Figura 4 - Menu principal possui hiperligações com problemas de contraste no estado de hover

    Esta implementação dificulta a 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 #65 Texto normal não têm contraste suficiente

    etiqueta: R 6.1etiqueta: chk 10 webetiqueta: NOK

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

    Evidências

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

    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 de cor no menu principal, especificamente na opção “Institucional”. Os itens “Assembleia Municipal”, “Composição”, “Informações úteis” e “Portal da Assembleia” utilizam as combinações de cores #FFFFFF(cor de primeiro plano) e #009DDC(cor de plano de fundo) o que torna os textos pouco visíveis. (Figura 1)

    Image

    Figura 1- Problemas de contraste no menu principal

    Adicionalmente, o mesmo problema é observado em textos de hiperligações ao longo do website, com a taxa de contraste inferior ao recomendado comprometendo a percepção do conteúdo. (Figura 2)

    Image

    Figura 2 - Texto normal de hiperligações com uma taxa de apenas 3,06:1

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

    Image

    Figura 3- 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 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 #9 Formulário de pesquisa avançada exposto ao leitor de ecrã antes de estar visível em mobile

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.2

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

    Evidências:

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

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

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

    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 #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 #18 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 #17 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.

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://am.cm-machico.pt/institucional/assembleia-municipal/fale-com-a-assembleia

    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.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 #41 Ao fechar a caixa de diálogo o cursor não retorna ao elemento que o acionou

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.4

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

    Evidências:
    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 Image

    URLs a verificar:
    https://am.cm-machico.pt/institucional/assembleia-municipal/fale-com-a-assembleia

    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 #73 Não foi possível extrair o conteúdo textual para formato TXT

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

    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.

    Image

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

    URLs a verificar:

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

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

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

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

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

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

    Evidencias:

    Verificámos que, na página Mesa da Assembleia, alguns elementos textuais apresentam um tamanho inferior ao mínimo recomendado de 16 px (12 pt).

    Os textos dos botões "Informações" e "Notas Biográficas" são apresentados com um tamanho de 15 px, comprometendo a legibilidade do conteúdo.

    Image

    Figura 01 — Os botões "Informações" e "Notas Biográficas" apresentam texto com tamanho de 15 px.

    Verificou-se que, na página Diretório de documentos, o elemento "Limpar filtro" apresenta um tamanho de texto de 12 px, inferior ao mínimo recomendado de 16 px (12 pt).
    Esta situação compromete a legibilidade e a facilidade de leitura do conteúdo. (Figura 02)

    Image

    Figura 02 — O elemento "Limpar filtro" apresenta texto com tamanho de 12 px.

    URLs a verificar:

    Recomendações:

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

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

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

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

    Evidencias:

    Verificámos que a página Mesa da Assembleia apresenta inconsistências na adaptação dos tamanhos de texto em dispositivos móveis.
    Em resoluções mais reduzidas, alguns links e elementos textuais são apresentados com dimensões inferiores às recomendadas, comprometendo a legibilidade e dificultando a leitura do conteúdo.

    os botões "Informações" e "Notas Biográficas" apresentam dimensões reduzidas em dispositivos móveis. (Figura 01)

    Image

    Figura 01 — Os botões "Informações" e "Notas Biográficas" apresentam dimensões reduzidas em dispositivos móveis.

    Image

    Verificou-se que, na página Diretório de documentos, alguns elementos não se adaptam corretamente a larguras de ecrã reduzidas. Em dispositivos móveis, as ações "Voltar atrás" e "Limpar filtro" são apresentadas com dimensões inferiores às recomendadas, comprometendo a legibilidade e dificultando a leitura do conteúdo. (Figura 02)

    Image

    Figura 02 — As ações "Voltar atrás" e "Limpar filtro" com dimensões inferiores às recomendadas.

    URLs a verificar:

    Recomendações:

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

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 #14 Legibilidade insuficiente do texto presente em logótipos institucionais e de distinções

    etiqueta: R 2.2etiqueta: melhoriaetiqueta: chk conteúdo

    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 Assembleia Municipal 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:

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

    Verificou-se que, na página Diretório de documentos, o texto "Parlamento Jovem Municipal"apresenta um espaçamento entre linhas de 20px para um tamanho de letra de 20px, não cumprindo o espaçamento mínimo recomendado de 1,5 vezes o tamanho da letra.
    Esta situação pode dificultar a leitura do conteúdo. (Figura 01)

    Image

    Figura 01 — O texto "Parlamento Jovem Municipal" apresenta um espaçamento entre linhas de 20px para um tamanho de letra de 20px.

    URLs a verificar:

    Recomendações:

    Ajustar o espaçamento entre linhas dos elementos textuais, garantindo uma altura de linha mínima correspondente a 1,5 vezes o tamanho da letra, de forma a melhorar a legibilidade e o conforto de leitura.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #59 Excesso de opções no menu do rodapé

    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 várias secções no rodapé ultrapassam este limite.

    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.2 - A navegação principal está sempre visível e sempre no mesmo local

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #61 Subopções do menu “Assembleia Informa” direcionam para a mesma página com filtros diferentes

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 3.2

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

    Evidências:

    A aba do menu “Assembleia Informa” apresenta várias subopções que direcionam todas para a página “Diretório de documentos”. A única diferença entre elas é o filtro “Categoria” aplicado automaticamente.

    Isto pode causar confusão na navegação, uma vez que o utilizador acredita estar a aceder a páginas diferentes, mas permanece na mesma página. Além disso, o breadcrumb mantém sempre a mesma localização, dificultando a perceção de contexto e estrutura do website.

    Image

    Na imagem os breadcrumbs estão apenas na página "Diretório de documentos", porém a navegação foi para "Assembleia Informa"->"Convocatórias".

    Para além disso, existe uma opção do filtro que não aparece no menu mas está presente em "Todos os arquivos", que é "Parlamento Jovem Municipal".

    Image

    Imagem da falta de opção do filtro no menu.

    URLs a verificar:

    Recomendações:

    • Simplificar o menu, mantendo apenas uma entrada para a página “Diretório de documentos”.
    • Avaliar, através de testes com utilizadores, a necessidade de transformar os filtros em navegação secundária.
    • Conter todas as opções do filtro "Categoria" na escolha de design utilizada.
    • Caso os filtros representem conteúdos distintos, cada opção deverá possuir uma página e URL próprias, garantindo contexto e navegação consistentes.

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:

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #51 Páginas extensas sem índice de navegação interna entre secções

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

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

    Evidências:

    Verificámos que a página Acessibilidade apresenta uma extensão superior a três ecrãs de altura, mas não disponibiliza um índice no topo da página com hiperligações internas para as diferentes secções do conteúdo.
    Esta situação dificulta a navegação e a localização rápida da informação pretendida. (Figura 01)

    Image

    Figura 01 — A página não disponibiliza um índice com hiperligações internas para as diferentes secções do conteúdo.

    URLs a verificar:

    Recomendações:

    Adicionar um índice no início das páginas mais extensas, com hiperligações internas para as principais secções do conteúdo. O índice deve refletir a estrutura da informação e permitir o acesso direto aos diferentes tópicos da página.

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 #52 Inconsistências de adaptação responsiva e apresentação de conteúdos em dispositivos móveis

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

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

    Evidências:

    Verificámos que, na página Pesquisar, o breadcrumb não é apresentado em determinadas larguras de ecrã na versão móvel do website. Esta situação dificulta a orientação do utilizador e a perceção da sua localização na estrutura do sítio Web, criando uma experiência de navegação inconsistente entre dispositivos. (Figura 01)

    Image

    Figura 01 — O breadcrumb não é apresentado na versão móvel da página Pesquisar.

    Verificou-se que, na página Notícias e Destaques, o botão "Pesquisa avançada" não é apresentado corretamente em algumas larguras de ecrã. Em dispositivos móveis, parte do elemento fica truncada, comprometendo a sua apresentação e a consistência visual da interface. (Figura 02)

    Image

    Figura 02 — O botão "Pesquisa avançada" é apresentado parcialmente truncado em visualização móvel.

    URLs a verificar:

    Recomendações:

    Garantir que todos os componentes da interface se adaptam corretamente às diferentes larguras de ecrã, preservando a sua apresentação e funcionalidade. Elementos como breadcrumbs, botões e controlos de navegação devem permanecer integralmente visíveis e operáveis em dispositivos móveis, sem cortes ou perda de informação.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    Na página inicial do website da Assembleia Municipal de Machico existe um elemento interativo no rodapé 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 #54 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, página inicial do website da Assembleia Municipal de Machico, alguns elementos interativos apresentam dimensões inferiores aos 44px × 44px recomendados.

    Os ícones associados às opções "Encontre a Informação que precisa" e "Contactos" apresentam uma dimensão de 35px.
    Por se tratarem de elementos interativos, a sua área acionável não cumpre a dimensão mínima de 44 × 44 px definida pelo presente critério, podendo dificultar a interação em dispositivos táteis. (Figura 01)

    Image

    Figura 01 — Os ícones "Encontre a Informação que precisa" e "Contactos" apresentam uma dimensão de 35px.

    O ícone associado ao botão "Consulte todas as plataformas digitais municipais" apresenta uma dimensão de 25 × 30 px.
    (Figura 02)

    Image

    Figura 02 — O ícone do botão "Consulte todas as plataformas digitais municipais" apresenta uma dimensão de 25 × 30 px.

    O botão "Contacto" apresenta uma altura de 32,60 px, inferior à dimensão mínima de 44 px definida pelo presente critério.
    (Figura 03)

    Image

    Figura 03 — O botão "Contacto" apresenta uma altura de 32,60 px.

    Verificámos que, na página Fale com a Assembleia, alguns elementos interativos apresentam dimensões inferiores aos 44px × 44px recomendados.

    A opção de aceitação da política de privacidade apresenta uma altura de 21,6 px, inferior à dimensão mínima de 44 × 44 px definida pelo presente critério. (Figura 04)

    Image

    Figura 04 — A opção de aceitação da política de privacidade apresenta uma altura de 21,6 px.

    Os ícones de partilha em redes sociais apresentam dimensões inferiores à dimensão mínima de 44 × 44 px definida pelo presente critério. A título de exemplo, o ícone de partilha para WhatsApp apresenta 30 × 32,9 px. (Figura 05)

    Image

    Figura 05 — O ícone de partilha para WhatsApp apresenta uma dimensão de 30 × 32,9 px.

    Na página Edital n.º 04/2026 - 2ª Sessão do Parlamento Jovem Municipal, os botões de navegação "Anterior" e "Seguinte" apresentam uma altura de aproximadamente 31,2 px, inferior à dimensão mínima de 44 px definida pelo presente critério. Esta situação pode dificultar a sua utilização, especialmente em dispositivos com interação por toque. (Figura 06)

    Image

    Figura 06 — Os botões "Anterior" e "Seguinte" apresentam uma altura de 31,2 px.

    URLs a verificar:

    Recomendações:

    Garantir que todos os elementos interativos dispõem de uma área acionável mínima de 44 × 44 px, aumentando a dimensão dos controlos ou a respetiva área de interação sempre que necessário.
    Deve ser dada especial atenção a ícones, botões de navegação, opções de formulários e elementos de partilha em redes sociais.

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

    Na página Notícias e Destaques, a ação "Voltar atrás" apresenta maior destaque visual do que a ação "Limpar filtro", através da utilização de um botão destacado. No contexto da pesquisa, a ação "Limpar filtro" corresponde à ação principal disponível para o utilizador, mas não apresenta qualquer destaque visual, comprometendo a hierarquia das ações na interface. (Figura 01)

    Image

    Figura 01 — A ação "Voltar atrás" apresenta maior destaque visual do que a ação "Limpar filtro".

    URLs a verificar:

    Recomendações:

    Rever a hierarquia visual das ações disponibilizadas na página, garantindo que a ação principal se encontra devidamente destacada e que as restantes ações assumem um papel secundário, de forma consistente e facilmente percetível pelos utilizadores.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    No menu "Institucional" da página inicial Assembleia Municipal de Machico, o elemento "Assembleia Municipal de Machico" apresenta-se visualmente como um botão interativo. No entanto, ao ser acionado, não executa qualquer ação nem conduz o utilizador para outro conteúdo. Esta situação cria uma expectativa de interação que não é correspondida pelo comportamento do elemento. (Figura 01)

    Image

    Figura 01 — O elemento "Assembleia Municipal de Machico" apresenta aspeto de botão, mas não executa qualquer ação quando acionado.

    Na página Notícias e Destaques, a ação "Limpar filtro" é apresentada visualmente como texto simples, sem características gráficas que permitam identificá-la claramente como um elemento interativo.
    Esta situação verifica-se também em dispositivos móveis, podendo dificultar a perceção da funcionalidade disponível e levar os utilizadores a não reconhecerem a possibilidade de repor os filtros aplicados. (Figura 02)

    Image

    Figura 02 — A ação "Limpar filtro" é apresentada como texto simples, sem indicação visual de interatividade.

    Na página inicial do website da Assembleia Municipal de Machico, os logótipos de entidades externas apresentados no rodapé funcionam como hiperligações, mas não apresentam características visuais que permitam identificá-los claramente como elementos interativos. (Figura 03)

    Figura 03 — Os logótipos do rodapé funcionam como hiperligações, mas não apresentam indicação visual clara de interatividade.

    URLs a verificar:

    Recomendações:

    Rever a apresentação dos elementos interativos, garantindo que os mesmos são facilmente identificáveis como clicáveis através de padrões visuais consistentes.
    Adicionalmente, assegurar que os elementos com aspeto de botão ou ligação executam efetivamente a ação esperada quando acionados.

Checklist Transação

etiqueta: NOK

Nível de conformidade:

  • Checklist Transação: 55.6% (5/9)
    • Requisitos avaliados: 13 (4 N/A excluídos, 9 aplicáveis)
    • Requisitos OK: 5
    • Requisitos NOK: 4
    • 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 #4 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 Assembleia 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 #5 Não foram encontrados formulários com mais de uma página

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

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

    Evidências:

    Não foram encontrados formulários com mais de uma página dentro do Assembleia 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: NOK

Lista de evidências recolhidas:

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

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

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

    Evidências:
    Verificámos que, o campo “Assunto que pretende abordar”, do formulário da página Fale com a Assembleia, ocupa quase toda a largura disponível do conteúdo principal.
    Da mesma forma, o campo “NIF” tem uma largura maior do que o necessário para o tipo de informação a introduzir. Em Portugal, o NIF tem sempre 9 dígitos, mas o campo transmite a ideia de que é possível (ou necessário) escrever mais caracteres.

    URL a verificar:
    Página Fale com a Assembleia

    Recomendações:
    Recomendamos a revisão dos campos dos formulários, garantindo que a largura dos campos está adequada ao tipo de informação a inserir.

    Image

    Figura – Formulário da página Fale com a Assembleia.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #43 Há campos dependentes que surgem desativados em vez de ocultos

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

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

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

    Evidências:
    No formulário da página Diretório de Documentos, o campo “Subcategoria” depende da seleção efetuada no campo “Categoria”. Atualmente, ambos os campos são apresentados desde o início. No entanto, o campo “Subcategoria” encontra-se desativado para interação por rato e teclado (Tab e Shift+Tab), mas continua a poder receber foco através da navegação por leitor de ecrã(setas direcionais).

    URL a verificar:
    Página Diretório de Documentos

    Recomendações:
    Recomendamos que o campo “Subcategoria” seja ocultado tanto visualmente como para leitores de ecrã enquanto não existir uma seleção válida no campo “Categoria”. O campo só deve tornar-se visível e acessível — na interface gráfica e para tecnologias de apoio — após o utilizador escolher uma categoria.

    Image

    Figura 1 – Análise do campo “Subcategoria”, do formulário da página Diretório de Documentos, através do Google Inspector.

    Image

    Figura 2 – Análise do campo “Subcategoria”, do formulário da página Diretório de Documentos, através do leitor de ecrã NVDA.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #45 Caixas de combinação não estão estruturadas de forma acessível

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

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

    Evidências:
    Verificámos que, nas comboboxes “Categoria” e “Subcategoria” presentes na página Diretório de Documentos, o leitor de ecrã não consegue aceder aos rótulos dos campos — quando o utilizador navega com Tab ou Shift+Tab — nem às opções disponíveis dentro de cada combobox. Quando o utilizador tenta navegar pelas opções, através das setas direcionais, o leitor de ecrã anuncia apenas “Em branco”, em vez de ler cada opção disponível.
    Isto significa que estas caixas de combinação não estão estruturadas de forma acessível.

    URL a verificar:
    Página Diretório de Documentos

    Recomendações:
    Sugerimos que estes componentes sejam reestruturados para garantir total compatibilidade com tecnologias de apoio.

    Como referência para uma implementação acessível de uma combobox, recomendamos consultar o exemplo da W3C Editable Combobox With Both List and Inline Autocomplete.

    Se concluírem que o número de opções não justifica o uso de uma combobox, podem optar por alternativas mais simples, como listas suspensas ou radio buttons. A página Creating Accessible Forms apresenta exemplos práticos de implementações acessíveis destes componentes.

    Image

    Figura 1 - Análise do campo "Categoria", na página Diretório de Documentos, através de Tab e Shift+Tab e do leitor de ecrã NVDA.

    Image

    Figura 2 - Análise das opções da combobox "Subcategoria", na página Diretório de Documentos, através do leitor de ecrã NVDA.

  • issue #44 Legenda do campo de pesquisa não é anunciada pelo leitor de ecrã nem aparece na interface

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

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

    Evidências:
    Verificámos que no campo de pesquisa da página para pesquisar por artigos, existe um elemento <label> dentro da estrutura do formulário, mas este não está a ser reconhecido pelo leitor de ecrã nem está visível na interface gráfica.

    URL a verificar:
    -Página Pesquisar | Motor de Busca

    Recomendações:
    Recomendamos que este campo seja reestruturado. Deve ser utilizado um elemento <label> para apresentar a legenda do campo (por exemplo, “Pesquisar:”), que deve ficar acessível para tecnologias de apoio e visível na interface gráfica, e um elemento <input> para o campo onde o utilizador escreve o termo de pesquisa.
    Como referência para uma implementação acessível, podem consultar o conteúdo dentro do cabeçalho “Text Inputs”, do artigo Creating Accessible Forms da WebAIM, onde é apresentado um exemplo claro de como estruturar corretamente este tipo de campo.

    Image

    Figura 1 – Análise do formulário para pesquisar por artigos através do Google Inspector.

    Image

    Figura 2 – Análise do formulário para pesquisar por artigos através do leitor de ecrã NVDA.

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

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

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

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

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 #2 Feedback após submissão não anunciado de forma imediata

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

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

    Evidências:

    Após submissão do formulário, a mensagem de confirmação é disponibilizada na página 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 #21 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.4 - As mensagens de erro devem mostrar os passos concretos para a resolução dos mesmos

etiqueta: NOK

Lista de evidências recolhidas:

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

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

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

    Evidências:
    Validado que a mensagem de erro apresentada no campo “Contacto de telefone”, no formulário Fale com a Assembleia 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://am.cm-machico.pt/institucional/assembleia-municipal/fale-com-a-assembleia

    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 #72 Outras Violações - Opção "Mapa do Site" sem funcionalidade associada

    etiqueta: outras violaçõesetiqueta: melhoria

    Evidências:

    Foi identificada a presença da opção "Mapa do Site" no rodapé do website.

    Contudo, este elemento não se encontra implementado como hiperligação nem disponibiliza qualquer página ou conteúdo associado, não sendo possível ao utilizador aceder a um mapa do site através desta opção.

    Como consequência, os utilizadores podem assumir que existe uma página de mapa do site disponível, mas não conseguem aceder ao conteúdo esperado.

    Image

    Figura 1 - Opção "Mapa do Site" apresentada no rodapé sem hiperligação ou conteúdo associado

    O mapa do site constitui frequentemente um mecanismo complementar de navegação que permite aos utilizadores obter uma visão global da estrutura do website e localizar conteúdos de forma mais eficiente.

    A disponibilização de uma opção sem funcionalidade associada pode gerar expectativas incorretas e causar frustração durante a navegação.

    URLs a verificar:

    Recomendações:

    • Implementar uma página de mapa do site acessível através da opção disponibilizada no rodapé;
    • Garantir que a opção "Mapa do Site" é apresentada como uma hiperligação funcional;
    • Em alternativa, remover a opção caso o website não disponibilize efetivamente esta funcionalidade;
    • Assegurar que todos os elementos apresentados como opções de navegação possuem um destino válido e funcional.

  • issue #71 Outras violações - Foco não está visível na navegação por teclado e leitor de ecrã

    etiqueta: outras violaçõesetiqueta: melhoria

    Evidências:
    Ao navegar pelo website utilizando apenas o teclado, nem sempre o indicador de foco se encontra visível, dificultando significativamente a navegação, em particular para utilizadores que dependem exclusivamente deste meio de interação.

    Durante a navegação sequencial através da tecla TAB, há algumas componentes que não são circunscritas pelo foco por exemplo durante a navegação por teclado nos cards da “Assembleia Informa".

    Image

    Figura 1 – Exemplo de ausência de foco visível na navegação por teclado

    Em alguns momentos o foco não é apresentado de forma perceptível, sendo apenas possível inferir a sua existência através da barra de estado do navegador, o que não constitui uma solução acessível nem adequada. Sendo assim não é possível identificar visualmente a posição do utilizador em cada momento da navegação. Esta situação pode levar o utilizador a perder a noção da sua posição na página, comprometendo a usabilidade e a acessibilidade do website.

    URLs a verificar:

    Recomendações:

    Garantir que todos os elementos interativos do website apresentam um indicador de foco visível, suficientemente contrastante e consistente, sempre que recebem foco através da navegação por teclado.

    • O estilo de foco deverá:
    • Ser claramente percetível visualmente (ex.: contorno, sublinhado ou mudança de cor);
    • Manter contraste adequado em relação ao fundo;
    • Não ser removido através de regras CSS como outline: none sem alternativa equivalente;
    • Acompanhar corretamente a ordem lógica da navegação por teclado.

    Esta melhoria é essencial para assegurar uma navegação acessível a utilizadores com deficiência visual, motora ou cognitiva

  • issue #56 Outras Violações - Ligações do rodapé direcionam incorretamente para a página inicial

    etiqueta: outras violaçõesetiqueta: melhoria

    Evidências:

    Foi identificado que várias ligações disponibilizadas no rodapé do website não direcionam para os conteúdos indicados pelo respetivo texto da ligação.

    Em diversos casos, ao ativar opções presentes nas secções “# Machico atua”, “# Machico apoia”, “# Machico envolve” e “# Machico informa”, o utilizador é encaminhado para a página inicial.

    Por exemplo, várias ligações apresentam URLs genéricas (/) ou encaminhamentos para conteúdos não correspondentes ao tema apresentado no texto da ligação, impossibilitando o acesso direto à informação esperada.

    Esta situação afeta a previsibilidade da navegação e pode levar os utilizadores a concluir incorretamente que os conteúdos não existem ou não estão disponíveis.

    Image

    Figura 1 - Ligações do rodapé que não direcionam para os conteúdos correspondentes

    A existência de ligações com destinos incorretos compromete a experiência de navegação e dificulta o acesso à informação disponibilizada pelo website. Os utilizadores são conduzidos para páginas inesperadas, sendo obrigados a procurar novamente os conteúdos pretendidos através de outros mecanismos de navegação.

    URLs a verificar:

    Recomendações:

    • Rever todas as ligações presentes no rodapé do website;
    • Garantir que cada ligação direciona para o conteúdo correspondente ao respetivo texto;
    • Remover ou ocultar temporariamente ligações para conteúdos que não se encontrem disponíveis;
    • Validar periodicamente o funcionamento das ligações para prevenir redirecionamentos incorretos ou conteúdos inexistentes.

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

    etiqueta: outras violaçõesetiqueta: melhoria

    Evidências:

    Na página “Membros Eleitos”, 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