Relatório Avaliação de Candidatura
PRR - Municipio da Madeira

Introdução

O website https://www.cm-sjm.pt/pt/acessibilidade 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 aspetos22.2% (6/27)etiqueta: Não passa
Conteúdo5.9% (1/17)etiqueta: Não passa
Transação27.3% (3/11)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.

Verificámos também que a Declaração de Acessibilidade não se encontra corretamente afixada. Consulte o capítulo "Declaração de acessibilidade" para saber o que tem de corrigir.

Declaração de Acessibilidade

etiqueta: NOK

De acordo com o artigo 8º do DL n.º 83/2018, todos os sítios web e todas as aplicações móveis têm de ostentar uma Declaração de Acessibilidade. A Declaração é o documento na qual a organização evidencia o trabalho levado a efeito para tornar os seus conteúdos e serviços digitais mais acessíveis, disponibilizando ainda contactos para ajuda adicional.

Lista de evidências recolhidas:

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: 22.2% (6/27)
    • Requisitos avaliados: 27 (27 aplicáveis)
    • Requisitos OK: 6
    • Requisitos NOK: 21

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 #5 As opções do rodapé não estão estruturadas como lista

    etiqueta: R 1.1etiqueta: NOKetiqueta: chk 10 web

    Quando os links de navegação são estruturados dentro de uma lista, os utilizadores de leitores de ecrã conseguem compreender de forma mais clara a organização e a hierarquia do conteúdo do website. Esta abordagem permite também que o leitor de ecrã anuncie o número total de opções disponíveis.

    O rodapé do website possui links que não estão estruturadas como listas:

    URL a verificar

    Sugestão de correção

    • Estruturar as opções de "Município", "Cidadão", "Investir" e "Visitante" como uma lista ul li no HTML.
    • O grupo de links Termos e Condições, Política de Privacidade, Política de Cookies, Acessibilidade e Livro de Reclamações Online devem ser estruturados também como lista ul li no HTML.

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 #24 O menu mobile não está acessível pelo teclado e leitor de ecrã

    etiqueta: R 1.2etiqueta: NOKetiqueta: chk 10 web

    Quando se navega com o leitor de ecrã ou com o teclado, não é possível aceder ao menu apresentado nas versões mobile e tablet. Isto acontece porque o menu está estruturado como uma div no HTML, em vez de ser implementado como um elemento interativo.

    O menu é o principal recurso de navegação do website, mas os leitores de ecrã não conseguem identificá‑lo nem saltar diretamente para ele, uma vez que não está estruturado como um elemento de navegação no HTML.

    Image

    Menu estruturado como div e não está definido como navegação nav

    Adicionalmente, verifica-se que as opções do menu estão estruturalmente separadas do botão de abrir/fechar menu um problema crítico para navegação por tecnologias de apoio:

    Image

    URL

    Sugestão de correção

    • Estruturar o menu como um button no HTML.
    • O botão deve ser estruturado dentro de uma navegação nav no HTML.
    • As opções do menu devem ser posicionadas estruturalmente a seguir ao botão de menu, garantindo que a ordem de leitura com o leitor de ecrã seja igual à ordem visual. Para mais informações, recomendamos analisar esta questão em conjunto com a issue #26 .

  • issue #23 Não é possível aceder as subopções do menu com o leitor de ecrã e teclado

    etiqueta: R 1.2etiqueta: NOKetiqueta: chk 10 web

    Quando se navega com o teclado e leitor de ecrã utilizando as teclas TAB e SHIFT+TAB, é possível identificar os seguintes problemas:

    1. As subopções do menu são automaticamente apresentadas, mesmo sem qualquer ação do utilizador para as expandir.
    Image
    1. Apesar das subopções serem visualmente apresentadas, não é possível selecioná‑las através do teclado (TAB ou setas direcionais).
    Image
    1. Com o leitor de ecrã, embora seja possível selecionar as subopções quando se navega com TAB e SHIFT+TAB, é necessário percorrer todas as subopções do menu, mesmo quando não é essa a intenção do utilizador. Por exemplo, para selecionar a opção “Transparência”, o utilizador é obrigado a passar por todas as subopções de “Município”, “Cidadão”, “Visitante” e “Investidor”:
    Image
    1. Quando se navega por elementos com o leitor de ecrã utilizando VO + Espaço (VoiceOver) ou as setas direcionais ↓↑ (NVDA) — não é possível abrir/fechar as subopções do menu (ENTER ou VO+ Espaço). Em vez de apresentar as subopções, é carregada diretamente a página correspondente. Por exemplo, ao ativar “Cidadão”, as suas subopções não são abertas; em vez disso, a página de “Cidadão” é imediatamente carregada.
    Image

    Isso acontece porque estão a ser atribuídas duas funções ao mesmo link a: por um lado, ele é utilizado para apresentar as subopções do menu no hover e foco; por outro, é também o elemento responsável por aceder as páginas do website:

    Image

    URL

    Sugestão de correção

    • É necessário verificar no menu compacto e desktop.
    • O mesmo elemento é utilizado simultaneamente para expandir/contrair subopções e para aceder a página interna, como por exemplo a de “Cidadão”, o que provoca erros de navegação. Por esse motivo, devem separar o link de navegação da página interna e do botão de abrir/fechar as subopções.
    • O elemento que abre e fecha as subopções deve ser um botão ▾. Caso optem em utilizar a sinalética ▾ para o botão, devem garantir que tenha um nome acessível apropriado, como por exemplo: "Abrir subopção de Município". Para mais informações recomendamos consultarem a issue #25 .
    • Devem utilizar o atributo aria-expanded apropriadamente para que os leitores de ecrã identifiquem se a opção está aberta ou fechada.
    • O acesso as páginas internas deve ser feito através de um link a.
    • Para mais informações partilhamos um exemplo de menu flyout da W3C: https://www.w3.org/WAI/tutorials/menus/flyout/#use-button-as-toggle

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 #25 As imagens-link do menu principal não têm texto alternativo

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.3

    Verifica‑se que a sinalética utilizada para indicar as subopções (▾) está a ser inserida via CSS e não possui texto alternativo:

    Image

    URL

    Sugestão de correção

    • A sinalética ▾ é uma informação primária e, por isso, não deve ser inserida via CSS. Por isso, deve ser estruturada como um botão, com um nome acessível adequado, como por exemplo: “Abrir subopções de Município”.
    • O menu apresenta problemas de acessibilidade; por isso, é importante analisar esta questão em conjunto com a issue #23 , garantindo que o texto alternativo utilizado é apropriado e que a estrutura esteja correta com o funcionamento do menu.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #60 Cabeçalho de tabela não está marcado com o elemento <th>

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 3.1

    O cabeçalho das tabelas no URL mencionado estão marcados como td. Para melhor identificar os cabeçalhos de uma tabela deve usar-se o elemento th de forma a melhor identificar os eixos que caracterizam a informação em cada célula.

    Evidências:

    Image

    Figura 1 - exemplo de tabela com o cabeçalho marcado com td.

    URLs a verificar:

    https://www.cm-sjm.pt/pt/noticias/ambiente/candidaturas-ao-vale-eficiencia-e-edificios-sustentaveis

    Recomendações:

    Alterar o cabeçalho da tabela para th.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #59 R 3.2 - 10 Aspetos -Tabelas não apresentam legenda descritiva

    etiqueta: R 3.2etiqueta: NOKetiqueta: chk 10 web

    As tabelas no URL mencionado não apresentam legenda descritiva com o elemento <caption> . Todas as tabelas deverão conter uma legenda descritiva do seu conteúdo, incluindo as fontes da informação, se necessário.

    Evidencias:

    Image

    Figura 1 - Tabela sem legenda descritiva (caption).

    URL a verificar:

    https://www.cm-sjm.pt/pt/noticias/ambiente/candidaturas-ao-vale-eficiencia-e-edificios-sustentaveis

    Recomendações:

    Adicionar uma legenda descritiva às tabelas com o elemento <caption> .

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 #67 Existem campos com etiquetas pouco claras

    etiqueta: NOKetiqueta: R 4.1etiqueta: chk 10 web

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

    O campo “Subscrever newsletter” do formulário de subscrição de newsletter tem um texto que não é claro relativamente à função desse campo:

    Image

    Texto da etiqueta de campo não clara relativamente à função desse campo
    Devemos salientar que o texto da etiqueta referida deve fornecer a informação correta da função do campo, o que apenas está a ser transmitido pelo texto do atributo placeholder.
    Recomendamos a alteração do texto da etiqueta do campo “Subscrever newsletter” para “Email”.

  • issue #55 O texto placeholder está a substituir a label

    etiqueta: NOKetiqueta: R 4.1etiqueta: chk 10 web

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

    Não deve ser usado o texto placeholder em substituição de uma label, porque ao escrever no campo esse texto irá desaparecer e torna a tarefa difícil para pessoas com problemas de memória ou na revisão das respostas do formulário. Para além disso, alguns leitores de ecrã podem não estar preparados para ler esse texto.

    Ao manter a label visível no ecrã, amplia-se a área de clique, o que pode beneficiar também pessoas com dificuldades motoras ao selecionar um campo específico.

    No formulário de pesquisa geral, existe apenas texto placeholder no campo e não há qualquer legenda associada a esse campo. Este problema ocorre quer no formato desktop do site quer no formato mobile.

    Recomendamos a revisão dos formulários para garantir que:

    • São atribuídas legendas aos campos utilizando o elemento `<label>`;

    • O texto placeholder, quando utilizado, auxilia no preenchimento do campo em vez de substituir a legenda;

    Para mais informações, recomendamos consultar a página sobre boas práticas nos formulários da WebAIM.

    Image

    Figura 1 - Análise do campo de pesquisa geral, localizado no cabeçalho do site, através do Google Inspector. Versão desktop do site.

    Image

    Figura 2 - Análise do campo de pesquisa geral através do Google Inspector. Versão mobile do site.

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 #56 Existem campos em formulários em PDF sem indicação de obrigatoriedade de preenchimento

    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

    Verificámos que, nos formulários Formulário de Candidatura ao Procedimento Concursal e Formulário para o exercício do direito de participação dos interessados da página Formulários, não é possível reconhecer os campos de preenchimento obrigatório. Esta informação não é passada quer visualmente quer para os leitores de ecrã.

    Uma solução mais acessível seria disponibilizar os formulários diretamente no site, em vez de em formato PDF. Nos formulários web, os campos obrigatórios devem incluir os atributos required ou aria-required=”true” para serem identificados pelas tecnologias de apoio como obrigatórios.

    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 1 - Formulário Formulário de Candidatura ao Procedimento Concursal da página Formulários. Não é possível reconhecer os campos de preenchimento obrigatório quer visualmente quer através do leitor de ecrã.

    Image

    Figura 2 - Formulário Formulário para o exercício do direito de participação dos interessados da página Formulários. Não é possível reconhecer os campos de preenchimento obrigatório quer visualmente quer através do leitor de ecrã.

  • issue #38 Existem campos de preenchimento obrigatório sem indicação para as tecnologias de apoio

    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

    O campo de concordância com os termos e condições e política de privacidade do formulário de subscrição de newsletter não tem uma indicação de preenchimento obrigatório que possa ser anunciada pelas tecnologias de apoio:

    Image

    Campo de preenchimento obrigatório sem essa indicação
    O mesmo problema ocorre no campo de de concordância com os termos e condições e política de privacidade do formulário Contactos
    Recomendamos que seja usado “(obrigatório)” ou “(campo obrigatório)” à frente dos rótulos dos campos, ou em alternativa o uso do * (desde que a indicação do seu significado conste no topo do formulário). Se já existirem campos com a indicação de preenchimento obrigatório, deve ser mantida a coerência na introdução das novas indicações.

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

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

    Verificámos que no formulário de subscrição de newsletter os campos não estão identificados programaticamente como obrigatórios.
    Recomendamos que os campos obrigatórios incluam o atributo required para serem identificados pelas tecnologias de apoio como obrigatórios.

    Image

    Análise do campo "Email", no formulário de subscrição de newsletter através do Google Inspector
    O mesmo problema ocorre nos campos de preenchimento obrigatório do formulário Contactos.

  • issue #35 Existem formulários com a indicação de campo de preenchimento obrigatório duplicada

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

    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. Em alternativa, pode-se colocar um * no campo obrigatório, desde que o significado do * seja mencionado no início do formulário.
    À frente dos rótulos dos campos do formulário de subscrição de newsletter é usado “Obrigatório *”, o que configura uma duplicação da indicação de campo de preenchimento obrigatório.

    Image

    Campo email do formulário de subscrição de newsletter com a indicação “Obrigatório *”
    O mesmo problema ocorre nos campos de preenchimento obrigatório do formulário Contactos
    Recomendamos que seja usado apenas “(obrigatório)” ou “(campo obrigatório)” à frente dos rótulos dos campos, ou em alternativa o uso do * (desde que a indicação do seu significado conste no topo do formulário).

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #73 Existem formulários sem Mensagens de erro junto aos campos

    etiqueta: R 4.3etiqueta: NOKetiqueta: chk 10 web

    É possível localizar e ler as mensagens de erro usando apenas um leitor de ecrã.
    – ver requisito 4.3 na lista 10 aspetos

    O formulário de subscrição de newsletter não apresenta mensagens de erro junto aos campos:

    Image

    Campo email do formulário de contactos sem mensagem de erro associada
    A única mensagens de erro apresentada ocorre no topo da página, e é apresentada durante um período de tempo:

    Image

    Mensagem de erro no topo da página
    As mensagens de erro devem ser apresentadas junto aos campos e, adicionalmente (é útil no caso da existência de um número elevado de campos no formulário), pode ser apresentada uma lista no topo do formulário com o sumário dos vários erros.
    Neste caso, a localização da mensagem “Erro: insira um email válido” no topo da página associada ao seu curto tempo de permanência no ecrã torna muito difícil a descoberta da mesma por parte dos utilizadores de leitores de ecrã.
    A mesma situação ocorre no formulário contactos, com uma variante: a mensagem de erro é apresentada apenas no topo do formulário, e o seu conteúdo (“Erro! Erro de validação contra robôs, tente novamente”) não descreve os erros existentes, mas sim um erro que o utilizador não vê:

    Image

    Conteúdo inadequado de mensagem de erro no formulário contactos
    Recomendamos que sejam apresentadas mensagens de erro junto aos campos de todos os formulários, para assim forenecerem apoio na correção dos mesmos e consequente submissão correta dos formulários.
    Adicionalmente, pode existir uma lista dos erros no topo de cada formulário que consolida os vários erros existentes, em que cada mensagem deve remeter para o respetivo campo (por exemplo, através da colocação da mensagem num link cujo href contenha o id do respetivo campo).
    Todas as mensagens de erro devem permanecer no ecrã até que o utilizador atualize a página, de modo a serem lidas o número de vezes que o utilizador pretender.

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 #49 Imagem/gráfico não é acompanhada de uma descrição longa

    etiqueta: NOKetiqueta: R 5.2etiqueta: chk 10 web

    Evidências:
    Verifica-se que o texto associado não contempla integralmente a informação presente no banner, por exemplo, não apresenta informações sobre prazos de candidatura e informações de regulamento do prémio (viagem).

    Image

    URL:

    Recomendações:

    • A informação pode ser apresentada diretamente no conteúdo da página juntamente com o texto existente.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    etiqueta: NOKetiqueta: R 6.1etiqueta: chk 10 web

    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

    
