Relatório Avaliação de Candidatura
Câmara Municipal de Sátão (sítio Web institucional)

Introdução

O website https://www.cm-satao.pt etiqueta: não passa nos requisitos mínimos do Selo de Usabilidade e Acessibilidade.

Estado das avaliações efetuadas
Tipo de avaliaçãoEstado
Avaliação Automáticaetiqueta: NOK
Avaliação Manualetiqueta: NOK

Das avaliações manuais efetuadas obtiveram-se os resultados que se sintetizam na tabela seguinte.

Níveis de conformidade das avaliações manuais
ChecklistConformidade alcançadaResultado
10 aspetos50.0% (12/24)etiqueta: Não passa
Conteúdo47.1% (8/17)etiqueta: Não passa
Transação41.7% (5/12)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: 50.0% (12/24)
    • Requisitos avaliados: 27 (3 N/A excluídos, 24 aplicáveis)
    • Requisitos OK: 12
    • Requisitos NOK: 12
    • Requisitos N/A: 3

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 #111 Opções no rodapé não estão estruturados como lista

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.1

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

    Evidencias:
    No website CM de Sátão é possível identificar que existem links que não estão estruturados como listas, como por exemplo, as opções de download da app:

    URL a verificar
    https://www.cm-satao.pt/

    Recomendações:
    As opções de download da app devem ser agrupadas em uma lista ul li.

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

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

Lista de evidências recolhidas:

  • issue #93 Não é possível identificar qual opção está com foco pelo teclado

    etiqueta: chk 10 webetiqueta: R 1.2etiqueta: melhoria

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

    Evidencias
    Ao navegar pelas opções do menu utilizando o teclado, através das teclas TAB e SHIFT + TAB, não é perceptível a posição actual do utilizador nos botões de subopções do menu.

    Não é visível que o foco está no botão de abrir a subopção de áreas de atividade

    URLs a verificar

    Recomendações

    • Definir um estilo visível para o contorno dos elementos interativos, utiizando à propriedade outline em CSS.
    • Outra alternativa, é manter o comportamento nativo dos navegadores, procedendo à remoção dos atributos de contorno actualmente definidos em CSS.

Requisito 1.3 - As imagens-link, caso existam no menu, devem ter o correspondente equivalente alternativo em texto

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