Notas gerais

    • 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 textos com problema de contraste, por exemplo os campos dos formulários da “Pesquisa” e “Subscrever newsletter” possuem placeholders com os textos normais “Introduza o seu endereço de email” e “O que procura” com uma taxa de contraste inferior ao recomendado, nas com combinação de cores #777 (cor de primeiro plano) e #35383F(cor de plano de fundo) (Figura 1)

    Image

    Figura 1- Página com problemas de contraste em textos normais

    O website possui uma "Assistente" disponível em todas as páginas, onde o texto da notificação e alguns textos internos ao chatbot apresentam problemas de contrastes. Por exemplo nas combinação de cores #9CA3AF(cor de primeiro plano) e #FFFFFF(cor de plano de fundo) (Figura 2 e 3)

    Image

    Figura 2- Textos normais da modal "Assistente" com problemas de contraste

    Image

    Figura 3- Texto da notificação do botão "Assistente" não possui constraste suficiente

    Na página Pesquisa a mensagem de erro "Verifique se escreveu tudo corretamente ou tente uma nova pesquisa com outras palavras-chave" apresenta taxa de contraste inferior para texto normal. (Figura 4)

    Image

    Figura 4- Textos para mensagens de erro com contraste inferior ao recomendado_

    Recomendações
    Recomendamos a revisão das cores das páginas para garantir os valores mínimos de contraste do texto normal.

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

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