Lista de evidências recolhidas:

  • issue #97 A imagem-link do menu principal possui texto alternativo

    etiqueta: chk 10 webetiqueta: R 1.3etiqueta: melhoria

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

    Evidências
    O menu principal do website da CM de Sátão apresenta imagens exibidas via CSS e o texto alternativo está sendo transmitido pelo aria-label:

    Ícone (▾) sendo apresentado via CSS

    Contudo, ao desligar o CSS não é possível identifica-lo corretamente pois o ícone desaparece e não é apresentado uma alternativa textual:

    URLs a verificar

    Recomendações

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 #116 Existem etiquetas em formulários PDF não discerníveis semanticamente

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.1

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

    O formulário participacao_alteracao_pdm está em formato pdf e não tem etiquetas discerníveis pelas tecnologias de apoio:

    Image

    Formulários como este excluem cidadãos do seu preenchimento

    URLs a verificar:
    participacao_alteracao_pdm
    Recomendações:
    Uma sugestão é ser disponibilizar os formulários diretamente em páginas web, garantindo melhor compatibilidade com leitores de ecrã e restantes requisitos de acessibilidade.

  • issue #115 Existem campos não agrupados em elementos <fieldset>

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.1

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

    Evidências:
    Os campos “País do número de telefone” e "contacto telefónico" não estão agrupados num elemento <fieldset>.

    Image

    campos não agrupados em elemento fieldset

    A etiqueta “Contacto telefónico” está associada programaticamente a um campo que não está adjacente a ela, havendo pelo meio uma combobox para escolha do país do número de telefone que não tem etiqueta associada.

    URLs a verificar:

    Recomendações:
    Recomendamos a colocação dos dois controlos num elemento fieldset com um elemento legend “Contacto telefónico”, e que os dois campos tenham cada um o respetivo label: “País do número de telefone” e “Número de telefone”.

  • issue #107 Existem etiquetas invisíveis no ecrã

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.1

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

    Evidências:
    O formulário De pesquisa de notícias tem as suas etiquetas invisíveis no ecrã.

    Image

    Apesar de os textos das etiquetas estarem visíveis para as tecnologias de apoio, não é possível fazer clique nos textos das mesmas para focar os respetivos campos, já que os elementos <label> estão ocultos

    Problema idêntico acontece no formulário de personalização de cookies, apesar de neste caso ter sido ocultado o texto da etiqueta e não a etiqueta:

    Image

    texto com a classe visually-hidden

    O problema acontece ainda no formulário de pesquisa geral do site:

    Image

    URLs a verificar:

    Recomendações:
    Recomendamos que as etiquetas de todos os formulários e os seus textos estejam visíveis no ecrã.

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 #118 Atributos required incorretamente aplicados em etiquetas

    etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 4.2

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

    Evidências:
    O formulário Agendamento de Reunião existem atributos required = “required” nas etiquetas:

    Image

    Mesmo no próprio campo é usada a forma required = “required”. Ora, esta sintaxe não existe. Ou bem que é utilizada a forma longa, required = “true”, ou bem que é utilizada a forma curta, required.
    Nas etiquetas, o atributo required não tem qualquer efeito, dificultando até a legibilidade e a manutenção do código.
    URLs a verificar:
    https://www.cm-satao.pt/balcao-virtual/atendimento/agendamento-de-reuniao
    Recomendações:
    Recomendamos que os atributos required apenas sejam aplicados aos campos e não às etiquetas.
    Nos campos, não devem ser utilizadas formas sintáticas incorretas deste atributo, pois a forma como diversas tecnologias de apoio ou browsers as vão interpretar é indeterminada.

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

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.2

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

    Evidências:
    Verificámos que, no formulário participacao_alteracao_pdm, os campos de preenchimento obrigatório não se encontram identificados de forma clara.

    A obrigatoriedade dos campos não é comunicada visualmente de forma evidente nem transmitida corretamente às tecnologias de apoio, como leitores de ecrã.

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

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

    Image

    Formulário “Participação alteração PDM” sem identificação clara dos campos de preenchimento obrigatório, quer visualmente quer através de tecnologias de apoio

    URLs a verificar:
    participacao_alteracao_pdm

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

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

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #66 Há imagens com textos alternativos incorretos

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.1

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

    Evidências:

    • As imagens não decorativas deverão ter uma descrição breve associada, nomeadamente através do uso do atributo . Esta legenda deve descrever fielmente o propósito da imagem no contexto em que se encontra.

    Há imagens informativas que não possuem um texto alternativo ou incorretos. A evidência (1) revela o carrossel de imagens da página “Praia Fluvial do Trabulo” onde há imagens com textos alternativos incorretos em relação ao conteúdo das imagens. Por exemplo, a imagem 04 do carrossel com alt="photo_19_04_17__14_11_50”. Sem contextualizar utilizadores de leitores de ecrã sobre o conteúdo das imagens. Recomendamos a inclusão de um texto alternativo mais descritivo das imagens para refletir fielmente o propósito da imagem no contexto em que se encontra.

    Image

    Figura 1 - Imagem com texto alternativo incorreto

    Na evidência (2), a página “Atividades do mês de janeiro da Universidade Sénior de Sátão” apresenta um cartaz em formato de imagem cujo texto alternativo é incorreto e não descreve os conteúdos. Como toda a programação (datas, horários, eventos e locais) está apenas dentro da imagem, utilizadores de tecnologias de apoio não conseguem aceder à informação da agenda, violando o presente requisito.

    Image

    Figura 2 - Cartazes informativos com texto alternativo incorreto

    Nas páginas interiores do website, as imagens que complementam o conteúdo apresentam problemas de acessibilidade com ausência de textos alternativos ou quando disponíveis estão incorretos, por exemplo nas imagens de destaque das páginas. (Figura 3 e 4)

    Image

    Figura 3 - Página interior de Notícia com imagens que complementam o conteúdo não possui uma descrição completa do seu contéudo

    Image

    Figura 4 - Imagens destaques de páginas interiores, como a página Áreas de Atividade com textos alternativos incorretos

    URLs a verificar

    Recomendação
    Recomendamos alterar o texto alternativo da imagem para algo que descreva o conteúdo da imagem de forma sucinta. As imagens com função informativa, que complementam o conteúdo do website, devem incluir um texto alternativo que sirva de síntese do seu conteúdo e que seja lido pelo leitor de ecrã.

    • Rever textos alternativos para que descrevam fielmente todas as imagens informativas e destaques de páginas interiores.
    • Caso seja necessário, incluir uma descrição longa da imagem, esta deve ser colocada próxima da imagem ou numa página à parte que esteja hiperligada à imagem em questão.
    • Nota: É necessário rever todas imagens informativas do website, e assegurar que as boas práticas associadas ao requisito são aplicadas de forma consistente e transversal a todas as páginas do website e não apenas nos apontamentos aqui colocados.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #52 Representações gráficas sem descrição longa

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.2

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

    Evidências:

    • A imagem complexa deve ser acompanhada não só de uma descrição curta, colocada como texto alternativo da imagem, mas também de uma descrição detalhada sobre o seu conteúdo, que represente de forma textual a informação mais relevante. Podemos considerar neste critério elementos como gráficos, diagramas, mapas, imagens, infografias, entre outros.
    • Gráficos resultantes de análise de dados deverão ser acompanhados da tabela de dados que lhe deu origem, de forma a preservar o acesso à informação completa.

    Na evidência (1) há representações gráficas em ficheiros PDFs na página Folhetos informativos, por exemplo o ficheiro “PR4 - Rota das Lagaretas” sem uma descrição longa alternativa. Embora o conteúdo textual esteja navegável, as imagens inseridas no PDF não possuem descrição adequada e são anunciadas pelos leitores de ecrã como “Gráfico sem etiqueta”. (Figura 1)

    Image

    Figura 1 - Imagens complexas em ficheiros PDFs sobre os "Percursos Pedestres do Município de Sátão" não possuem textos alternativos

    Além disso, há conteúdos que também são disponibilizados no corpo de páginas, por exemplo na página PR1 - Rota do Míscaro no entanto permanecem sem uma descrição longa alternativa. (Figura 2)

    Image

    Figura 2 - Imagens complexas da "Rota do Míscaro" não possuem textos alternativos

    Na página Resíduos Urbanos há imagens complexas inseridas em acordeões que apresentam textos alternativos incorretos e não incluem descrição longa. Adicionalmente, estas imagens se encontram apresentadas em dimensões reduzidas e com elevado nível de compressão, o que resulta em baixa legibilidade, mesmo quando ampliadas. (Figura 3)

    Image

    Figura 3 - Imagens complexas disponíveis em acordeões com textos alternativos incorretos e sem descrição longa

    URLs a verificar

    Recomendações:
    Recomenda-se que as imagens complexas sejam acompanhadas por textos alternativos adequados que apresente uma breve descrição da sua função. Além disso, quando trata-se de uma imagem complexa que inclui informação detalhada, é igualmente necessário disponibilizar uma descrição textual completa no próprio corpo da página. Esta descrição longa deve reproduzir, em formato textual estruturado, os elementos informativos essenciais presentes na imagem.

    • Adicionalmente, recomenda-se que a informação de imagens complexas sejam apresentadas diretamente em HTML estruturado na página, evitando que dados relevantes sejam transmitidos exclusivamente através de dados estáticos e inacessíveis em imagens. Esta abordagem garante que o conteúdo permanece acessível a utilizadores de leitores de ecrã, melhora a compreensão geral da informação e contribui para a conformidade com os critérios de acessibilidade aplicáveis ao conteúdo não textual.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #51 Imagens-link com textos alternativos incorretos

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.3

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

    Evidências

    • As hiperligações compostas apenas por uma imagem obrigam que esta tenha um equivalente alternativo em texto que represente fielmente o destino da hiperligação.

    Na evidência (1) identificamos no carrossel “Ligações úteis” links com imagens que possuem textos alternativos incorretos. Estas imagens direcionam para páginas externas, mas os respetivos textos alternativos não indicam essa ação nem descrevem o conteúdo ou o destino do link. Por exemplo, a imagem‑link “Qualidade de Água” apresenta o texto alternativo alt="gota", que não transmite qualquer informação útil ao utilizador.

    Image

    Figura 1 - Imagens decorativas com textos alternativos incorretos

    Esta prática gera ruído na leitura por tecnologias de apoio, prejudica a compreensão da função das hiperligações e não cumpre o presente requisito. Nesses casos, que já existe um título associado e descritivo referente ao conteúdo do logotipo, as imagens não acrescentam informação relevante e devem ser tratadas como decorativas, utilizando um texto alternativo vazio (alt="").

    URLs a verificar:

    Recomendações
    Recomendamos a revisão das imagens-link e atualização dos seus textos alternativos, assegurando que descrevem de forma clara e objetiva o conteúdo e o destino da hiperligação

    • É necessário rever as boas práticas de acessibilidade em todas as páginas do website, uma vez que as evidências apresentadas refletem problemas recorrentes e críticos, como textos alternativos incorretos, uso inadequado de atributos e padrões inconsistentes. A correção deve ser aplicada de forma transversal, garantindo que a acessibilidade seja tratada como padrão e não apenas nos apontamentos aqui colocados.

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 #68 Problemas de contraste para texto normal

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 6.1

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

    Evidências:

    • Contraste inferior para elementos textuais, elementos da interface e objetos gráficos.

    A evidência (1) revela problemas no rácio de contraste do menu principal da página, os textos que utilizam a cor #C4D600 e #FFFFFF como cor de plano de fundo. Não passam na avaliação de contraste. O mesmo acontece nas páginas secundárias, por exemplo na evidência (2).

    Image

    URLs a verificar

    Recomendações

    • Recomendamos a revisão das cores das páginas e dos vários estados dos elementos 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:

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 #91 O botão do menu compacto (mobile e tablet) está visível para leitores de ecrã em desktop

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.2

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

    Evidencia
    É possível identificar o botão do menu compacto na versão desktop, utilizando o navegador Safari. Por exemplo, embora o menu esteja oculto através do CSS com o atributo display: none, ele continua visível juntamente com as restantes opções do menu principal:

    Image

    Embora o botão menu compacto esteja escondido via CSS através do display:none ele está a ser anunciado pelo leitor de ecrã dentro da navegação do menu principal

    Recomendações

    • Deve ser utilizado o atributo aria-hidden tanto no menu desktop como no menu compacto. O menu que estiver visível no momento deverá ter aria-hidden="false", enquanto o outro deverá manter aria-hidden="true".

  • issue #89 Existem elementos que estão a ser lidos apenas pelos leitores de ecrã

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.2

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

    Evidencia
    Nas páginas internas é apresentada um campo de pesquisa na qual se verifica a existência de um input do tipo type="image". Esta construção é válida, uma vez que este tipo de input é semelhante a um botão do tipo submit. No entanto, existe uma label associada a este input, o que é incorreto, sendo essa label visível apenas para leitores de ecrã gerando ruídos na navegação:

    Image

    Campo de pesquisa estruturado com o botão do tipo input type="image" e com duas tags label visíveis para os leitores de ecrã

    Recomendações

    • Relativamente ao campo de pesquisa, é necessário verificar todos os locais onde este é apresentado, garantindo que não é utilizada uma label associada a botões do tipo type="image".

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:

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: N/A