Lista de evidências recolhidas:

  • issue #84 Foi possivel ativar os botões de controlo do leitor quer com o rato quer com o teclado

    etiqueta: melhoriaetiqueta: R 7.1etiqueta: chk 10 web

    Foi possivel ativar os botões de controlo do leitor quer com o rato quer com o teclado, no entanto, verifica-se que não é possível interagir de forma adequada com os controlos do vídeo. Por exemplo, ao iniciar a reprodução, os controlos ficam ocultos e, para os tornar novamente visíveis, é necessário ativar uma opção localizada no canto do vídeo. A identificação dessa opção só é possível com o indicador de foco do navegador. Com o teclado, não é apresentada qualquer informação visível que permita compreender a sua função. Esta situação não é recomendada, uma vez que o utilizador pode não perceber que se trata de um elemento que permite aceder aos controlos do vídeo.

    Evidências:

    Image

    URLs a verificar:

    https://www.cm-sjm.pt/pt/noticias/educacao/carnaval-das-escolas-celebrou-o-centenario-do-concelho
    https://www.cm-sjm.pt/pt/noticias/municipio/tomaram-de-posse-os-eleitos-para-os-orgaos-municipais-com-video

    Recomendações:

    É necessário garantir que os controles do vídeo apresentem um ícone ou texto visível da sua função, além do indicador de foco visível, assegurando que o utilizador consegue identificar claramente a ação disponível.

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 #71 Elementos ocultos incluídos na ordem de leitura

    etiqueta: NOKetiqueta: R 8.2etiqueta: chk 10 web

    Notas Gerais

    • A ordem de leitura do conteúdo deve refletir apenas os elementos relevantes e disponíveis para o utilizador. Elementos que estejam ocultos visualmente não devem ser incluídos na navegação por teclado nem ser expostos a tecnologias de apoio.
    • Quando componentes interativos (como sliders/carrosséis) ocultam controlos com CSS, é necessário garantir que esses mesmos elementos ficam também inacessíveis programaticamente (por exemplo, removendo-os da ordem de tabulação ou utilizando aria-hidden="true").
    • Caso contrário, cria-se uma inconsistência entre o que é apresentado visualmente e o que é anunciado por leitores de ecrã, prejudicando a compreensão e navegação.

    URL a verificar

    Evidências:

    No componente de galeria (slider), os botões de navegação (“Previous slide” e “Next slide”) encontram-se ocultos visualmente através da classe hide-controls.

    No entanto, estes elementos continuam presentes na árvore de acessibilidade e mantêm:

    • tabindex="0" (focáveis por teclado)
    • role="button"
    • aria-label descritivo

    Como resultado, durante a navegação com leitor de ecrã ou teclado, estes controlos são anunciados e podem receber foco, apesar de não estarem visíveis para o utilizador.

    Image

    Figura 1 – Botões de navegação do slider ocultos visualmente mas acessíveis por teclado e leitores de ecrã

    Recomendações:

    • Remover elementos ocultos da ordem de tabulação (tabindex="-1" ou remover foco)
    • Aplicar aria-hidden="true" a elementos não visíveis
    • Garantir consistência entre visibilidade visual e acessibilidade programática dos componentes
    • Remover os atributos role="group" e aria-label="1 / 1" na div que contém a imagem.

  • issue #62 Ordem de leitura incorreta no formulário de newsletter

    etiqueta: NOKetiqueta: R 8.2etiqueta: chk 10 web

    Notas Gerais

    • A ordem dos elementos no HTML deve refletir a sequência lógica de interação do utilizador. Quando essa ordem não é respeitada, especialmente em formulários, pode gerar confusão, dificultar a navegação por teclado e comprometer a compreensão do fluxo de preenchimento.
    • Elementos dependentes entre si (como aceitação de termos e ativação de campos) devem surgir numa ordem coerente, garantindo que o utilizador percebe claramente os passos necessários para completar a ação.

    URL a verificar

    Evidências:

    No formulário de subscrição da newsletter, a ordem dos elementos no DOM não corresponde à sequência lógica de interação:

    O campo de email e o botão de submissão surgem antes da opção de aceitação dos termos
    No entanto, o campo de email encontra-se desativado até que o utilizador selecione a opção “Sim, li e aceito os Termos e Condições”
    Ou seja, a interação obrigatória (aceitação dos termos) aparece apenas após os elementos que dela dependem

    Esta estrutura provoca uma ordem de leitura inconsistente, sobretudo em navegação linear (sem CSS ou com tecnologias de apoio), onde o utilizador encontra primeiro elementos que não pode utilizar.

    Image

    Figura 1 - Formulário de newsletter com ordem de leitura inconsistente (aceitação de termos após campo dependente)

    Recomendações:

    • Colocar a aceitação dos termos antes do campo de email, garantindo uma sequência lógica de interação
    • Garantir que a ordem no DOM reflete o fluxo real de utilização
    • Em alternativa, caso se pretenda manter a ordem atual, posicionar o botão de submissão apenas após o campo de email e a checkbox de aceitação
    • Analisar também a issue https://github.com/a11y-PT/report_020/issues/36, por abordar um problema relacionado com o preenchimento da newsletter

  • issue #26 Ordem lógica do conteúdo comprometida no menu mobile

    etiqueta: NOKetiqueta: R 8.2etiqueta: chk 10 web

    Notas Gerais

    • A ordem do conteúdo no HTML deve refletir uma sequência lógica de leitura, independentemente da apresentação visual. Quando os elementos são posicionados visualmente através de CSS (por exemplo, menus que aparecem no topo), mas estão colocados noutra posição no código, isso pode comprometer a compreensão quando os estilos são desativados ou quando o conteúdo é interpretado por tecnologias de apoio.

    URL a verificar

    Evidências:

    As opções do menu mobile encontram-se estruturadas no final do código HTML da página.

    Visualmente, o menu surge no topo da interface, mas ao desativar o CSS ou ao navegar linearmente pelo conteúdo, os itens do menu apenas aparecem depois de todo o restante conteúdo da página.

    Isto compromete a ordem lógica de leitura, uma vez que a navegação principal deveria estar disponível no início da página.

    Image

    Figura 1 – Opções do menu mobile posicionadas no final do código, surgindo apenas após o restante conteúdo quando o CSS é desativado

    Recomendações:

    • Posicionar o menu de navegação principal no início do HTML, antes do conteúdo principal
    • Evitar depender exclusivamente de CSS para alterar a ordem visual dos elementos
    • Garantir que a ordem no código corresponde à ordem lógica de leitura e navegação

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 #86 Componente de pesquisa com comportamento de separadores (tabs) 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

    Notas Gerais

    • Quando existe um padrão de interface do tipo “tabs”, este deve ser implementado com a devida estrutura semântica, garantindo que a navegação e a relação entre conteúdos sejam corretamente interpretadas por leitores de ecrã e navegação por teclado.

    URL a verificar

    Evidências:
    Na página de resultados de pesquisa, o conteúdo apresenta um comportamento equivalente a um sistema de separadores (tabs), onde os resultados são organizados em diferentes secções interativas.
    No entanto, este comportamento não está estruturado semanticamente como um padrão de tabs (não são utilizados papéis ARIA nem estrutura equivalente), o que pode dificultar a compreensão da relação entre as diferentes secções para utilizadores de tecnologias de apoio.

    Image

    Figura 1 – Página de resultados de pesquisa com comportamento semelhante a tabs sem estrutura semântica ARIA adequada.

    Recomendações:

    • Implementar estrutura semântica de tabs utilizando ARIA (role="tablist", role="tab", role="tabpanel").
    • Garantir que cada separador é navegável por teclado e anunciado corretamente por leitores de ecrã.
    • Assegurar que a relação entre tabs e conteúdo é programaticamente determinável.

    Referência de boas práticas:
    https://www.w3.org/WAI/ARIA/apg/patterns/tabs/examples/tabs-manual/

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

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

    Notas Gerais

    • De acordo com boas práticas de estrutura e semântica da informação, cada elemento interativo deve ser único e ter um propósito claro dentro do bloco de conteúdo. A repetição de elementos com a mesma finalidade pode comprometer a clareza da estrutura, aumentar a complexidade de navegação e dificultar a interpretação por tecnologias de apoio.

    URL a verificar

    Evidências

    Image

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

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

    Um link no título (<h4> <a>)
    Um botão visual (<a class="main-button">)

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

    Recomendações

    • Remover a duplicação de links com o mesmo destino dentro do mesmo bloco
    • Manter apenas um elemento clicável por item (idealmente o botão ou o título, mas não ambos)
    • Em alternativa, remover o link do título e manter o botão como elemento principal de navegação
    • Garantir uma estrutura de navegação mais limpa e consistente para utilizadores e tecnologias de apoio

  • issue #47 Controlos de pesquisa 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

    Notas Gerais

    Os elementos interativos devem ser implementados com elementos HTML semânticos apropriados (como <button>, <input>), garantindo que a sua função é compreendida sem dependência de estilos visuais.

    A utilização de elementos genéricos como <div> para funcionalidades interativas compromete a interpretação da interface quando o CSS é removido, dificultando a perceção da estrutura e da funcionalidade por parte de utilizadores e tecnologias de apoio.

    URL a verificar

    Evidências:

    No componente de pesquisa mobile, existem controlos interativos (como o botão de fechar e o ícone de limpar pesquisa) implementados com elementos <div> contendo apenas ícones SVG, sem utilização de elementos semânticos como <button>.

    Sem CSS, estes elementos não são identificáveis como controlos interativos, nem possuem semântica adequada que permita perceber a sua função.

    Image

    Figura 1 – Controlos de pesquisa implementados com <div> e <svg> sem semântica de botão

    Recomendações:

    • Substituir elementos <div> interativos por <button> ou outros elementos semânticos adequados
    • Garantir que todos os controlos têm nome acessível (ex: aria-label)
    • Validar comportamento sem CSS e com navegação por teclado

  • issue #32 Conteúdo duplicado na leitura de campos de formulário

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.3

    Notas Gerais

    • A existência de marcação duplicada ou estruturalmente redundante (por exemplo, múltiplos rótulos associados ao mesmo campo, textos repetidos no DOM ou elementos que representam a mesma informação mais do que uma vez) pode comprometer a clareza da estrutura do documento.
    • Este tipo de redundância afeta a forma como tecnologias de apoio interpretam a página, podendo resultar em repetições ou numa estrutura hierárquica pouco clara durante a navegação por conteúdo estruturado.

    URL a verificar

    Evidências:

    No formulário de contactos, ao navegar com leitor de ecrã, os campos são anunciados de forma duplicada.

    Por exemplo, no campo “Nome”, são lidos múltiplos conteúdos redundantes como:
    “Nome Obrigatório * edição Nome (Obrigatório) Introduza o seu nome em branco (…) Nome Obrigatório *”

    Esta repetição indica a presença de informação duplicada no código (ex.: labels, instruções ou atributos), resultando numa leitura excessiva e potencialmente confusa para o utilizador.

    Como consequência, a ordem lógica e a clareza da informação ficam comprometidas.

    Image

    Figura 1 – Leitura duplicada de informação no campo “Nome” do formulário de contactos

    Recomendações:

    • Evitar duplicação de labels e textos associados ao mesmo campo
    • Garantir que cada campo possui um único nome acessível claro e consistente
    • Evitar o uso desnecessário de title e placeholder; estes atributos devem ser usados apenas quando fornecem informação adicional e complementar ao label existente

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 #6 Quando a caixa de diálogo é aberta, não move-se para um elemento dentro da caixa de diálogo

    etiqueta: NOKetiqueta: R 9.1etiqueta: chk 10 web

    Evidências:
    Quando a caixa de diálogo é ativada, o foco do navegador permanece no conteúdo de fundo da página (links ou campos de texto do site) em vez de ser transferido automaticamente para o primeiro elemento interativo da modal (ex: botão "Aceitar todos").

    Image Image

    URL:
    https://www.cm-sjm.pt/

    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:

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

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 9.2

    Evidências:
    A navegação por teclado e leitores de ecrã não fica limitada aos elementos da caixa de diálogo. Durante a navegação, é possível interagir com elementos subjacentes à caixa de diálogo, fora do seu contexto.

    Image Image

    URL:

    https://www.cm-sjm.pt

    Recomendações:

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

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

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

Lista de evidências recolhidas:

  • issue #14 A caixa dialogo não pode ser encerrada através da tecla ESC.

    etiqueta: melhoriaetiqueta: R 9.3etiqueta: chk 10 web

    Evidências:

    Verifica‑se que a caixa de diálogo não pode ser encerrada através da tecla ESC e também não possui um botão dedicado para fechar. Atualmente, para sair da modal é necessário acionar um dos botões “Aceitar todos”, “Rejeitar todos” ou “Guardar”, o que não é explícito tal como um botão de "Fechar".

    Image Image

    URL:

    https://www.cm-sjm.pt/

    Recomendações:

    • Idealmente podem implementar um mecanismo que permita o encerramento das janelas modais através da tecla ESC.
    • Devem incluir um botão de fechar claramente identificado na caixa de diálogo, permitindo ao utilizador encerrar o componente de forma simples e independente.

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 #18 Ao fechar a modal o cursor não retorna ao elemento que o acionou.

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 9.4

    Evidências:

    Ao fechar a caixa de diálogo, o foco não é devolvido ao elemento que a acionou. Em vez disso, o foco é reposicionado em outro elemento da página prejudicando a navegação.

    Image

    URL:
    https://www.cm-sjm.pt/

    Recomendações:

    • Recomenda-se que ao fechar a modal, o foco seja devolvido ao elemento que a acionou. No caso da modal de cookies, deverá ter o foco posicionado no primeiro elemento interativo da página: o botão de saltar para conteúdo principal.

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:

Checklist Conteúdo

etiqueta: NOK

Nível de conformidade:

  • Checklist Conteúdo: 5.9% (1/17)
    • Requisitos avaliados: 17 (17 aplicáveis)
    • Requisitos OK: 1
    • Requisitos NOK: 16

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

    etiqueta: chk conteúdoetiqueta: R 1.1etiqueta: 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 inicial do do website da Camâra Municipal de São João da Madeira, não aparece presente um resumo breve do próposito do site. Apesar de existir a frase "Novo Portal de São João da Madeira Mais acessível, mais transparente" na imagem no banner principal, esta frase não resume fielmente quais as tarefas ou a informação que é possível encontrar no website.

    Image

    Imagem da página inicial sem dar scroll.

    Recomendações:

    Não existe qualquer resumo do propósito na Homepage da Câmara Municipa de São João da Madeira pelo que deve ser adicionado.

    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 inicial, sem ser necessário fazer scroll, avançar no slideshow, entre outros.

    Como exemplo de uma boa prática, é possível verificar no website acessibilidade.gov que o seu propósito está escrito no topo da página:

    Image

    Image exemplo de uma frase de propósito do website acessibilidade.gov

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #30 Falta de glossário para termos complexos

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

    Os termos mais complexos têm uma definição agregada.
    – ver requisito 1.2 na lista Conteúdo

    Evidências:

    Ao longo do website, é possível identificar a utilização de diversos termos técnicos e complexos que surgem sem qualquer definição ou explicação associada. Na ausência de um glossário ou de mecanismos que permitam esclarecer esses conceitos, os utilizadores podem ter dificuldade em compreender plenamente a informação apresentada, especialmente aqueles que não estão familiarizados com a terminologia utilizada.

    Esta limitação compromete a acessibilidade e a clareza dos conteúdos, uma vez que obriga o utilizador a procurar significados fora do contexto do site ou a interpretar incorretamente a informação. A situação torna-se ainda mais evidente em elementos de navegação, como demonstrado na Figura 1, onde uma opção de submenu no rodapé apresenta um termo complexo sem qualquer contextualização. Neste caso, o utilizador pode não conseguir perceber o significado da opção nem antecipar o conteúdo da página associada sem ter de a aceder previamente.

    Image

    Figura 1: Imagem com o termo complexo "PRR" como opção no menu do rodapé.

    Image

    Figura 2: Imagem do termo complexo "VIARCO" na página dos presidentes anteriores

    Image

    Figura 3: Imagem do termo complexo "CERCI" na página dos presidentes anteriores

    Image

    Figura 4: Imagem do termo complexo "RSU" como título na página das Águas e Saneamentos

    A disponibilização de definições, descrições contextuais ou de um glossário dedicado contribuiria significativamente para melhorar a compreensão, promover a inclusão e reforçar a usabilidade global do website.

    Outros exemplos:

    Recomendações:

    Recomenda-se a criação de um glossário que permita a utilização consistente de siglas ao longo do website, evitando que o utilizador tenha de procurar repetidamente a sua definição noutros parágrafos.

    Como exemplo podem visualizar o glossario do acessibilidade.gov. https://www.acessibilidade.gov.pt/glossario/