Lista de evidências recolhidas:

  • issue #123 Não foram encontradas modais

    etiqueta: N/Aetiqueta: chk 10 webetiqueta: R 9.1

    Quando a caixa de diálogo é aberta, o foco (cursor do Browser) move-se para um elemento dentro da caixa de diálogo
    – ver requisito 9.1 na lista 10 aspetos

    Evidências
    Não foram encontradas modais no site da Câmara Municipal de Sátão. Assim, este requisito é avaliado como “Não Aplicável” (N/A).

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: N/A

Lista de evidências recolhidas:

  • issue #124 Não foram encontradas modais

    etiqueta: N/Aetiqueta: chk 10 webetiqueta: R 9.2

    Quando uma caixa de diálogo está aberta, a navegação com teclado (Browser ou Tecnologia de apoio) tem de ficar circunscrita aos elementos que compõem a caixa de diálogo
    – ver requisito 9.2 na lista 10 aspetos

    Evidências
    Não foram encontradas modais no site da Câmara Municipal de Sátão. Assim, este requisito é avaliado como “Não Aplicável” (N/A).

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

etiqueta: NOK

Lista de evidências recolhidas:

Requisito 9.4 - Quando a caixa de diálogo fecha, o foco (cursor do Browser) deve voltar ao elemento interativo que a invocou

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #126 Não foram encontradas modais

    etiqueta: N/Aetiqueta: chk 10 webetiqueta: R 9.4

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

    Evidências
    Não foram encontradas modais no site da Câmara Municipal de Sátão. Assim, este requisito é avaliado como “Não Aplicável” (N/A).

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: 47.1% (8/17)
    • Requisitos avaliados: 17 (17 aplicáveis)
    • Requisitos OK: 8
    • Requisitos NOK: 9

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #46 Existem siglas que não possuem definição no website

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

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

    Evidencia
    Algumas siglas personalizadas podem não tornar explícito o seu significado para todos os utilizadores. Por exemplo, a sigla TELM pode ser interpretada como o número de telefone do município ou telemóvel, mas essa associação pode não ser imediata ou clara para quem consulta a informação:

    URL a verificar
    https://www.cm-satao.pt/contactos

    Recomendação

    • Não utilizar abreviações personalizadas. Nesse caso, devem alterar a abreviação para o seu significado completo escrito (telemóvel?)

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 #41 A informação sobre contactos no rodapé possui tamanho inferior a 16px

    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

    Evidencias

    O website apresenta o contacto principal da câmara municipal no rodapé da página. Contudo, apesar da relevância dessa informação, a mesma encontra-se classificada como conteúdo secundário e é apresentada com um tamanho de fonte inferior a 16 píxeis:

    URL a verificar

    Recomendação

    • Alterar o tamanho do texto para que seja, de no mínimo, 16px.

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 #38 O conteúdo tem um tamanho de texto inferior a 10pt (13.3px)

    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

    Evidencias

    Foram encontrados textos cujo tamanho está abaixo de 13.3px. Por exemplo, os dias da semana da tabela estão com tamanho de 12px:

    URL a verificar
    https://www.cm-satao.pt/eventos

    Recomendação
    Alterar o tamanho do texto para que seja, de no mínimo, 16px (1rem):

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

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