Requisito 1.3 - Cada bloco de conteúdo contém a sua data de atualização

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #29 Falta de datas de atualização em blocos de conteúdo

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 1.3

    Cada bloco de conteúdo contém a sua data de atualização.
    – ver requisito 1.3 na lista Conteúdo

    Evidências:

    Não foi possível identificar qualquer data de atualização nos blocos de conteúdo analisados, excetuando-se apenas as secções de notícias ou outros conteúdos que, por natureza, apresentam uma data de publicação associada. Esta ausência de informação temporal estende-se também à área de contactos, onde igualmente não foram encontradas indicações sobre a última atualização.

    A falta dessas referências compromete a perceção de atualidade e fiabilidade da informação disponibilizada, tornando mais difícil para o utilizador avaliar se os conteúdos e contactos apresentados continuam válidos. A inclusão de datas de atualização, especialmente em páginas institucionais e informativas, é um elemento fundamental para reforçar a transparência, a credibilidade e a confiança na informação fornecida.

    Image

    Imagem da página dos contactos sem data de atualização.

    Importa salientar que a ausência de datas de atualização não se limita apenas à página de contactos. Na realidade, verifica-se de forma transversal em praticamente todas as páginas com conteúdo informativo do site, o que agrava a perceção de desatualização e fragiliza a confiança do utilizador.

    Qualquer página que disponibilize informação relevante deveria apresentar, de forma clara, a data da última atualização, permitindo ao utilizador avaliar a sua atualidade e fiabilidade. Esta prática é especialmente importante em secções como Serviços, Apoios, Programas, Regulamentos e Ofertas, entre outras, onde a informação pode sofrer alterações frequentes e ter impacto direto nas decisões dos utilizadores.

    Algumas páginas que evidenciam a necessidade de inclusão de uma data de atualização incluem, por exemplo:

    Recomendações:

    • Incluir a data de publicação e/ou última atualização em todos os conteúdos relevantes;

    • Garantir que essa informação está semanticamente estruturada;

    • Assegurar consistência na apresentação das datas em todo o site.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #28 A informação sobre a entidade responsável pelo conteúdo está em todas as páginas

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

    A informação sobre a entidade responsável pelo conteúdo está em todas as páginas.
    – ver requisito 1.4 na lista Conteúdo

    Evidências:

    Todas as páginas devem apresentar o nome da entidade responsável pelos conteúdos publicados no site. O nome da entidade pode ser apresentado através de um logótipo ou texto, mas deve estar por extenso.

    Apesar de existir no rodapé o logotipo da entidade e acesso rápido aos contactos. Observamos que o nome da entidade responsável não está disponível por extenso, o texto ”Todos os direitos reservados a www.cm-sjm.pt ” remete ao próprio site.

    Image

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

    Recomendações:

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

    Image

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

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #9 Informações primárias não possuem tamanho mínimo recomendado

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

    Notas Gerais

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

    O website possui informações primárias com tamanho inferior a 12pontos(16px) por exemplo na página Estrutura e Serviços no menu principal, as opções de segundo nível possuem dimensão de 14px. (Figura 1)

    Image

    Figura 1 - Verificação do tamanho do texto do menu com tamanho inferior ao recomendado.

    Há botões de ação principal, com tamanho inferior ao recomendado. Por exemplo na página Águas, saneamento e RSU (Figura 2)

    Image

    Figura 2 - Botões com tamanho de texto inferior ao recomendado

    Outras páginas com o mesmo problema, em botões:

    Além disso, na página inicial há textos informativos e botões dos cookies com dimensão inferior ao recomendado. Assim como informações primárias como os textos "Sim, li e aceito os Termos de Condições e a Política de Privacidade" presentes nos formulários da Newsletter do rodapé e na página Contactos (Figura 3 e 4)

    Image

    Figura 3 - Verificação do tamanho de texto para aceitação dos cookies

    Image

    Figura 4 - Textos com informações primárias do formulário da Newsletter no rodapé com dimensão inferior ao recomendado

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

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #19 Há informações secundárias com um tamanho de letra inferior a 10pt (equivalente a 13px)

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

    Notas Gerais

    • Para garantir a legibilidade da informação secundária, esta deve ter um tamanho de letra igual ou superior a 13px (10pt).

    Durante a análise foram identificadas informações secundárias apresentadas com um tamanho de letra inferior ao mínimo recomendado.

    Por exemplo, na página Inicial, há textos de informações secundárias como na secção "Temas de destaque" as datas de atualização possuem valor de 12px, não cumpre o presente critério. Esta dimensão reduzida compromete a legibilidade e cria barreiras para utilizadores com baixa visão ou que necessitem de ampliar o conteúdo. (Figura 1)

    Image

    Figura 1 - Verificação do tamanho para informações secundárias com valor inferior ao recomendado

    Outro exemplo:

    Recomendação de melhoria
    Recomendamos revisar todo website, e aumentar o tamanho de letra das informações secundárias para, no mínimo 10 pontos(13px). Garantindo simultaneamente que a fonte permanece escalável, permitindo ampliação por tecnologias assistivas ou pelo zoom do navegador;

    Outras evidências (OK):

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

    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 existe níveis de navegação com 11 e 13 opções, ultrapassando o limite de nove.

    Image

    Imagem com o menu de navegação e os seus subníveis ultrapassando as 9 opções.

    Notas:

    O menu deve ser estruturado de forma a facilitar a navegação por utilizadores de tecnologias de apoio visual, como leitores de ecrã (ex.: NVDA). Na sua forma atual, a apresentação de subníveis sem diferenciação clara e dispostos lado a lado, com quebra para a linha seguinte, pode gerar ambiguidade e dificultar a compreensão da hierarquia de navegação.

    Recomenda-se que a organização do menu seja mais clara e previsível. As opções de nível superior devem ser apresentadas na mesma coluna, com os respetivos subníveis posicionados de forma consistente (por exemplo, em lista vertical indentada ou em menus laterais), evidenciando a relação hierárquica entre os itens. Esta abordagem melhora a perceção, compreensão e orientação dos utilizadores, especialmente daqueles que dependem de tecnologias de apoio.

    Recomendações:

    Recomenda-se que a organização do menu seja mais clara e previsível. As opções de nível superior devem ser apresentadas na mesma coluna, com os respetivos subníveis posicionados de forma consistente (por exemplo, em lista vertical indentada ou em menus laterais), evidenciando a relação hierárquica entre os itens. Esta abordagem melhora a perceção, compreensão e orientação dos utilizadores, especialmente daqueles que dependem de tecnologias de apoio.

    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.

    • Reorganizar a arquitetura de informação para garantir uma hierarquia mais simples e intuitiva.

    • Utilizar rótulos claros e consistentes que facilitem a identificação rápida das secções.

    • Considerar a introdução de sub-subníveis ou menus progressivos (ex.: “ver mais”) para distribuir melhor as opções.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #33 Carrossel não totalmente adaptável em dispositivos móveis

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 4.2

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

    Ponto 01
    Página: https://www.cm-sjm.pt/pt/noticias/4

    Em alguns dispositivos móveis, como o iPhone SE, os botões de navegação do carrossel não se adaptam corretamente ao layout, ficando parcialmente cortados ou fora da área visível.

    Botões de navegação do carrossel parcialmente cortados em dispositivos móveis com ecrã reduzido (ex.: iPhone SE), não se adaptando corretamente ao layout responsivo

    Recomendações:
    Ajustar o comportamento responsivo do carrossel para garantir que os botões de navegação se mantêm totalmente visíveis e corretamente posicionados em diferentes tamanhos de ecrã, incluindo dispositivos com largura reduzida, como o iPhone SE.

    Ponto 02
    Página: https://www.cm-sjm.pt/pt/noticias

    Na página de notícias, o menu de categorias não é totalmente visível em dispositivos móveis, sendo parcialmente cortado devido à largura reduzida do ecrã, o que dificulta a navegação e a perceção de todas as opções disponíveis.

    Secção de categorias de notícias em dispositivo móvel com opções parcialmente cortadas, impedindo a visualização completa de todas as categorias disponíveis

    Outros exemplos:
    https://www.cm-sjm.pt/pt/agenda

    Recomendação
    Ajustar o componente de categorias para garantir que todas as opções sejam acessíveis em dispositivos móveis, através de quebra de linha, scroll horizontal controlado ou layout responsivo adequado, evitando conteúdo cortado ou inacessível.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #15 Navegação por teclado incompleta em menus interativos

    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

    Ponto 01

    Página: https://www.cm-sjm.pt/pt/inicio ( E em todo website)

    O menu principal com as opções “Município”, “Cidadão”, “Visitante” e “Investigador” apresenta um comportamento inconsistente na navegação por teclado. Ao utilizar a tecla TAB, o foco abre o menu, mas não percorre os itens do submenu, saltando diretamente para o próximo elemento da página, impedindo a navegação completa pelas opções disponíveis.

    Menu principal do website da CM S. João da Madeira com problema de navegação por teclado

    Recomendação

    Garantir que a navegação por teclado percorre todos os itens dos menus expandidos, mantendo o foco dentro do submenu enquanto este estiver aberto, de forma a permitir o acesso completo a todas as opções sem necessidade de utilização do rato.

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 #17 Elementos interativos com área de toque inferior ao mínimo recomendado (44x44px)

    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

    Ponto 01
    Página: https://www.cm-sjm.pt/pt/inicio

    O checkbox de aceitação de termos e condições no formulário de subscrição da newsletter apresenta dimensão aproximada de 16px, abaixo do mínimo recomendado de 44px CSS, dificultando a interação em dispositivos de toque.

    Checkbox de subscrição da newsletter com dimensão inferior a 44px

    Figura 06 – Checkbox com dimensão inferior ao mínimo recomendado

    Outros exemplo:
    https://www.cm-sjm.pt/pt/contactos

    Recomendação
    Aumentar o tamanho do checkbox para pelo menos 44px e tornar explícita a dependência entre o campo de email e o checkbox, garantindo que o utilizador compreende desde o início que ambos são necessários para a subscrição.

    Ponto 02
    Página: https://www.cm-sjm.pt/pt/inicio

    Na secção “Atalhos rápidos”, alguns elementos interativos apresentam dimensão inferior ao mínimo recomendado de 44px CSS, com cerca de 15,75px, o que pode dificultar a interação em dispositivos de toque e afetar a usabilidade.

    Elementos interativos na secção

    Recomendação
    Recomenda-se garantir que todos os elementos interativos do site (botões, links, ícones clicáveis e atalhos) possuam uma área mínima de interação de 44x44px CSS, conforme boas práticas de acessibilidade e recomendações da WCAG 2.2.

    Ponto 03
    Página: https://www.cm-sjm.pt/pt/inicio

    No botão de assistente virtual, os elementos interativos (como o ícone “X” para fechar e a seta de envio) apresentam dimensão reduzida (~20px), o que pode dificultar a interação, especialmente em dispositivos de toque.

    Botão do assistente virtual com ícones de fechar (X) e enviar (seta) apresentando dimensão reduzida (~20px), podendo dificultar a interação em dispositivos de toque

    Recomendação
    Aumentar a área clicável dos ícones interativos (mínimo recomendado de 44x44px conforme boas práticas WCAG), garantindo melhor usabilidade em touch devices. Pode-se também manter o ícone visual menor, mas com área de clique expandida.

    Ponto 04
    Página: https://www.cm-sjm.pt/pt/noticias/3

    Na página de Notícias, os botões de paginação apresentam dimensão reduzida 32px de altura e largura, e não cumprem o presente requisito. Esta implementação dificulta a interação em dispositivos de toque e compromete a usabilidade em contexto mobile

    Botões de navegação do carrossel na página de notícias com dimensão reduzida (~16px), dificultando a interação em dispositivos de toque

    Recomendação
    Aumentar a área clicável dos botões de navegação do carrossel para um mínimo recomendado de 44x44px, garantindo melhor acessibilidade e facilidade de interação em dispositivos móveis, sem comprometer o design visual.

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 #70 Falta de hierarquia visual entre botões de ação e tags em todo o website

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

    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

    Ponto 01
    O website utiliza um estilo de cor consistente entre tags, botões e elementos interativos, o que compromete a distinção entre ações primárias e secundárias. Esta abordagem reduz a clareza da hierarquia visual e pode gerar dúvidas ao utilizador sobre qual ação deve ser executada primeiro.

    Na página https://www.cm-sjm.pt/pt/agenda, existem múltiplas tags e elementos clicáveis com o mesmo tratamento visual, sem uma ação principal claramente destacada.
    Isto dificulta a orientação do utilizador na tomada de decisão e na identificação do conteúdo mais relevante.

    Na página de contactos https://www.cm-sjm.pt/pt/contactos, o botão principal “Enviar” apresenta o mesmo estilo visual das tags utilizadas em todo o website, não se destacando como uma ação primária de submissão do formulário.
    Esta falta de diferenciação compromete a perceção de prioridade das ações e pode afetar a usabilidade do formulário.

    Image Image

    Outros exemplos
    https://www.cm-sjm.pt/pt/recursos-humanos
    https://www.cm-sjm.pt/pt/informacoes
    https://www.cm-sjm.pt/pt/criancas-e-jovens

    Recomendação
    Diferenciar visualmente botões de ação principal (ex.: “Enviar”) das tags e elementos secundários, usando estilo mais destacado (cor, preenchimento ou contraste).
    Isto ajuda a melhorar a hierarquia visual e facilita a identificação das ações mais importantes pelo utilizador.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #13 Inconsistência na perceção de clicabilidade e hierarquia visual em elementos interativos

    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

    Ponto 01
    Página: https://www.cm-sjm.pt/pt/acessibilidade

    Os botões do banner de cookies “Personalizar” e “Rejeitar cookies” apenas são percecionados como botões quando é utilizado o hover. Este comportamento não garante uma identificação adequada dos controlos interativos.

    Banner de cookies onde os botões perdem diferenciação visual no estado de hover, ficando com aparência semelhante

    Figura 01 – Banner de cookies com perda de diferenciação visual no estado de hover

    Recomendação
    Deve ser revisto o estilo visual destes elementos, assegurando‑se que são apresentados, por defeito, como botões claramente clicáveis, com recurso a volume, cor e/ou contorno.

    Ponto 02
    Página: https://www.cm-sjm.pt/pt/inicio

    Deve ser assegurado feedback visual claro no switch de seleção da categoria de cookies, garantindo‑se uma diferenciação inequívoca entre os estados ativo e inativo. Essa diferenciação deve ser percecionável através de indicadores visuais explícitos, como o movimento da bolinha e/ou a alteração de cor, de modo a permitir a correta identificação do estado do controlo por todos os utilizadores, incluindo utilizadores de tecnologias de apoio.

    Switch da categoria de cookies no painel de gestão de cookies sem indicação clara do estado ativo/inativo, mantendo a bolinha na mesma posição e dificultando a perceção da interação

    Recomendação
    Garantir feedback visual claro no switch da categoria de cookies, assegurando diferenciação evidente entre estados ativo e inativo, com movimento da bolinha e/ou alteração de cor para melhorar a perceção da interação e seguir boas práticas de UX e acessibilidade.

    Ponto 03
    Página:https://www.cm-sjm.pt/pt/inicio

    Os botões “Descarregar” apresentam contraste insuficiente em relação ao fundo do card no estado padrão (inferior a 3:1), o que dificulta a sua identificação e destaque visual. O botão torna-se mais perceptível apenas no estado de hover, quando o fundo escurece, evidenciando a falta de contraste inicial.

    Botão

    Recomendação
    Aumentar o contraste dos botões “Descarregar” no estado padrão, garantindo um rácio mínimo de 3:1 em relação ao fundo, de forma a assegurar a sua identificação clara como elemento interativo, independentemente do estado de hover.

    Outros exemplos:
    https://www.cm-sjm.pt/pt/covid-19

    Recomendação
    Garantir que os botões “Descarregar” apresentam no estado padrão uma aparência consistente de elemento interativo, com indicação visual clara de clicabilidade sem depender exclusivamente do estado de hover.

    Ponto 04
    Página: https://www.cm-sjm.pt/pt/inicio

    Nos “Atalhos rápidos”, os cards de “Habitação”, “Informações” e “Pedidos” apresentam uma aparência visual de elemento clicável, apesar de não existir uma indicação consistente de interatividade semelhante à das setas de navegação presentes na mesma secção, o que pode gerar ambiguidade na perceção de quais elementos são efetivamente acionáveis.

    Cards de

    Figura 03 – Inconsistência na perceção de clicabilidade nos “Atalhos rápidos”

    Recomendação

    Garantir consistência na indicação de interatividade entre todos os elementos da secção “Atalhos rápidos”, assegurando que tanto os cards como as setas apresentem sinais claros e uniformes de clicabilidade.

    Ponto 05
    Página: https://www.cm-sjm.pt/pt/inicio

    O link “Veja todas as notícias”, composto por texto e ícone (seta), não apresenta destaque visual consistente de interatividade, o que pode dificultar a sua identificação como elemento clicável.

    Link de notícias sem indicação clara de interatividade

    Outros exemplos:
    https://www.cm-sjm.pt/pt/oportunidades-e-incentivos

    Recomendação
    Recomenda-se que os elementos sejam apresentado com um estilo visual consistente de link, garantindo a sua perceção imediata como elemento clicável, através de indicadores como sublinhado, cor diferenciada e estados de hover/focus claramente visíveis.

    Ponto 06
    Página: https://www.cm-sjm.pt/pt/orgaos-autarquicos

    Os elementos gráficos clicáveis (imagens da “Câmara Municipal” e “Assembleia Municipal”) funcionam como links, mas não apresentam indicação visual clara de interatividade. Esta ausência de affordance pode dificultar a perceção de que os elementos são clicáveis, especialmente para utilizadores menos experientes e em navegação por teclado ou dispositivos móveis.

    Imagens clicáveis sem indicação clara de interatividade

    Outros exemplos:
    https://www.cm-sjm.pt/pt/projeto-d-noses
    https://www.cm-sjm.pt/pt/empreendedorismo
    https://www.cm-sjm.pt/pt/oportunidades-e-incentivos
    https://www.cm-sjm.pt/pt/zonas-industriais
    https://www.cm-sjm.pt/pt/gestao-de-desporto-na-cidade

    Recomendação
    Recomenda-se que os elementos gráficos interativos sejam claramente identificáveis como links, através de indicadores visuais consistentes de interatividade, como alteração de estilo ao hover/foco, cursor adequado, contraste adequado e eventual reforço visual (ex: overlay, sublinhado ou contorno), garantindo a perceção imediata de que se trata de elementos clicáveis.

    Ponto 07
    Página: https://www.cm-sjm.pt/pt/inicio

    Os ícones de email e telefone associados ao “Balcão Virtual” não apresentam feedback visual de interação, como alteração de cor, destaque ou indicação de estado (hover/ativo), não transmitindo claramente a sua clicabilidade.

    Ícones de email e telefone ao lado do texto

    Recomendação
    Implementar feedback visual nos ícones interativos (email e telefone), como alteração de cor, hover ou variação de estilo, para reforçar a sua natureza clicável e melhorar a perceção de interação, em conformidade com boas práticas de UX e acessibilidade.

    Ponto 08
    Página: https://www.cm-sjm.pt/pt/noticias

    Os botões de navegação do carrossel apresenta contraste insuficiente em relação ao fundo (inferior a 3:1), dificultando a sua identificação e perceção como elemento clicável.

    Elemento interativo com contraste insuficiente em relação ao fundo (inferior a 3:1), dificultando a sua identificação como clicável

    Recomendação
    Ajustar o contraste do elemento interativo para garantir um rácio mínimo de 3:1, assegurando melhor visibilidade e identificação da sua interatividade, de acordo com boas práticas de acessibilidade.

    Ponto 09
    Página: https://www.cm-sjm.pt/pt/agenda-municipal-da-saude

    A página indica que o utilizador deve clicar na imagem para aceder ao ficheiro PDF da Agenda Municipal da Saúde, no entanto, o elemento gráfico não apresenta indicação visual de interatividade. A ausência de feedback visual, como hover, alteração de estado ou estilo de link, pode dificultar a perceção de que se trata de um elemento clicável.

    Página da Agenda Municipal da Saúde com imagem utilizada como elemento clicável para acesso ao PDF, sem indicação visual de interatividade (sem hover, destaque ou estilo de link), podendo dificultar a perceção de que é clicável

    Recomendação
    Garantir que os elementos gráficos clicáveis tenham indicação visual clara de interatividade (hover, cursor ou destaque), assegurando a perceção imediata de que são clicáveis.

Checklist Transação

etiqueta: NOK

Nível de conformidade:

  • Checklist Transação: 27.3% (3/11)
    • Requisitos avaliados: 13 (2 N/A excluídos, 11 aplicáveis)
    • Requisitos OK: 3
    • Requisitos NOK: 8
    • Requisitos N/A: 2

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #36 Campo de email dependente da aceitação dos Termos e Condições

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

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

    No formulário de subscrição da newsletter, localizado no rodapé do site, verificámos que o campo de email está desativado por defeito. O campo só fica ativo depois de o utilizador selecionar a caixa de verificação “Sim, li e aceito os Termos e Condições e a Política de Privacidade”, que se encontra abaixo do campo de email.

    Esta configuração cria um problema de ordem de foco e navegação: o campo de email aparece antes da caixa de verificação — tanto visualmente como na ordem de leitura das tecnologias de apoio — mas só pode ser utilizado depois de essa caixa ser selecionada. Além disso, não é intuitivo para o utilizador que o campo apenas ficará ativo após aceitar os termos e condições.

    Recomendamos que o campo de email esteja ativo por defeito e que a sua utilização não dependa da seleção prévia da caixa de verificação.

    Image

    Figura - Formulário para subscrever a newsletter no rodapé do site.

  • issue #27 O link para submissão do formulário é ignorado quando se navega por teclado (Tab e Shift+Tab)

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

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

    Ao navegar pelo formulário com o teclado usando a tecla TAB, a sequência de tabulação deve seguir a ordem de preenchimento, passando por todos os campos disponíveis.

    Verificámos que, na página Contactos, ao navegar por teclado (Tab e Shift+Tab), não é possível focar no link “Enviar” - cuja função é a de submeter a informação recolhida no formulário.

    Recomendamos que a <div> dentro da qual se encontra este elemento (<div class="btn-input-submit">) seja substituída pelo elemento HTML nativo semântico <button>.

    Image

    Figura 1 - Navegação pelo formulário da página Contactos através de Tab e Shift+Tab. O link 'Enviar' não está a receber foco através do teclado.

    Image

    Figura 2 - Análise da <div> onde se encontra o link 'Enviar', do formulário da página Contactos, através do Google Inspector.

  • issue #11 A sequência de tabulação não segue a sequência de preenchimento

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

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

    Testámos os ficheiros PDF Formulário de Candidatura ao Procedimento Concursal e
    Formulário para o exercício do direito de participação dos interessados, presentes na página Formulários, através do browser e do Adobe Acrobat Reader, e não é possível navegar pelos diferentes campos do formulário através do leitor de ecrã.

    Uma solução mais acessível seria disponibilizar o formulário diretamente no site, em vez de em formato PDF.

    Image

    Figura 1 - Análise do ficheiro PDF Formulário para o exercício do direito de participação dos interessados, presente na página Formulários, através do Adobe Acrobat Reader.

    Image

    Figura 2 - Análise do ficheiro PDF Formulário de Candidatura ao Procedimento Concursal, presente na página Formulários, através do Adobe Acrobat Reader.

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

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

Lista de evidências recolhidas:

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

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

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

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

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

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

    A largura do próprio campo deve refletir o tamanho previsível dos dados a preencher, principalmente em campos de escrita livre em que o utilizador deve inserir os seus próprios dados.

    No caso do formulário da página Contactos, a largura dos campos não reflete o tamanho previsível dos dados. O campo 'Telefone' tem a mesma largura que os campos 'Nome', 'Email' e 'Assunto', apesar de, no contexto português, um número de telefone ter no máximo cerca de 14 caracteres (por exemplo, 00351212345678). Tendo isto em conta, este campo deveria ser mais curto do que os restantes.

    Por outro lado, o campo 'Nome' deve ter largura suficiente para acomodar, no limite, o nome completo do utilizador. Assim, recomendamos reformular este campo para ser maior.

    Image

    Figura - Formulário da página Contactos. Campo "Telefone" é demasiado largo para os dados a inserir e o campo "Nome" demasiado estreito para um nome completo.

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

etiqueta: N/A