Lista de evidências recolhidas:

  • issue #128 Breadcrumbs não representam corretamente a localização do utilizador

    etiqueta: chk conteúdoetiqueta: melhoriaetiqueta: R 3.2

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

    Evidências:
    Verificámos que, nos sites mencionados abaixo, as breadcrumbs não representam corretamente a posição do utilizador na estrutura do site nem o percurso de navegação até à página atual.

    Image

    Figura - Página Prestação de Contas no site do Município de Sátão. O caminho de breadcrumbs (Início > Autarquia > Serviços Financeiros) que aparece na página está incompleto. Breadcrumbs destacado através de um retângulo de borda preta.

    Recomendações:
    Recomendamos reformular este componente para que apresente, de forma precisa, a página onde o utilizador se encontra e o trajeto desde a página inicial.

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 #15 O layout do sítio Web é adaptável a plataforma móveis

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 4.2

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

    Evidências

    • O layout do site deve ter comportamento responsive, ou seja, deve-se adaptar às diferentes resoluções de ecrãs, de forma a garantir que a navegação seja fluída e não haja conteúdo cortado.

    A página inicial do website, revela que o campo de pesquisa não se adapta às diferentes resoluções de ecrã, pois sobrepõe os elementos interativos das redes sociais do Município. O mesmo problema se repete nas páginas principais de todo o website, por exemplo nas evidências (2 e 3).

    Figura 1 - Erro de responsividade no website Satão

    URLs a verificar

    Recomendação
    Recomendamos rever e corrigir espaçamento e margens responsivas entre conteúdos e textos das áreas clicáveis, por exemplo entre o campo de pesquisa e os ícones das redes sociais, assegurando espaçamento adequado. Garantir que todo o layout do site, possuem comportamento responsive e adaptam-se às diferentes resoluções de ecrã, sem necessidade de fazer varrimento horizontal para realizar a leitura dos conteúdos.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #14 Existem elementos interativos acionados apenas com a passagem do rato (hover)

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.1

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

    Evidências:

    • Não devem existir elementos de interação, como hiperligações ou botões, que aparecem apenas quando se passa por cima com um dispositivo apontador. Este método de interação não está disponível em aparelhos com interação por toque.

    A evidência (1) indica que, na página inicial, o chatbot é acionado apenas através da interação por hover. Ao passar o rato, surge a mensagem “Fale connosco – Precisa de ajuda?”. No entanto, quando um elemento interativo depende exclusivamente do hover para ser ativado ou para revelar informação, torna-se inacessível para utilizadores que recorrem a tecnologias de apoio, bem como para quem utiliza dispositivos móveis baseados em toque. (Figura 1)

    Image

    Figura 1 - Chatbot disponível apenas com hover

    Além disso, na página PR1 - Rota do Míscaro, o carrossel de fotos possui setas interativas de controlo que só são ativas quando passamos o rato(hover) pelas imagens do carrossel. (Figura 2)

    Image

    Figura 2 - Setas interativas do carrossel de imagens no website disponíveis apenas com hover

    Esta limitação compromete a perceção da funcionalidade e impede o acesso equitativo ao serviço disponibilizado.

    URLs a verificar

    Recomendação
    Garantir que os elementos interativos podem ser acionados por diferentes métodos de interação incluindo teclado, toque e tecnologias de apoio. Ou seja permitir interação inclusiva das setas interativas dos carrosséis de fotos, e que o chatbot incluindo a mensagem associada "Fale Connosco" é apresentada de forma visível e acessível sem depender exclusivamente do hover. Rever estrutura do carrossel (Ver nota do Requisito 8.3 - 10 Aspetos)

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 #13 Os elementos interativos têm uma dimensão mínima de 44px

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.2

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

    Evidências:

    • Para garantir que os utilizadores interagem devidamente com um elemento interativo (botões, imagens-link...), a área clicável desse elemento deve ser, no mínimo, 44px de largura e 44px de altura.

    A evidência (1) revela que na página inicial, a secção “Agenda” há um elemento interativo com área clicável inferior a dimensão mínima exigida (44px de altura e largura). O botão “Ver todos os eventos” com altura de 23px, não cumprindo as dimensões mínimas necessárias.

    Image

    URLs a verificar

    Recomendações
    Devem garantir que os elementos interativos têm uma altura e largura igual ou superior a 44px de área clicável, mesmo que o ícone/imagem tenha um tamanho inferior.

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 #12 Há apenas um botão de ação principal por página e o mesmo encontra-se destacado

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.3

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

    Evidências

    • Os botões de ação principal devem estar destacados numa página ou num bloco de informação para tornar mais perceptível o local onde os utilizadores devem clicar para realizar uma determinada tarefa.

    Na evidência (1) a página “Newsletters” revela que o botão de ação principal “Submeter” possui um estilo semelhante a outros elementos interativos da interface, neste caso os cards das newsletter. Sendo assim, pode gerar dificuldade de perçepcão para os utilizadores.

    Image

    URLs a verificar

    Recomendações
    Os botões principais devem ser estilizados de forma diferente dos botões de ação secundária. Pode-se também distinguir os botões através da forma (ex: preenchimento, delineamento, cantos arredondados).

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #11 Elementos interativos devem aparentar ser clicáveis

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.4

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

    Evidências

    • Os elementos interativos devem ter um estilo que demonstre que são clicáveis e, ao mesmo tempo, suficientemente diferente de elementos não clicáveis para que não se confundam.
    • O contraste em elementos interativos deve ser de, no mínimo, 3:1 em relação a cor adjacente. Este contraste é aplicado a todos os estados dos elementos (normal, hover, focus, etc). Quando o elemento possui conteúdo em texto, o contraste deve ser de no mínimo, 4,5:1 com a cor de fundo.

    A evidência (1) demonstra que a página inicial contém elementos interativos com contraste insuficiente. Os ícones dos botões “Atendimento”, “Documentos”, “Biblioteca online” e “IGT/PDM/Planos” por exemplo, utilizam a cor #FFFFFF sobre o fundo #ADDA19 que apresenta um contraste de apenas (1,6:1).

    Figura 1 - Botões da página inicial Município de Satão, com baixo contraste

    A evidência (2) demonstra que a página “Newsletters” contém elementos interativos com contraste insuficiente. Os botões “Submeter”, e os cards das respetivas newsletters, utilizam a cor #C4D600 sobre o fundo #FFFFFF que apresenta um contraste de apenas (1,6:1) inferior ao recomendado.

    Figura 2 - Página Newsletter com problemas de contraste em botões

    URLs a verificar

    Recomendações
    Rever o estilo dos elementos não clicáveis para garantir que se distinguem dos elementos interativos. É necessário a revisão das cores dos vários estados dos elementos para garantir os valores mínimos de contraste em elementos interativos.