Lista de evidências recolhidas:

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

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

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

    No site da Câmara Municipal de São João da Madeira, não foram encontrados campos cujo conteúdo dependente seja ocultado ou revelado automaticamente com base na ativação de um campo chave. Assim, o requisito 2.2. da Checklist de Transação é avaliado como “Não aplicável”.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #54 O texto placeholder está a substituir a label

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

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

    Não deve ser usado o texto placeholder em substituição de uma label, porque ao escrever no campo esse texto irá desaparecer e torna a tarefa difícil para pessoas com problemas de memória ou na revisão das respostas do formulário. Para além disso, alguns leitores de ecrã podem não estar preparados para ler esse texto.

    Ao manter a label visível no ecrã, amplia-se a área de clique, o que pode beneficiar também pessoas com dificuldades motoras ao selecionar um campo específico.

    No formulário de pesquisa geral, existe apenas texto placeholder no campo e não há qualquer legenda associada a esse campo. Este problema ocorre quer no formato desktop do site quer no formato mobile.

    Recomendamos a revisão dos formulários para garantir que:

    • São atribuídas legendas aos campos utilizando o elemento `<label>`;

    • O texto placeholder, quando utilizado, auxilia no preenchimento do campo em vez de substituir a legenda;

    • Caso seja usada a legenda dentro do campo, esta deve estar identificada como `<label>` e não deve desaparecer quando o campo está em foco, como acontece no exemplo do [Campos de formulário - Material Design](https://m2.material.io/components/text-fields) e/ou [Caixa de seleção - Material Design](https://material-components.github.io/material-components-web-catalog/#/component/select)

    Para mais informações, recomendamos consultar a página sobre boas práticas nos formulários da WebAIM.

    Image

    Figura 1 - Análise do campo de pesquisa geral, localizado no cabeçalho do site, através do Google Inspector. Versão desktop do site.

    Image

    Figura 2 - Análise do campo de pesquisa geral através do Google Inspector. Versão mobile do site.

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

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

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

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

    Verificámos que nos campos “Informação Extra”(do formulário da página Contactos) e “Subscrever Newsletter” (do formulário localizado no rodapé para subscrição da newsletter) a legenda não corresponde ao tipo de conteúdo que o utilizador deve inserir.

    Estas legendas devem ser ajustadas para indicar de forma clara e precisa que informação é esperada. Neste caso, uma possível solução seria alterar as legendas para “Mensagem” e “Email”, respetivamente.

    Image

    Figura 1 - Formulário da página Contactos.

    Image

    Figura 2 - Análise do rótulo do formulário para subscrição da newsletter através do Google Inspector.

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

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

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

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

    No formulário PDF Formulário de Candidatura ao Procedimento Concursal da página Formulários, é possível observar que o campo que se encontra em frente ao campo “Telemóvel” não tem uma legenda associada.

    Tendo em conta a falta de acessibilidade dos formulários em PDF, recomendamos que o formulário seja disponibilizado diretamente no site, em vez de em formato PDF.

    Relativamente ao campo que não apresenta legenda, recomendamos que avaliem primeiro qual é o seu propósito. Se não existir uma função clara para este campo, sugerimos que seja removido. Caso decidam mantê-lo, recomendamos que seja adicionado uma legenda ao campo que indique de forma clara e inequívoca os dados a ser inseridos pelo utilizador. Por exemplo, “Telefone” ou “Segundo telemóvel”.

    Image

    Figura - Formulário PDF Formulário de Candidatura ao Procedimento Concursal da página Formulários. O campo cuja legenda está em falta está destacado através de um retângulo de borda roxa.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

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

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

    Verificámos que, nos formulários para subscrição da newsletter e da página Contactos, existem campos que apresentam a indicação visual “(Obrigatório)” junto ao respetivo rótulo, mas que não estão programaticamente definidos como obrigatórios.

    No caso do formulário de subscrição da newsletter, o campo relativo ao email não tem associado o atributo required ou aria-required. Na página Contactos, os campos “Nome”, “Email”, “Assunto” e “Telefone” também não possuem qualquer um destes atributos.

    Recomendamos que, para além do texto “(Obrigatório)” em frente ao rótulo do campo, seja também adicionado o atributo required nos campos de input de forma a reforçar aos utilizadores de tecnologias de apoio que o campo em questão é um campo de preenchimento obrigatório.

    Image

    Figura 1 - Análise do campo "Nome", no formulário da página Contactos, através do Google Inspector.

    Image

    Figura 2 - Anáise do campo para inserção do email, no formulário para subscrição da newsletter, através do Google Inspector.

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

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

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

    Verificámos que, nos formulários Formulário de Candidatura ao Procedimento Concursal e Formulário para o exercício do direito de participação dos interessados da página Formulários, não é possível reconhecer os campos de preenchimento obrigatório. Esta informação não é passada quer visualmente quer para os leitores de ecrã.

    Uma solução mais acessível seria disponibilizar os formulários diretamente no site, em vez de em formato PDF. Nos formulários web, os campos obrigatórios devem incluir os atributos required ou aria-required=”true” para serem identificados pelas tecnologias de apoio como obrigatórios.

    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 1 - Formulário Formulário de Candidatura ao Procedimento Concursal da página Formulários. Não é possível reconhecer os campos de preenchimento obrigatório quer visualmente quer através do leitor de ecrã.

    Image

    Figura 2 - Formulário Formulário para o exercício do direito de participação dos interessados da página Formulários. Não é possível reconhecer os campos de preenchimento obrigatório quer visualmente quer através do leitor de ecrã.

  • issue #51 Não é possível identificar campos obrigatórios em formulários do site

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

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

    Os campos dos formulários devem estar devidamente construídos e identificados como obrigatórios.

    No formulário para subscrição da Newsletter, localizado no rodapé do site, o leitor de ecrã não reconhece o campo “Sim, li e aceito os Termos e Condições e a Política de Privacidade.” como obrigatório.

    Os campos obrigatórios devem incluir o atributo required para serem identificados pelas tecnologias de apoio como obrigatórios.

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

    Image

    Figura - Análise do campo “Sim, li e aceito os Termos e Condições e a Política de Privacidade.”, no formulário para subscrição da newsletter, através do Google Inspector.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #8 Ausência de feedback em ações de longa duração

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

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

    Notas Gerais

    • Em ações de submissão ou processamento, o sistema deve fornecer feedback adequado ao utilizador, garantindo que este compreende que a operação está a decorrer.
    • A ausência de feedback em ações potencialmente demoradas pode gerar incerteza e levar o utilizador a repetir a ação ou a considerar que ocorreu um erro.

    URL a verificar

    Evidências:

    Ao desencadear a ação de pesquisa, o sistema não apresenta qualquer indicador de progresso. O tempo de resposta da operação é de aproximadamente 6 segundos, período durante o qual a interface permanece estática, sem comunicar ao utilizador que a informação está a ser processada.

    Image

    Figura 1 – Ausência de indicador de processamento durante os 6 segundos de espera da pesquisa

    Recomendações:

    • Implementar indicador visual: Adicionar um spinner ou ícone de carregamento imediato logo após o envio do formulário de pesquisa.
    • Notificação semântica: Utilizar um contentor com aria-live="polite" ou role="status" contendo uma mensagem textual (ex: "A pesquisar, por favor aguarde..."). Isto garantirá que utilizadores de leitores de ecrã também sejam informados sobre o estado da operação.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #16 Confirmação de sucesso invisível para tecnologias de apoio.

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

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

    Notas Gerais

    • Sempre que um utilizador realiza uma ação que implica o envio de informação (como a submissão de um formulário), o sistema deve fornecer uma confirmação clara de que a operação foi concluída com sucesso.
    • Esta confirmação deve ser apresentada de forma imediata, visível e programaticamente determinável, garantindo que todos os utilizadores, incluindo aqueles que utilizam navegação por teclado ou tecnologias de apoio, conseguem perceber que a ação foi concluída corretamente.

    URL a verificar

    Evidências:

    Nos formulários de contacto e subscrição de newsletter, após a submissão dos dados, a mensagem de sucesso não é apresentada de forma imediata ou percetível ao utilizador.

    Adicionalmente, não é possível aceder a essa mensagem através de navegação por teclado (Tab e Shift+Tab), o que indica que a mesma não se encontra no fluxo de foco da página.

    Como consequência, os utilizadores podem não perceber que a ação foi concluída com sucesso.

    Image

    Figura 1 – Mensagem de sucesso após subscrição da newsletter não acessível via teclado

    Image

    Figura 2 – Mensagem de sucesso após envio do formulário de contacto não acessível através de navegação por teclado

    Recomendações:

    • Garantir que a mensagem de sucesso é apresentada imediatamente após a submissão e posicionada junto ao formulário
    • Tornar a mensagem acessível no fluxo de foco (ex.: elemento focável ou gestão de foco automática para a mensagem)
    • Implementar anúncio automático para tecnologias de apoio (ex.: aria-live="polite" ou role="status")

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

    Não identificamos formulários que permitem o utilizador fazer ações destrutivas e por esse motivo, consideramos esse critério como "Não aplicável".

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #75 Existem formulários sem Mensagens de erro junto aos campos

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

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

    O formulário de subscrição de newsletter não apresenta mensagens de erro junto aos campos:

    Image

    Campo email do formulário de contactos sem mensagem de erro associada
    A única mensagens de erro apresentada ocorre no topo da página, e é apresentada durante um período de tempo:

    Image

    Mensagem de erro no topo da página
    As mensagens de erro devem ser apresentadas junto aos campos e, adicionalmente (é útil no caso da existência de um número elevado de campos no formulário), pode ser apresentada uma lista no topo do formulário com o sumário dos vários erros.
    Neste caso, a localização da mensagem “Erro: insira um email válido” no topo da página associada ao seu curto tempo de permanência no ecrã torna muito difícil a descoberta da mesma por parte dos utilizadores de leitores de ecrã.
    A mesma situação ocorre no formulário contactos, com uma variante: a mensagem de erro é apresentada apenas no topo do formulário, e o seu conteúdo (“Erro! Erro de validação contra robôs, tente novamente”) não descreve os erros existentes, mas sim um erro que o utilizador não vê:

    Image

    Conteúdo inadequado de mensagem de erro no formulário contactos
    Recomendamos que sejam apresentadas mensagens de erro junto aos campos de todos os formulários, para assim forenecerem apoio na correção dos mesmos e consequente submissão correta dos formulários.
    Adicionalmente, pode existir uma lista dos erros no topo de cada formulário que consolida os vários erros existentes, em que cada mensagem deve remeter para o respetivo campo (por exemplo, através da colocação da mensagem num link cujo href contenha o id do respetivo campo).
    Todas as mensagens de erro devem permanecer no ecrã até que o utilizador atualize a página, de modo a serem lidas o número de vezes que o utilizador pretender.

    Recomendamos ainda que as mensagens de erro sejam programaticamente associadas aos respetivos campos, para que os utilizadores que navegam por teclado (tab e shift+tab) e leitor de ecrã possam ouvir a mensagem de erro associada a cada campo à medida que o foco passa pelos campos. A mensagem a associar programaticamente a cada campo deve ser a que se encontra junto do mesmo.
    A associação programática de uma mensagem de erro a um campo pode fazer-se adicionando dois atributos a esse campo:

    • Um atributo aria-invalid com o valor “true”, que indica que o campo não está num estado válido;
    • Um atributo aria-describedby com o id do elemento que contém a mensagem de erro. Em alternativa ao atributo aria-describedby pode ser utilizado um atributo aria-errormessage, também preenchido da mesma forma, com o id do elemento que contém a mensagem de erro.

    A diferença entre os dois atributos é que o atributo aria-errormessage foi desenhado mais recentemente e pode ainda não ser suportado por todas as tecnologias, e tem o propósito específico de fazer a associação programática entre um campo e a respetiva mensagem de erro, enquanto que o atributo aria-describedby é mais antigo e mais genérico, servindo em particular para fazer esta associação programática.
    Um exemplo de associação seria:

    <input type = "text" name = "email" aria-invalid = "true" aria-describedby = "msgerroremail">
<div id = "msgerroremail" class="popupMessage themeGreen">Email não válido</div>

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

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

    A mensagem de erro “Erro: insira um email válido” presente no formulário de subscrição de newsletter não ajuda no preenchimento do campo:

    Image

    Mensagem de erro no topo da página que não guia o utilizador na resolução do erro

    Como observado na figura, a mensagem “Por favor digite um endereço de email” que é apresentada quando o campo foi preenchido com um formato incorreto não indica qual o formato a ser inserido, não ajudando a preencher o campo.
    O mesmo problema ocorre no formulário contactos.
    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 7 melhorias que se recomenda efetuar)