Checklist Transação

etiqueta: NOK

Nível de conformidade:

  • Checklist Transação: 41.7% (5/12)
    • Requisitos avaliados: 13 (1 N/A excluído, 12 aplicáveis)
    • Requisitos OK: 5
    • Requisitos NOK: 7
    • Requisitos N/A: 1

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 #29 A sequência de tabulação não segue a sequência de preenchimento nos documentos PDF

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

    Evidências

    Na análise o ficheiro PDF Disponível na página Bolsas Académicas e de Mérito através do browser e do Adobe Acrobat Reader, foi verificado como um formulário longo cujo conteúdo está distribuído em 3 páginas, respetivamente.

    No entanto, como este formulário PDF não está acessível, os utilizadores que dependem de leitores de ecrã não conseguem aceder devidamente ao seu conteúdo. (Figura 1)

    Image

    Figura 1 - Formulário PDF inacessível através do Browser

    Apesar de ser possível aceder ao conteúdo com o leitor de ecrã NVDA e Adobe Reader, a navegação por teclado (Tab e Shift+Tab) não funciona, apenas com setas direcionais e sem direcionamento do foco. Ainda assim, o formulário apresenta problemas na sequência de tabulação onde existem saltos de informações, excluindo preenchimentos de campos de checkbox, por exemplo na secção “10 -Apreciação Júri” com um salto do campo “Bolsa Acadêmica” para o campo “A Candidatura Reúne os requisitos” (Figura 2)

    Image

    Figura 2 - Análise do formulário Ficha de Inscrição através de navegação por teclado (Teclas direcionais) com leitor de ecrã NVDA no Adobe Acrobat Reader.

    URLs a verificar

    Recomendações

    • Recomenda-se que para formulário PDF, a solução mais acessível seria disponibilizar o formulário diretamente no site, em vez de em formato PDF.

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:

  • issue #28 Formulários PDF inacessíveis para leitores de ecrã

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

    Os formulários com mais de 2 ecrãs de altura devem ser distribuídos por várias páginas.
    – ver requisito 1.2 na lista Transação

    Evidências

    Na análise foi verificado o ficheiro PDF disponível na página Bolsas Académicas e de Mérito através do browser e do Adobe Acrobat Reader, e foi verificado que é um formulário longo cujo conteúdo está distribuído em 3 páginas, respetivamente. (Figura)

    Image

    Figura 1 - Formulário com divisão por páginas

    No entanto, como este formulário PDF não está acessível, os utilizadores que dependem de leitores de ecrã não conseguem aceder devidamente ao seu conteúdo.

    Apesar do formulário possuir distribuição faseada por páginas, ao aceder o conteúdo com o leitor de ecrã NVDA e Adobe Reader, a navegação só funciona com setas direcionais e por tabelas. No entanto, não há gerenciamento de foco e também não é possível que utilizadores preencham campos e façam a navegação por cabeçalhos. (Figura 2)

    Image

    Figura 2 - Análise do formulário Ficha de Inscrição que apresenta falhas na acessibilidade através de navegação por teclado (Teclas direcionais), tabelas e cabeçalhos com leitor de ecrã NVDA no Adobe Acrobat Reader.

    URLs a verificar

    Recomendações

    • Recomenda-se que para formulário PDF, a solução mais acessível seria disponibilizar o formulário diretamente no site, em vez de em formato PDF.

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:

  • issue #27 Formulários PDF inacessíveis para leitores de ecrã

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

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

    Na análise o ficheiro PDF Disponível na página Bolsas Académicas e de Mérito através do browser e do Adobe Acrobat Reader, foi verificado como um formulário longo cujo conteúdo está distribuído em 3 páginas, respetivamente.

    No entanto, como este formulário PDF não está acessível, os utilizadores que dependem de leitores de ecrã não conseguem aceder devidamente ao seu conteúdo. (Figura 1) é um formulário que têm a sequência de passos ilustrada sendo dividido em 10 etapas (“1.RESERVADO AOS SERVIÇOS”, “2 IDENTIFICAÇÃO DA/O REQUERENTE”, etc.). (Figura 1)

    Image

    Figura 1 - Formulário PDF sequência de passos ilustrada, mas inacessível na navegação com ( (Tab e Shift+Tab)

    No entanto, como estes formulários PDF não são acessíveis, os utilizadores que dependem de leitores de ecrã não conseguem aceder devidamente ao seu conteúdo.

    Além disso, há alguns problemas nas divisões das etapas, pois há dois títulos para a etapa 9 (Declarações e Observações). (Figura 2)

    Image

    Figura 2 - Análise do formulário Ficha de Inscrição através de navegação por teclado (Teclas direcionais) com leitor de ecrã NVDA no Adobe Acrobat Reader.

    URLs a verificar
    https://www.cm-satao.pt/balcao-virtual/documentos/bolsas-academicas-e-de-merito

    Recomendações

    • Recomenda-se que para formulário PDF, a solução mais acessível seria disponibilizar o formulário diretamente no site, em vez de em formato PDF.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    Evidências:
    Na página Agendamento de Reunião, os campos “Tipo de Atendimento” e “Área de Atendimento”, têm uma largura maior do que o necessário para o tipo de informação a introduzir.

    Image

    Figura 1 – Análise do campo “Tipo de Atendimento” do formulário da página Agendamento de Reunião.

    Image

    Figura 2 – Análise do campo “Área de Atendimento” do formulário da página Agendamento de Reunião.

    URL a verificar:
    Página Agendamento de Reunião

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

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #131 Exibição de campo inativo

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

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

    Evidências:
    Na página Agendamento de Reunião, verificámos que, ao selecionar certas opções nos campos “Tipo de Atendimento” e “Área de Atendimento”, surge um campo adicional. Por exemplo: ao escolher “Online” no campo “Tipo de Atendimento” e “Testes” na “Área de Atendimento”, aparece o campo “Operador”.
    No entanto, este campo surge desativado — tanto para utilização com rato como para navegação com leitor de ecrã — e é apresentada a seguinte mensagem:
    “Não foram encontradas vagas para os critérios selecionados. Por favor ajuste as opções e tente novamente.”

    Image

    Figura – Análise da página Agendamento de Reunião com a opção “Online” selecionada no campo “Tipo de Atendimento” e “Testes” no campo “Área de Atendimento”.

    URL a verificar:
    Página Agendamento de Reunião

    Recomendações:
    Diante disto, deixamos a seguinte questão: se não existem vagas disponíveis para uma determinada Área de Atendimento, como é o caso de “Testes”, faz sentido que essa opção continue a aparecer na lista suspensa?

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #133 O texto placeholder está visualmente a substituir a label

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

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

    Notas gerais:
    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.
    Manter a label visível no ecrã, amplia-se a área de clique, o que pode beneficiar pessoas com dificuldades motoras ao selecionar um campo específico.

    Evidências:
    Nos formulários das páginas Arqueológico, Natural e na pesquisa geral, no cabeçalho do site, existem rótulos associados aos campos dos formulários que não são visíveis na interface gráfica. Estes rótulos só podem ser percebidos por quem utiliza leitores de ecrã.
    Como consequência, utilizadores que não usam tecnologias assistivas ficam dependentes apenas do texto placeholder para compreender a função de cada campo.

    Image

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

    URLs e componentes a verificar:

    • Página Arqueológico – Campo “Nome” e “Categoria”;
    • Página Natural - Campo “Nome” e “Categoria”;
    • Campo de pesquisa geral no cabeçalho do site;

    Recomendações:
    Recomendamos a revisão dos formulários para garantir que:
    • são atribuídas legendas aos campos utilizando o elemento

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

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

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

    Evidências:
    Verificámos que nos campos “Nome” das páginas Arqueológico e Natural, a legenda(“Texto”), que é transmitida por tecnologias assistivas mas não está visível na interface gráfica, não é clara.

    Image

    Figura 1 – Análise do campo “Nome” da página Arqueológico através do Google Inspector.

    Image

    Figura 2 – Análise do campo “Nome” da página Natural através do Google Inspector.

    URLs a verificar:

    Recomendações:
    Recomendamos que o rótulo(“Texto”) e o texto placeholder (“nome”) estejam em sintonia para transmitir de forma mais clara a informação que é necessário inserir nos respetivos campos.

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

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

Lista de evidências recolhidas:

  • issue #134 Atributo required aplicado incorretamente nos controlos do formulário

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

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

    Evidências:
    Verificámos que, no formulário da página Agendamento de Reunião, os campos “Tipo de Atendimento”, “Área de Atendimento” e “Operador” não estão a indicar corretamente, de forma programática, que são de preenchimento obrigatório. Nos elementos <select> destes campos é utilizada a expressão required=”required”. Apesar de o leitor de ecrã reconhecer estes campos como obrigatórios, esta não é a forma semanticamente mais adequada de o declarar.

    Image

    Figura 1 – Análise do campo “Tipo de Atendimento”, da página Agendamento de Reunião, através do Google Inspector.

    Image

    Figura 2 – Análise do campo “Área de Atendimento”, da página Agendamento de Reunião, através do Google Inspector. Expressão required = "required" destacada através de um retângulo de borda preta.

    URL a verificar:
    Página Agendamentos - Campos “Tipo de Atendimento”, “Área de Atendimento” e “Operador”.

    Recomendações:
    Recomendamos utilizar o atributo required diretamente no elemento <select> quando o campo corresponde a uma lista suspensa.
    Recomendamos também aplicar o atributo required apenas no próprio controlo de formulário, evitando colocá-lo no elemento <label>, uma vez que o rótulo não deve transmitir obrigatoriedade de forma programática.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #22 Em ações longas o sistema deve dizer o que está a acontecer

    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

    Evidências:
    Quando o utilizador introduz o email, o sistema gera automaticamente um código de validação e envia-o para o email indicado, permitindo validar o endereço durante o preenchimento do formulário. No entanto, esta ação não é comunicada aos leitores de ecrã, que não são notificados de que algo está acontecendo e que foi enviado um código de validação para prosseguir. O utilizador precisará navegar numa modal, para encontrar a informação de que precisa:

    A mensagem não é identificada pelo leitor de ecrã. Para além disso ela pode ser mais explícita

    Leitor de ecrã anuncia que está no campo de preenchimento do código sendo que o utilizador não sabe sequer que foi enviado um código

    URLs a verificar
    https://www.cm-satao.pt/balcao-virtual/formularios/atividades-de-educacao-ambiental

    Recomendações:

    • Alterar a mensagem para que indique claramente o que está a acontecer. Por exemplo: Enviando código para o email indicado.
    • A mensagem de envio deve ser automaticamente anunciada para o leitor de ecrã.

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

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

Lista de evidências recolhidas:

  • issue #21 O Sucesso do envio/submissão da informação é confirmada

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

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

    Evidencias

    O critério está a cumprir, mas é possível fazer melhorias: é apresentado uma mensagem de confirmação de envio do formulário. A mensagem está sendo automaticamente identificada pelos leitores de ecrã, mas isso não acontece em todos os formulários:

    Formulário de atividades de educação ambiental: a mensagem de sucesso não é automaticamente anunciada pelo Voice Over

    Formulário de newsletter: a mensagem de sucesso é automaticamente anunciada pelo Voice Over

    Formulário de newsletter: a mensagem de sucesso é automaticamente anunciada pelo NVDA

    URLs a verificar

    Recomendação
    Verificar todos os formulários do website para garantir que as mensagens de confirmação de envio sejam anunciadas automaticamente para os leitores de ecrã.

Requisito 4.2 - As ações destrutivas nunca devem ser permanentes; deve ser sempre possível desfazer a operação

etiqueta: N/A

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

Requisito 4.4 - As mensagens de erro devem mostrar os passos concretos para a resolução dos mesmos

etiqueta: NOK

Lista de evidências recolhidas:

Outras violações

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

Lista de evidências recolhidas:

  • issue #50 Outras violações - Páginas com erros no acesso de conteúdos

    etiqueta: melhoriaetiqueta: outras violações

    Evidências:

    Na página RSS Feed, existe uma componente de acordeão com as opções “RSS Notícias” e “RSS Eventos” no decorrer da navegação, ao pressionar uma das opções o utilizador é direcionado a páginas com erros. (Figura 1 e 2)


    Image

    Figura 1 - Conteúdo com erros nos acordeões

    Image

    Figura 2 - Exemplos de página com erro ao clicar em "RSS de Notícias"

    Este comportamento compromete a previsibilidade e a robustez da interação, podendo causar perda de acesso a informação e frustração na navegação para utilizadores.

    URLs a verificar

    Recomendações
    Validar o comportamento acordeão e verificar erro associado.
    Apresentar mensagens claras ao utilizador sempre que ocorra perda de sessão ou necessidade de reinício do processo;

  • issue #10 Outras violações - Existem páginas que apresentam quebra de layout

    etiqueta: melhoriaetiqueta: outras violações

    Evidências
    Verificámos uma quebra de layout em campos de prenchimento e mensagens de erro de formulários. Por exemplo, na página da Pesquisa, com problemas de sobreposição da botões sobre o texto do placeholder, onde a componente surge visual e estruturalmente desformatada. (Figura 1)

    Image

    Figura 1 - Problemas de quebra de layout na componente de Paginação

    Esta situação compromete a legibilidade, a distinção entre elementos e a correta perceção da hierarquia da interface, podendo causar dificuldades na identificação do estado atual do preenchimento do campo.

    URLs a verificar

    Recomendações
    Deve ser ajustado o posicionamento e a hierarquia visual dos elementos, definição de limites consistentes de largura e extensão para a componente de paginação, garantindo a sua apresentação uniforme em todas as páginas. Recomenda-se assegurar uma separação clara entre componentes, validando o comportamento em diferentes resoluções para um comportamento responsivo adequado e níveis de zoom.

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

    etiqueta: melhoriaetiqueta: outras violações

    Evidências:

    Na página , verificam-se conteúdos com informação incompleta ou não desenvolvida, nomeadamente na secção de “Parcerias”.

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

    Image

    Figura 1 -Conteúdo não desenvolvido com mensagem “Brevemente disponível”

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

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

    URLs a verificar:

    Recomendações:

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

  • issue #7 Outras violações- Páginas com conteúdo indisponível (Google maps)

    etiqueta: melhoriaetiqueta: outras violações

    Evidências

    • Páginas com Serviço indisponível, estão desatualizadas ou levam a conteúdos removidos, impedindo o utilizador de aceder ao conteúdo pretendido e comprometendo a navegação.

    Foram identificadas páginas no website que incluem uma secção designada “Localização”, na qual deveria estar disponível um mapa interativo do Google Maps correspondente ao local apresentado. Contudo, esse conteúdo encontra-se indisponível.

    Por exemplo, na página Igreja de Santa Maria, o mapa não é carregado, sendo exibida apenas a mensagem: “Serviço indisponível - Clique aqui para ver o ponto no Google Maps”. (Figura 1)

    Image

    Figura 1 - Conteúdos indisponíveis no website

    Esta situação compromete a apresentação da informação, causa frustração no acesso do conteúdo e limita a experiência e acessibilidade da informação.

    URLs a verificar:

    Recomendações

    • Garantir que o componente do Google Maps é corretamente carregado e apresentado em todas as páginas onde está previsto.
    • Validar a integração com a API do Google Maps (chaves, permissões e configurações) para prevenir falhas de carregamento.
    • Assegurar que, em caso de indisponibilidade do mapa, é fornecida uma alternativa acessível e funcional, como uma ligação claramente identificada para o Google Maps ou coordenadas geográficas em texto.
    • Caso se conclua que esta informação não acrescenta valor relevante ao conteúdo da página, recomenda-se a remoção da secção “Localização”. Em alternativa, deverá ser disponibilizada apenas uma ligação clara para o Google Maps, devidamente identificada como redirecionamento externo. Desta forma, evita-se transmitir aos utilizadores a perceção de conteúdo indisponível ou de uma área incompleta/vazia na página.

Significado das etiquetas utilizadas