Lista de evidências recolhidas:

  • issue #92 Outras violações- Nome acessível dos links não corresponde ao texto visível

    etiqueta: melhoriaetiqueta: outras violações
    Descrição da problemática

    Verificou‑se que existem links cujo nome acessível, não corresponde ao texto visível apresentado ao utilizador. Em particular, o texto visível “Ver mais” não faz parte do nome acessível anunciado por tecnologias de apoio.

    Nos exemplos analisados no website, o nome acessível é definido através do atributo aria-label, com valores como:
aria-label="Sobre este evento: Exposição 'Zapping: Televisão como cultura e contracultura'", omitindo o texto visível “Ver mais”. Desta forma, utilizadores de leitores de ecrã escutam uma designação diferente daquela que é apresentada visualmente, o que pode causar confusão e dificultar a orientação e compreensão dos conteúdos. (Figura 1)

    Image

    Figura 1 – Inspeção de elementos no DOM demonstra esta discrepância entre o texto visível e o nome acessível.

    Esta situação repete‑se em todos os botões/links das secções Agenda e Notícias, nos quais o texto alternativo ou nome acessível não corresponde ao conteúdo visível, sendo substituído integralmente pelo título da notícia ou evento.

    Exemplos de outras páginas onde o problema ocorre:

    Recomendação de melhoria
    Assegurar que o nome acessível dos links e botões inclua sempre o texto visível apresentado ao utilizador, garantindo a consistência entre a informação visual e a informação anunciada por leitores de ecrã.
    Em particular, recomenda‑se que:

    • O texto visível (por exemplo, “Ver mais”) faça parte do nome acessível;
    • O atributo aria-label não substitua integralmente o texto visível, devendo apenas complementar quando estritamente necessário;

    A consistência seja aplicada de forma uniforme em todas as páginas e componentes semelhantes no website.

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

    etiqueta: melhoriaetiqueta: outras violações
    Descrição da problemática

    Ao navegar em todo o website utilizando apenas o teclado, o indicador de foco não 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, não é possível identificar visualmente qual o elemento que se encontra ativo em cada momento. 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.

    Por exemplo na página inicial, durante a navegação por teclado pelas "Últimas Notícias", o foco não é apresentado de forma perceptível nos elementos interativos, 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. (Figura 1)

    Image

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

    Recomendação de melhoria
    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;
    • 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 #90 Outras violações - Link “Saltar para os conteúdos” não percetível visualmente nem acessível a leitores de ecrã

    etiqueta: melhoriaetiqueta: outras violações
    Descrição da problemática

    Na estrutura do website encontra‑se disponível o link “Saltar para os conteúdos”, cuja finalidade é permitir aos utilizadores contornar blocos repetitivos de navegação e aceder diretamente à área principal do conteúdo. No entanto, este link não é apresentado de forma visível, não sendo identificado como um botão ou link interativo durante a navegação visual. (Figura 1)

    Image

    Figura 1 – Inspeção do link “Saltar para os conteúdos”

    Adicionalmente, não é devidamente percetível por tecnologias de apoio, como leitores de ecrã, comprometendo a sua função para utilizadores com deficiência visual ou que navegam exclusivamente por teclado. Esta situação impede que o mecanismo de salto cumpra o seu propósito de facilitar a navegação eficiente e inclusiva, reduzindo a usabilidade global do website e criando barreiras de acesso à informação.

    Recomendação de melhoria
    Assegurar que o link “Saltar para os conteúdos” seja:

    • Visualmente percetível, apresentando-se como um elemento interativo (link ou botão);
    • Disponível e visível quando recebe foco por teclado;
    • Corretamente identificado e anunciado por leitores de ecrã;
    • Posicionado de forma lógica no início da página, antes dos blocos de navegação repetitivos.

    O link deverá tornar‑se visível aquando da navegação por teclado (por exemplo, ao receber foco através da tecla TAB) e permitir que todos os utilizadores compreendam claramente a sua função.

  • issue #89 Outras violações - Existência de elementos fora de landmarks semânticos

    etiqueta: melhoriaetiqueta: outras violações
    Descrição da problemática

    Verificou‑se a presença de elementos interativos fora de landmarks semânticos, encontrando‑se diretamente “soltos” no elemento <body>, nomeadamente o botão de aceitação de cookies, botão de acessibilidade e a assistente (chatbot).

    A inexistência de enquadramento destes elementos em regiões semânticas apropriadas (por exemplo, <header>, <main>, <nav>, <aside> ou <footer>) compromete a sua deteção e interpretação por tecnologias de apoio. Em consequência, leitores de ecrã e a navegação por teclado podem não percorrer nem anunciar estes elementos, impossibilitando o acesso por parte de utilizadores com deficiência visual ou motora.

    Esta situação cria uma barreira significativa à acessibilidade, uma vez que funcionalidades essenciais ficam inacessíveis a determinados perfis de utilizadores, contrariando os princípios de perceção, operabilidade e robustez.
    As (Figuras 1 e 2) ilustram a inspeção de elementos que não são corretamente expostos a leitores de ecrã nem integrados no fluxo de navegação por teclado.

    Image

    Figura 1 – Assistente virtual não visível para leitores de ecrã e navegação por teclado

    Image

    Figura 2– Inspeção de elementos não visíveis fora de estrutura semântica

    Recomendação de melhoria
    Garantir que todos os elementos interativos do website estejam corretamente integrados em landmarks semânticos apropriados, de acordo com a sua função e localização lógica na página. Em particular, recomenda‑se que os botões e componentes interativos (cookies, acessibilidade, chatbot) sejam posicionados dentro de regiões semânticas adequadas.

    Sugestão para construção de Chatbots acessíveis: Chatbot Accessibility Playbook

  • issue #88 Outras violações - Botão com texto alternativo em inglês

    etiqueta: melhoriaetiqueta: outras violações
    Descrição da problemática

    Verificamos uma inconsistência linguística, uma vez que o website está em português mas há componente com o textos alternativos em inglês. Por exemplo as setas de controlo do carrossel com os textos “Previous slide” ou “Next slide”, sem indicação adequada do atributo lang. Dificultando a navegação para utilizadores do idioma português, língua em que o site é implementado. (Figura 1)

    Image

    Figura 1 - Textos alternativos de botões do carrossel em inglês

    Recomendação de melhoria
    Recomendamos traduzir todos os textos alternativos dos botões para português, idioma principal do website.

  • issue #87 Outras violações - Há hiperligações que redirecionam para páginas de erro

    etiqueta: melhoriaetiqueta: outras violações
    Descrição da problemática

    A página Bolsas para estudantes sanjoanenses do ensino superior 2019-2020 possui uma hiperligação que aponta para um conteúdo inexistente, originando uma página de erro 404. Ao aceder o conteúdo “clicando AQUI” o utilizador é redirecionado para página de erro e recebe a mensagem de “A página que procura pode ter sido movida, eliminada ou talvez nunca tenha existido.” (Figura 1)



    Image

    Figura 1 - Redirecionamento do conteúdo para página de erro

    Esta situação impede o acesso à informação e constitui uma barreira significativa na acessibilidade do conteúdo.

    Recomendação de melhoria
    Recomenda‑se atualizar todas as hiperligações para garantir que apontam para conteúdos atualizados e disponíveis no website.

  • issue #81 Outras violações - Uso inadequado de overlays de acessibilidade

    etiqueta: melhoriaetiqueta: outras violações
    Descrição da problemática

    Os overlays de acessibilidade são frequentemente utilizados como soluções rápidas, mas não corrigem os problemas reais do website. Estas ferramentas funcionam como camadas sobrepostas ao código existente, sem resolver falhas estruturais como erros de semântica, foco, landmarks ou navegação por teclado.

    Em todo website, é disponibilizado um “menu de acessibilidade” que em alguns casos, podem interferir com tecnologias de apoio (ex.: NVDA), criando comportamentos inesperados, atalhos redundantes ou problemas de apresentação, como textos muito pequenos que afetam a legibilidade e problemas de contraste (Figura 1 e 2).

    Image

    Figura 1 - Textos muito pequeno com ferramenta overlays de acessibilidade

    Image

    Figura 2 - Problemas de contraste com ferramenta overlays de acessibilidade

    Além disso, transmitem uma falsa perceção de conformidade, mantendo problemas de acessibilidade para utilizadores reais.

    Recomendação de melhoria
    Recomenda‑se que a acessibilidade seja assegurada prioritariamente através de boas práticas nativas: uso correto de HTML semântico, navegação por teclado funcional, contraste adequado e compatibilidade com tecnologias de apoio. Os overlays não devem substituir a correção estrutural do site, pois a melhoria da acessibilidade deve começar na base do código e não depender exclusivamente de ferramentas externas. Sendo assim, devem ser removidos do website.

Significado das etiquetas utilizadas