Relatório Avaliação de Candidatura
Portal das Bolsas de Estudo de Câmara de Lobos

Introdução

O website https://bolsadeestudo.cm-camaradelobos.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 aspetos44.0% (11/25)etiqueta: Não passa
Conteúdo35.3% (6/17)etiqueta: Não passa
Transação50.0% (5/10)etiqueta: Não passa

Nota: para passar os requisitos do Selo é necessário alcançar um nível de conformidade superior ou igual a 75% em cada uma das 3 checklists.

Avaliação automática

etiqueta: NOK

Para a produção das evidências do presente capítulo, foram utilizadas ferramentas automatizadas de avaliação de requisitos de acessibilidade de acordo com a norma WCAG 2.1 'AA'. A amostra em análise pelas ferramentas é composta pela Homepage mais todas as páginas diretamente hiperligadas por ela, pertencentes ao domínio.

Lista de evidências recolhidas:

Avaliação manual

etiqueta: NOK

A avaliação manual é feita por inspeção perícial dos diversos requisitos constantes da:

Sempre que os auditores localizam uma falha grave de um requisito de acessibilidade que, embora não faça parte do esquema de requisitos do Selo, se enquadre no âmbito das violações das WCAG 2.1 'AA' do W3C, tal referência é anotada em "Outras violações" do presente capítulo. Apesar destas violações não se apresentarem com carácter vinculativo no esquema de requisitos do Selo, recomenda-se que as mesmas sejam corrigidas.

Checklist 10 aspetos

etiqueta: NOK

Nível de conformidade:

  • Checklist 10 aspetos: 44.0% (11/25)
    • Requisitos avaliados: 27 (2 N/A excluídos, 25 aplicáveis)
    • Requisitos OK: 11
    • Requisitos NOK: 14
    • Requisitos N/A: 2

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #40 O menu principal não está estruturado como lista

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.1

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

    Evidencias
    As opções do menu principal estão agrupadas através de uma tag div genérica e não possuem semântica de uma lista:

    URls a verificar
    -https://bolsadeestudo.cm-camaradelobos.pt/

    Recomendações

    • As opções "Lobo Digital", "Informações", "Consultar" e "Candidatura" devem ser estruturadas dentro de uma lista não ordenada ul li.

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

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.2

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

    Evidencias

    Verifica-se que não está a ser utilizado a tag nav no menu. Ao utilizar o leitor de ecrã, não é possível realizar saltos diretamente para o menu, nem este é identificado como uma área de navegação:

    Menu mobile não está definido como navegação

    Menu desktop não está definido como navegação

    URL

    Recomendações

    • Verificar o menu mobile e desktop.
    • O menu deve ser estruturado dentro de uma tag nav.

  • issue #41 O menu mobile não está acessível para leitores de ecrã e teclado

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.2

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

    Evidencias

    Quando navegamos com o leitor de ecrã ou através do teclado, não é possível abrir o menu mobile. Isto ocorre porque o menu está estruturado como uma div, não sendo reconhecido como um elemento interativo não sendo acionável pelas tecnologias de apoio nem por teclado:

    URL

    Recomendações

    • Estruturar o menu como botão. O menu e o botão de fechar devem ser implementados como elementos button, garantindo que sejam reconhecidos como controlos interativos por teclado e leitores de ecrã.
    • Gerir a abertura e fecho dos botões com o atributo aria‑expanded. A lógica de abertura e fecho do menu deve ser controlada por script, atualizando corretamente o atributo aria-expanded para que as tecnologias de apoio identifiquem o estado atual do menu.

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 #43 O menu principal não possui texto alternativo

    etiqueta: NOKetiqueta: R 1.3etiqueta: chk 10 web

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

    Evidencias

    O menu principal e o botão de fechar estão sem texto alternativo. Isso faz com que ao navegar com o leitor de ecrã não seja possível identificar a sua função:

    Image

    URL
    -https://bolsadeestudo.cm-camaradelobos.pt/ - menu principal

    Recomendações

    • Efetuarem as propostas de correção da issue xx
    • Idealmente o nome acessível do botão pode ser fornecido através de um texto dentro do próprio botão. Esse texto deve estar presente para que, além do ícone, exista uma indicação visual clara de que se trata de um botão de menu. Por exemplo:
    Menu com texto visível

    Caso optem em esconder o texto visualmente, ele deve continuar acessível para tecnologias de apoio. Para mais informações partilhamos o artigo Esconder Texto dos Utilizadores Que Usam o Sentido da Visão do site acessibilidade.gov.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #9 Cabeçalho h1 genérico em todas as páginas

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 2.1

    Evidências

    Actualmente, todas as páginas apresentam o mesmo <h1> ("Bolsas de Estudo Câmara Municipal de Câmara de Lobos"). O elemento <h1> deve ser atribuído ao título principal de cada página de forma a identificar de forma clara o respetivo conteúdo.

    Image

    Figura 1 - Exemplo do <h1> estar igual em todas as páginas .

    Recomendações

    • Garantir que existe um único elemento h1, correspondente ao título principal de cada página.
    • Em todas as páginas o título principal está a ser atribuído como h2 sendo necessário alterar para h1. Devem garantir que essa alteração não gere problemas na hierarquia entre os cabeçalhos.

  • issue #8 Existência de múltiplos h1 na página web

    etiqueta: melhoriaetiqueta: chk 10 webetiqueta: R 2.1

    Evidências

    Cada página do website deve conter um único elemento <h1>, que represente o título principal do conteúdo. A utilização de múltiplos <h1> pode comprometer a interpretação da hierarquia da página por tecnologias de apoio.

    Na página de Declaração de Acessibilidade, verifica-se a existência de dois elementos <h1>, o que constitui uma utilização incorreta da estrutura de cabeçalhos.

    Esta duplicação poderá gerar problemas caso ambos os cabeçalhos h1 fiquem visíveis para os leitores de ecrã.

    Image

    Figura 1 - Identificação de dois cabeçalhos marcados com <h1> na mesma página. .

    URLs a verificar:

    Recomendações

    • Remover o título genérico "Bolsas de Estudo Câmara Municipal de Câmara de Lobos" da página de Declaração de Acessibilidade e Usabilidade.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #49 Cabeçalho partido em 2 tags

    etiqueta: R 2.2etiqueta: NOKetiqueta: chk 10 web

    Evidências

    Na homepage o cabeçalho "Bolsas de Estudo de Câmara de Lobos" está partido em 2 tags diferentes.

    Image

    Figura 1- Cabeçalhos partidos em 2 tags diferentes .

    Recomendações

    • Na homepage, não partir o título em h2 e h3 apenas para reduzir o tamanho do texto, usar font-size para alterar o tamanho e devem manter tudo no mesmo cabeçalho.

  • issue #35 Cabeçalhos no footer

    etiqueta: R 2.2etiqueta: NOKetiqueta: chk 10 web

    Evidências

    No footer do website, a secção de "Contactos" está marcada como cabeçalho, no entanto as restantes secções estão marcadas com <div>.

    Image

    Figura 1 - Secção do footer marcada como cabeçalho.

    Recomendações

    Aplicar uma das 2 soluções:

    • Alterar a secção de contactos do footer para ficar igual às restantes (<div>)
    • Alterar as restantes secções "Candidaturas", "Resultados", "Informações" and "Lobos Digital" para cabeçalhos.

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

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #38 Não foram encontradas tabelas

    etiqueta: N/Aetiqueta: R 3.1etiqueta: chk 10 web

    Evidências

    Não foram encontradas tabelas. tornando este critério N/A.

    Recomendações

    Nada a acrescentar.

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

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #39 Não foram encontradas tabelas

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

    Evidências

    Não foram encontradas tabelas. tornando este critério N/A.

    Recomendações

    Nada a acrescentar.

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 #76 Não é possível identificar campos obrigatórios nos formulários em PDF

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 4.2

    Evidências

    Verificámos que, no formulário “Declaração sob compromisso de honra”, presente na página Bolsa de Estudo, 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ã.

    Image

    Análise do formulário “Declaração sob compromisso de honra”, presente na página Bolsa de Estudo, no browser através do leitor de ecrã NVDA.

    Recomendações

    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 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)” — para que todos os utilizadores consigam identificar facilmente os campos que têm obrigatoriamente de preencher.

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

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 4.2

    Evidências

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

    No formulário da página Consulta Candidatura não existe informação sobre o significado do asterisco nos campos.

    Image

    formulário que não apresenta o significado do *

    Recomendações

    Recomendamos a revisão dos formulários por forma a adicionarem uma legenda no início do formulário que indique claramente o significado de *. Por exemplo, “* Campos de preenchimento obrigatório”.

  • issue #36 Identificação incorreta de campos obrigatórios em tecnologias de apoio

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 4.2

    Evidências

    Foi identificado que a marcação de campos obrigatórios no formulário inclui um elemento auxiliar com utilização incorreta de ARIA:

    • <span class="required" aria-required="true">*</span>

    O atributo aria-required="true" encontra-se aplicado num elemento <span>, que não representa um controlo de formulário, não sendo suportado para este tipo de indicação semântica.

    Adicionalmente, os campos de formulário já incluem corretamente a indicação de obrigatoriedade através dos atributos:

    • required
    • aria-required="true"
    Image

    Figura 1 - Utilização incorreta do atributo aria-required num elemento não interativo (span) na indicação de campos obrigatórios

    Notas Gerais

    • A indicação de campos obrigatórios deve ser feita exclusivamente nos elementos de formulário (input, select, textarea), garantindo que:
      • leitores de ecrã conseguem identificar corretamente campos obrigatórios;
      • a semântica ARIA é utilizada de forma válida e consistente;
      • não existem atributos ARIA aplicados em elementos não interativos;
      • a informação de obrigatoriedade é transmitida de forma inequívoca.
    • A utilização de aria-required em elementos não de formulário pode gerar inconsistências na interpretação por tecnologias de apoio.

    URL a verificar

    Recomendações

    • Remover o atributo aria-required="true" do elemento <span class="required">.
    • Garantir que a indicação de obrigatoriedade é aplicada apenas nos campos de formulário (input, select, textarea).
    • Manter o uso de required e aria-required="true" nos controlos de formulário, quando aplicável.
    • Utilizar o símbolo visual (*) apenas como indicação visual, sem impacto semântico.
    • Validar a estrutura com leitores de ecrã para garantir consistência na identificação de campos obrigatórios.

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 #57 Imagem não decorativa sem texto alternativo

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 5.1

    Evidências

    Verifica-se que o ícone de alerta é apresentado através de um elemento gráfico (svg) sem texto alternativo. Neste caso, o ícone assinala uma mensagem de aviso relativa ao estado da candidatura e deve ser anunciado aos utilizadores de tecnologias de apoio.

    Image

    URL:
    https://bolsadeestudo.cm-camaradelobos.pt/menu/submissao-de-candidatura

    Recomendações

    • As imagens não decorativas deverão ter uma descrição breve associada, nomeadamente através do uso do atributo descrevendo corretamente a imagem apresentada. Por exemplo, no ícone de alerta o texto alternativo poderá ser: aria-label="Alerta".

  • issue #26 (Melhoria) Imagens decorativas com texto alternativo indevido

    etiqueta: melhoriaetiqueta: chk 10 webetiqueta: R 5.1

    Evidências

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

    Image Image Image

    Verificado que os ícones também funcionam apenas como apoio visual, uma vez que a sua finalidade já se encontra claramente identificada pelo texto visível associado. Nesses casos não devem possuir nome acessível através do atributo title. Adicionalmente, sendo o ícone em SVG meramente decorativo neste contexto, deve ser removido da árvore de acessibilidade através de aria-hidden="true".

    Image

    URL:

    https://bolsadeestudo.cm-camaradelobos.pt/menu/noticias-e-destaques/noticia/983-erasmus-vrampar-classroom-transformers
    https://bolsadeestudo.cm-camaradelobos.pt/menu/noticias-e-destaques/

    Recomendações

    • Recomenda-se que as imagens decorativas tenham alt="".
    • Quando o SVG tiver apenas finalidade visual ou decorativa, deve ser removido da árvore de acessibilidade, por exemplo com aria-hidden="true". Remover o atributo title.

  • issue #25 Imagens decorativa com texto alternativo indevido

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 5.1

    Evidências

    Verifica-se que o leitor de ecrã anuncia o banner da página inicial como imagem, apesar de este funcionar apenas como elemento visual decorativo. Neste contexto, o banner não acrescenta informação essencial distinta da que já se encontra disponível no conteúdo textual da página, pelo que não deve ser exposto autonomamente às tecnologias de apoio.

    Image

    URL:
    https://bolsadeestudo.cm-camaradelobos.pt/

    Recomendações

    • Recomenda-se que as imagens decorativas tenham alt="".

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #29 Imagem/gráfico não acessível para tecnologias de apoio

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 5.2

    Evidências

    A imagem apresenta informação detalhada sobre vários percursos, mas o texto associado não contempla todas as informações nela contidas. Os links para mais informações também não disponibilizam o detalhe necessário sobre cada percurso, pelo que o conteúdo visual não está acessível de forma equivalente.

    Image

    URL:

    https://bolsadeestudo.cm-camaradelobos.pt/menu/noticias-e-destaques/noticia/848-semana-da-saude-e-bem-estar-2024

    Recomendações

    • Recomenda-se que a informação representada na imagem seja disponibilizada no texto associado à imagem.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #24 Imagens link com texto alternativo incorreto

    etiqueta: NOKetiqueta: R 5.3etiqueta: chk 10 web

    Evidências

    Verifica-se que a imagem do logótipo utilizada como link para a página inicial, apresenta um texto alternativo que não descreve adequadamente o seu propósito (acesso à página inicial).

    Image
    • Imagem-link da galeria
      Verifica-se que, embora o texto alternativo definido no atributo alt esteja correto, a presença simultânea de um aria-label faz com que o leitor de ecrã anuncie apenas este último, ignorando o alt. Como resultado, o texto alternativo deixa de ser efetivamente utilizado.
    Image
    • Imagem ampliada da galeria
      A imagem ampliada deve apresentar o mesmo texto alternativo da imagem-link, garantindo consistência na identificação do conteúdo visual. No entanto, nesse caso, o alt não deve incluir a indicação “abrir galeria”, uma vez que a ação já foi executada e a imagem ampliada deve apenas descrever o conteúdo efetivamente apresentado.
    Image

    Verifica-se que a imagem-link não apresenta um equivalente alternativo adequado. Embora a imagem possua atributo alt, o texto alternativo utilizado (“Support_Center”) corresponde a uma designação técnica e pouco natural, não comunicando de forma clara e acessível a função ou o destino do link.

    Adicionalmente, a informação mais descritiva encontra-se no atributo title (“Support Center - Bolsas Estudo”), o que não é adequado, uma vez que o title não deve ser usado como mecanismo principal para fornecer o nome acessível de uma imagem-link. O equivalente alternativo deve estar assegurado de forma robusta no próprio mecanismo acessível principal, através do alt da imagem ou do nome acessível do link.

    Image

    Também foi verificado que o link utiliza target="_blank", abrindo o destino num novo separador, esta informação não esta a ser comunicada de forma acessível ao utilizador. Nestes casos, o aviso de abertura em novo separador pode ser incluído no nome acessível do link. Por exemplo: alt="Support Center - Bolsas Estudo (abre num novo separador)"

    Image

    URL:
    (Ajustar em todas as galerias de imagens)
    https://bolsadeestudo.cm-camaradelobos.pt/menu/noticias-e-destaques/noticia/985-iniciativa-vamos-falar-de-livros-12
    https://bolsadeestudo.cm-camaradelobos.pt/menu/noticias-e-destaques/noticia/983-erasmus-vrampar-classroom-transformers
    https://bolsadeestudo.cm-camaradelobos.pt/informacoes/bolsas-de-estudo

    Recomendações

    • O texto alternativo deve transmitir claramente o destino ou finalidade do link. Por exemplo: alt="Município de Câmara de Lobos – página inicial".
    • As imagens-link deverão ter uma descrição breve associada, nomeadamente através do uso do atributo alt descrevendo corretamente a imagem apresentada, sem identificadores técnicos ou caracteres desnecessários.
    • Quando o link direciona para um novo separador esta informação deve ser comunicada ao utilizador através do nome acessível da imagem.
    • Nas imagens da Galeria: deve ser removido o atributo aria-label da imagem-link e integrada no atributo alt a indicação da ação disponível, isto é, que a imagem permite abrir a galeria.

Requisito 6.1 - No corpo de um documento, o rácio de contraste entre a cor do texto normal (menor que 18 pontos ou menor que 14 pontos negrito) e a cor do fundo é superior a 4,5:1

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #69 Texto normal não tem contraste suficiente

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 6.1

    Evidências

    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 a ferramenta Colour Contrast Analyser revela problemas relacionados com insuficiência de contraste, afetando diretamente a legibilidade.

    O website apresenta problemas de contraste em formulários, por exemplo na página Consulta de candidatura com problemas de contraste nos textos das mensagens de erro com as combinação de cores #E73D4A(cor de primeiro plano) e #F6FAFE(cor de plano de fundo). (Figura 1)


    Image

    Figura 1 - Formulário com problemas de contraste nas mensagens de erro

    Recomendações

    Recomendamos a revisão das cores das páginas do website nas combinações de cores utilizadas em texto normal incluindo mensagens de erro, estados de foco e hover para garantir os valores mínimos de contraste.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #71 Player não funcional no browser Safari

    etiqueta: NOKetiqueta: R 7.1etiqueta: chk 10 web

    Evidências

    No browser Safari não foi possível visualizar o vídeo no link mencionado. O vídeo começa e imediatamente para, impossibilitando o utilizador de ver o vídeo.

    Image

    Figura 1 - Evidência de que não foi possível visualizar o video no Safari .

    URLs a verificar:

    https://bolsadeestudo.cm-camaradelobos.pt/informacoes/bolsas-de-estudo

    Recomendações

    • Permitir a reprodução do player no browser Safari quando ativado pelo rato, teclado e leitores de ecrã.

  • issue #27 Controlos do player sem label

    etiqueta: R 7.1etiqueta: melhoriaetiqueta: chk 10 web

    Evidências

    Foi possível ativar os botões de controlo do leitor quer com o rato quer com o teclado, no entanto, existem alguns controlos no player sem label quando se usa o tab para navegar.

    Image

    Figura 1 - Evidência que foi possivel fazer play com o teclado .

    Image

    Figura 2 - Controlos no player, navegando com tab .

    URLs a verificar:

    https://bolsadeestudo.cm-camaradelobos.pt/informacoes/bolsas-de-estudo

    Recomendações

    • Remover os controlos sem label ou adicionar uma label descritiva nos mesmos.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #28 Conteúdo visual sem audiodescrição

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 7.2

    Evidências

    Existem players multimédia sem legendas audiodescritivas.

    Para garantir acessibilidade, todos os conteúdos visuais essenciais devem ser acompanhados por audiodescrição ou por uma alternativa equivalente que permita compreender integralmente a informação transmitida no vídeo.

    Image

    Figura 1: Imagem de player com contéudo visual sem legendas audiodescritivas .

    URLs a verificar:

    https://bolsadeestudo.cm-camaradelobos.pt/informacoes/bolsas-de-estudo

    Recomendações

    • Incluir legendas audiodescritivas.

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

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

Lista de evidências recolhidas:

  • issue #10 Elementos ocultos e campos técnicos expostos sem função percetível

    etiqueta: R 8.2etiqueta: melhoriaetiqueta: chk 10 web

    Evidências

    No formulário de consulta de candidatura foram identificados elementos técnicos e controlos ocultos presentes na estrutura da página sem função percetível para o utilizador.

    Foram observados:

    • campos ocultos (input type="hidden");
    • uma área de ações (form-actions) definida com display:none;
    • um botão de submissão oculto com texto técnico interno.

    Embora alguns destes elementos possam ser utilizados internamente pela aplicação, encontram-se presentes na estrutura do formulário sem contexto funcional claro para utilizadores ou tecnologias de apoio.

    Como consequência, a estrutura do formulário pode tornar-se confusa quando interpretada sem os estilos visuais aplicados ou através de tecnologias de apoio, dificultando a compreensão da lógica e fluxo da interação.

    Image

    Figura 1 - Elementos técnicos e ações ocultas expostos na estrutura do formulário

    Notas Gerais

    • Elementos presentes na estrutura do formulário devem possuir uma função clara e coerente no contexto da interação do utilizador.
    • Componentes exclusivamente técnicos ou de suporte interno não devem introduzir ruído estrutural nem comprometer a compreensão semântica do formulário.
    • A exposição de controlos ocultos ou identificadores técnicos pode dificultar a navegação e interpretação da interface por tecnologias de apoio.

    URL a verificar

    Recomendações

    • Rever a necessidade de exposição estrutural de campos e ações exclusivamente técnicas.
    • Garantir que elementos ocultos não interferem com a compreensão semântica e lógica do formulário.
    • Evitar a apresentação de identificadores técnicos ou controlos sem função percetível para o utilizador.
    • Validar a experiência com tecnologias de apoio e com estilos desativados para confirmar que a estrutura permanece coerente e compreensível.

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 #12 Controlo “Voltar atrás” apresentado sem semântica adequada e sem função clara

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.3

    Evidências

    No formulário de consulta de candidatura foi identificado um elemento visualmente apresentado como controlo de navegação com o texto “Voltar atrás”.

    No entanto, o elemento encontra-se implementado através de um elemento genérico <div>, sem semântica nativa de botão ou link.

    Adicionalmente, no contexto observado, o controlo não aparenta possuir uma função clara ou necessária para o utilizador, uma vez que o formulário já se encontra na etapa principal de consulta, onde apenas é esperado o preenchimento dos dados e a ação “Consultar”.

    Como consequência, o utilizador pode interpretar o elemento como um controlo interativo sem compreender a sua finalidade, enquanto tecnologias de apoio podem não o anunciar corretamente como ação navegável.

    Image

    Figura 1 - Controlo “Voltar atrás” implementado com elemento não semântico e sem função clara

    Notas Gerais

    • Elementos interativos devem utilizar componentes HTML semanticamente apropriados, como <button> ou <a>.
    • A utilização de elementos genéricos como <div> para representar ações compromete a semântica da interface.
    • Controlos expostos ao utilizador devem possuir uma função clara, compreensível e consistente com o contexto da página.
    • A presença de elementos aparentando ser interativos sem necessidade funcional pode gerar confusão na navegação, sobretudo para utilizadores de tecnologias de apoio.

    URL a verificar

    Recomendações

    • Substituir o elemento <div> por um elemento semanticamente apropriado, caso o controlo tenha efetivamente uma função válida.
    • Garantir que a ação executada pelo controlo é clara e necessária no contexto do formulário.
    • Caso o elemento não possua utilidade funcional real, recomenda-se que não seja apresentado na interface.
    • Validar o comportamento com navegação por teclado e leitores de ecrã para garantir que o controlo é corretamente anunciado e compreendido.

  • issue #11 Listagem de conteúdos sem estrutura semântica adequada

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.3

    Evidências

    Na página principal, têm várias secções em que cada item é apresentado como um conjunto de conteúdos relacionados (imagem, data, título, descrição e ligação para detalhe), estruturado com múltiplos elementos <div>.

    No entanto, estes itens não estão inseridos numa estrutura semântica de lista (<ul> / <li>), apesar de representarem claramente uma listagem de conteúdos homogéneos.

    Image

    Figura 1 – Listagem de eventos estruturada com elementos <div> sem utilização de lista semântica

    Como consequência, as tecnologias de apoio não conseguem identificar programaticamente que estes elementos pertencem a um conjunto, nem o número total de itens existentes.

    Quando os estilos CSS são desativados, os conteúdos passam a ser apresentados como blocos isolados, sem indicação clara da relação entre si, dificultando a compreensão da estrutura da informação.

    Notas Gerais

    • Conjuntos de conteúdos relacionados, como listagens de documentos, notícias ou resultados, devem ser estruturados com elementos HTML semânticos apropriados (ex.: listas <ul> / <ol> e <li>), de forma a permitir que tecnologias de apoio identifiquem corretamente o agrupamento e o número de itens.
    • A utilização exclusiva de elementos genéricos (<div>) para representar estes conjuntos pode comprometer a perceção da relação entre os conteúdos apresentados.

    URL a verificar

    Recomendações

    • Deve ser verificado este padrão em todo o website.
    • Os conjuntos de conteúdos que representem listagens (ex.: documentos, notícias, resultados) devem ser estruturados semanticamente como listas (<ul> ou <ol>), com cada item representado por um <li>.
    • Cada item da lista deve agrupar toda a informação relacionada (categoria, título, descrição e ações) dentro do respetivo <li>.
    • Evitar a utilização exclusiva de elementos genéricos (<div>) para representar agrupamentos de conteúdos.
    • Validar com leitores de ecrã para garantir que o agrupamento e o número de itens são corretamente anunciados.

Requisito 9.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 #33 Quando a caixa de diálogo fecha, o foco não volta ao elemento interativo que o invocou

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 9.4

    Evidências

    Verifica-se que, ao navegar com o leitor de ecrã utilizando os controles VO + espaço (Voice Over) ou VO + Tab, ao fechar a galeria o foco não regressa ao elemento que a acionou. Isso acontece quando efetuamos a abertura da galeria de imagens e navegamos pelo conteúdo antes de fechar.

    Image

    URL:
    https://bolsadeestudo.cm-camaradelobos.pt/menu/noticias-e-destaques/noticia/985-iniciativa-vamos-falar-de-livros-12

    Recomendações

    • Recomenda-se que ao fechar a modal, o foco seja devolvido ao elemento que a acionou.

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

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

Lista de evidências recolhidas:

  • issue #44 Ficheiros PDF apresentados em um domínIo diferente do domínio do website institucional

    etiqueta: R 10.1etiqueta: melhoriaetiqueta: chk 10 web

    Evidências

    Nos PDFs avaliados foi possível extrair o conteúdo textual para formato TXT, no entanto, verifica-se que vários ficheiros PDF disponibilizados no website da Câmara Municipal de Lobos redirecionam para o domínio balcaomunicipal.cm. Recomenda-se que esses documentos sejam disponibilizados, no mesmo domínio do website institucional, de forma a garantir maior coerência na navegação e consistência na apresentação da informação.

    Image

    URLs a verificar:

    https://bolsadeestudo.cm-camaradelobos.pt/informacoes/bolsas-de-estudo - Link para o PDF

    Recomendações

    • Recomenda-se que os ficheiros atualmente alojados no domínio balcaomunicipal.cm sejam migrados ou disponibilizados diretamente no mesmo domínio do website institucional da Câmara Municipal de Lobos.

Checklist Conteúdo

etiqueta: NOK

Nível de conformidade:

  • Checklist Conteúdo: 35.3% (6/17)
    • Requisitos avaliados: 17 (17 aplicáveis)
    • Requisitos OK: 6
    • Requisitos NOK: 11

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    etiqueta: NOKetiqueta: R 1.3etiqueta: chk conteúdo

    Evidências

    Não foi possível identificar datas de atualização em certos blocos de conteúdo analisados. Considerando que as informações relativas às associações são relevantes e exigem credibilidade, é fundamental que todos os conteúdos apresentem uma data de atualização visível, de forma a reforçar a confiança, a transparência e a fiabilidade da informação disponibilizada.

    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 de bloco de conteúdo sem uma data de atualização. Disponível em: https://bolsadeestudo.cm-camaradelobos.pt/menu/resultados-anteriores

    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 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 #46 O conteúdo do site fica desformatado em resoluções mais pequenas

    etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 2.1

    Evidências

    Notas Gerais

    • Todos os conteúdos do site devem ser responsivos para garantir a sua legibilidade na maioria das resoluções e quando são escalados para tamanhos superiores.

    O website apresenta inconsistências na variação dos tamanhos de letra em resoluções mais reduzidas. Com a navegação verificou‑se que, ao alterar a resolução para um formato mobile, o texto de botões do menu principal ficam desformatado e com uma dimensão inferior à recomendada, comprometendo a legibilidade. (Figura 1 e 2)

    Image

    Figura 1 - Botões do menu principal apresentam tamanho de letra variável com apenas 14px

    Image

    Figura 2 - Verificação do texto de links na secção “Notícias Educação” com texto variável e tamanho de letra de apenas 12px

    Além disso, nas páginas interiores das notícias, o corpo de texto também sofre alterações com o tamanho de letra de apenas 14px. (Figura 3)

    Image

    Figura 3 - Corpo de texto da página com tamanho de letra variável em dispositivos móveis

    Outras páginas (NOK) e com tamanho de fonte variável em dispositivos móveis:



    Recomendações

    É necessário a revisão em todo website. Para correção das páginas adaptadas de modo a assegurar que o conteúdo se reorganiza corretamente e permanece totalmente utilizável em diferentes resoluções, tamanhos e orientações de ecrã, sem perda de informação ou funcionalidade.

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

    etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 2.1

    Evidências

    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), como o menu “Lobos Digital” (disponível em todas as páginas do website) possui opções com tamanho de letra inferior ao recomendado, por exemplo a opção “Agenda Câmara de Lobos” com apenas 14px(Figura 1)

    Image

    Figura 1 - Verificação do tamanho do texto nas opções do menu com apenas 14px

    Há botões de ação principal com tamanho de texto inferior ao recomendado. Por exemplo o botão “Limpar Filtro” na página Notícias e Destaques com tamanho de letra de apenas 15px. (Figura 2)

    Image

    Figura 2- Verificação do tamanho de texto em botão “Limpar Filtro” com apenas 15px

    O formulário de Consulta de candidatura possui * para indicar campos obrigatórios que não são visíveis com o tamanho de letra de apenas 12px, associados aos campos de preenchimento obrigatório são consideradas informação primária, mas apresentam um tamanho inferior ao recomendado. Além disso, o botão “Voltar atrás” também não cumpre o presente requisito. (Figura 3)

    Image

    Figura 3- Informações primárias do formulário com dimensão inferior ao recomendado

    No rodapé, a hiperligação para o Suporte Center (“AQUI”) é considerada informação primária, uma vez que constitui um elemento de navegação relevante para os utilizadores. Contudo, apresenta um tamanho de letra inferior ao recomendado e compromete a legibilidade.

    Image

    Figura 4- Verificação do texto do rodapé com informação primária sem o valor mínimo recomendado

    Recomendações

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

Requisito 2.3 - Blocos e linhas de texto com largura não superior a 100 caracteres

etiqueta: NOK

Lista de evidências recolhidas:

Requisito 2.4 - O espaçamento entre linhas não é inferior a 1.5x o tamanho da letra

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #50 O espaçamento entre linhas está abaixo do recomendado

    etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 2.4

    Evidências

    Notas gerais

    • Para assegurar uma boa leitura, o espaçamento entre linhas não deve ser inferior a 1.5x em relação ao tamanho do texto a ser analisado.

    Evidência 01
    Na página inicial, há diversos blocos de texto com espaçamento inferior ao recomendado. Por exemplo, no banner, a secção “Notícias Educação” com espaçamento de 20px para um tamanho de letra de 20px. (Figura 1)



    Image

    Figura 1 - Textos com espaçamento inferior ao recomendado

    Outra evidência de espaçamento incorreto:

    


    Recomendações

    Para a evidência 01 apresentada, o espaçamento deveria ser, no mínimo 30px. É necessário rever todo website para garantir o espaçamento mínimo recomendado, relativo ao tamanho da letra. Além disso, como sugestão de melhoria para manter a consistência dos blocos de texto do website, recomendamos organizar o texto com alinhamento à esquerda.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #63 As hiperligações não são consistentes ao longo do website

    etiqueta: chk conteúdoetiqueta: melhoriaetiqueta: R 3.3

    Evidências

    As hiperligações devem apresentar uma representação visual claramente distinta do texto envolvente, recorrendo a indicadores complementares como sublinhado, contraste adequado, alteração de cor consistente ou outros elementos visuais identificáveis. Essa diferenciação deve manter-se consistente ao longo de todas as páginas do website e entre diferentes browsers, garantindo previsibilidade e reconhecimento imediato por parte dos utilizadores.

    Adicionalmente, o texto meramente informativo não deve possuir características visuais semelhantes às utilizadas nas hiperligações, evitando ambiguidades na interpretação dos elementos interativos.

    Atualmente, existem conteúdos no website cuja apresentação visual é semelhante à das hiperligações, o que pode induzir os utilizadores em erro, levando-os a interpretar texto estático como clicável ou, inversamente, a considerar determinadas hiperligações como simples texto informativo. Esta inconsistência compromete a perceção da navegabilidade e a identificação correta de elementos interativos.

    Image

    Imagem de texto informativo mas que aparenta com hiperligação.

    Outros exemplos:

    Recomendações

    Garantir consistência da cor e forma entre todas as hiperligações e texto informativo ao longo do website e entre os diferentes browsers.

    Todas as hiperligações do website devem manter um estilo visual consistente, garantindo uniformidade na sua apresentação e reconhecimento ao longo de toda a navegação. O padrão atualmente utilizado nas hiperligações da página de Acessibilidade deve ser adotado de forma transversal em todas as páginas do website.

  • issue #60 Falta de identificação complementar nas hiperligações

    etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 3.3

    Evidências

    Foi identificado um problema de acessibilidade relacionado com a identificação visual de links no website. Atualmente, existem situações em que os links não estão devidamente diferenciados do texto normal, sendo identificáveis apenas através da cor ou de interação (hover), o que não cumpre as boas práticas de acessibilidade. Segue em seguida alguns exemplos encontrados:

    Image

    Figura 01: Imagem do título das notícias na página inicial como hiperligação sem identificação visual complementar.

    Image

    Figura 02: Imagem das hiperligações no rodapé sem identificação visual complementar.

    As hiperligações presentes no rodapé devem possuir uma identificação visual complementar, como sublinhado, para que os utilizadores consigam reconhecer de forma clara que os elementos são clicáveis.

    Atualmente, o link “Aqui”, presente no Support Center do rodapé (Ver figura 02), funciona como hiperligação, mas não apresenta diferenciação visual suficiente em relação ao texto informativo envolvente. Esta ausência de indicação visual dificulta a perceção da sua funcionalidade e pode comprometer a navegação, sobretudo para utilizadores com limitações cognitivas, baixa visão ou dificuldades de perceção visual.

    Outros exemplos:

    Recomendações

    • Sejam visualmente distinguíveis do texto normal sem depender exclusivamente da cor;

    • Incluam sublinhado ou outro indicador visual consistente;

    • Mantenham consistência em todos os estados (normal, hover, focus).

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

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

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 5.1

    Evidências

    Ponto 01
    Página: https://bolsadeestudo.cm-camaradelobos.pt/

    Foi identificado um elemento interativo no rodapé do conteúdo que apenas se torna visível quando o utilizador passa o rato sobre a área correspondente. Este comportamento impede o acesso à funcionalidade em dispositivos sem interação por hover, como dispositivos móveis ou navegação por teclado.

    Elemento interativo dependente de hover para visualização

    Figura 01 — Elemento interativo apenas visível através de interação por hover.

    Recomendações

    Os elementos interativos devem permanecer visíveis independentemente da interação por hover, garantindo o acesso às funcionalidades em dispositivos móveis, navegação por teclado e restantes formas de interação.

Requisito 5.2 - Os elementos interativos têm uma dimensão mínima de 44px CSS (44 pontos) (vertical e horizontal)

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #19 Elementos interativos com área clicável inferior à dimensão mínima recomendada

    etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 5.2

    Evidências

    Ponto 01
    Página: https://bolsadeestudo.cm-camaradelobos.pt/

    Os botões “Informações”, “Consultar” e “Candidatura” apresentam uma área interativa inadequada, com apenas 18.89px de altura, ficando abaixo do mínimo recomendado de 44×44px para componentes acionáveis, o que compromete a sua usabilidade e acessibilidade.

    Botões com área interativa visualmente reduzida

    Figura 01 — Botões com dimensão visual inferior à área interativa mínima recomendada.

    Ponto 02
    Página: https://bolsadeestudo.cm-camaradelobos.pt/menu/noticias-e-destaques

    Os elementos interativos da paginação apresentam uma área clicável reduzida relativamente ao tamanho mínimo recomendado para componentes acionáve

    Elementos de paginação com área interativa reduzida

    Figura 01 — Elementos de paginação com área clicável inferior à dimensão mínima recomendada.

    Recomendações

    Os elementos interativos da plataforma devem apresentar uma área clicável adequada ao tamanho mínimo recomendado de 44×44px, garantindo uma interação mais confortável e facilitando a navegação em diferentes dispositivos.

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

    etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 5.3

    Evidências

    Ponto 01
    Página: https://bolsadeestudo.cm-camaradelobos.pt/menu/consulta-candidatura

    O botão “Consultar”, apesar de ser a principal ação da página, apresenta o mesmo estilo visual dos restantes botões da plataforma, não existindo um destaque claro relativamente às ações secundárias.

    Botão principal sem destaque visual relativamente às restantes ações

    Figura 01 — Ação principal sem diferenciação visual clara relativamente às ações secundárias.

    Ponto 02
    Página: https://bolsadeestudo.cm-camaradelobos.pt/menu/noticias-e-destaques

    Verificou-se que o botão secundário “Voltar atrás” não possui destaque visual suficiente enquanto botão relativamente ao conteúdo envolvente.

    Foi ainda identificado que o botão “Limpar filtro”, presente no formulário de pesquisa por filtros, não apresenta destaque claro enquanto ação principal do formulário.

    Botões com destaque visual insuficiente relativamente ao contexto apresentado

    Figura 02 — Botões “Voltar atrás” e “Limpar filtro” com destaque visual insuficiente relativamente ao conteúdo envolvente.

    Recomendações

    A principal ação da página deve apresentar maior destaque visual relativamente às restantes ações secundárias, permitindo a sua identificação de forma mais rápida e intuitiva pelos utilizadores.

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

etiqueta: NOK

Lista de evidências recolhidas:

Checklist Transação

etiqueta: NOK

Nível de conformidade:

  • Checklist Transação: 50.0% (5/10)
    • Requisitos avaliados: 13 (3 N/A excluídos, 10 aplicáveis)
    • Requisitos OK: 5
    • Requisitos NOK: 5
    • Requisitos N/A: 3

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 #52 Não é possível aceder ao conteúdo do ficheiro PDF através de navegação por teclado (Tab e Shift+Tab)

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

    Evidências

    Testámos o ficheiro PDF “Declaração sob compromisso de honra”, presente na página Bolsa de Estudo, através do browser e do Adobe Acrobat Reader, e não é possível aceder de forma acessível ao conteúdo deste documento através de navegação por teclado (Tab e Shift+Tab).

    Image

    Figura - Análise do ficheiro PDF “Declaração sob compromisso de honra”, presente na página Bolsa de Estudo, através do leitor de ecrã NVDA no Adobe Acrobat Reader.

    Recomendações

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

  • issue #51 Há componentes do formulário que são ignorados quando se navega por teclado

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

    Evidências

    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 Consulta Candidatura, ao navegar por teclado (Tab e Shift+Tab), não é possível focar no componente “Voltar atrás” - cuja função é a de limpar o conteúdo já inserido nos campos do formulário.

    Image

    Figura - Análise do componente "Voltar atrás", no formulário da página Consulta Candidatura, através do Google Inspector.

    Recomendações

    Recomendamos que a <div> dentro da qual se encontra este elemento (<div class="voltarAtras" style="display: block;">Voltar atrás</div>) seja substituída pelo elemento HTML nativo semântico <button>.

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 #53 Formulários PDF inacessíveis para leitores de ecrã

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

    Evidências

    O formulário PDF “Declaração sob compromisso de honra”, presente na página Bolsa de Estudo, é um formulário cujo conteúdo está distribuído por 2 páginas.

    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.

    Image

    Figura - Análise do formulário PDF “Declaração sob compromisso de honra” presente na página Bolsa de Estudo.

    Recomendações

    Nos casos dos formulários PDF, uma solução mais acessível seria disponibilizar os formulários 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: NOK

Lista de evidências recolhidas:

  • issue #54 Há formulários PDF com mais de uma página que não têm a sequência de passos identificada

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

    Evidências

    Em formulários com mais de uma página, deve-se garantir que está identificada a sequência de passos, juntamente com a designação de cada passo.

    O formulário “Declaração sob compromisso de honra”, presente na página Bolsa de Estudo, é um formulário que está distribuído por 2 páginas e que não tem a sequência de passos identificada. Para além disso, não é possível navegar e aceder devidamente ao conteúdo do ficheiro através do leitor de ecrã.

    Image

    Figura - Formulário em formato PDF “Declaração sob compromisso de honra”, presente na página Bolsa de Estudo.

    Recomendações

    Para garantir melhor acessibilidade, os formulários não devem ser disponibilizados em PDF. A solução mais inclusiva é apresentar os formulários diretamente no site, permitindo o seu preenchimento online.

    Nos formulários extensos, com mais de uma página, a estrutura deve ser revista para incluir uma sequência de passos claramente identificada.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

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

    Evidências

    Verificámos que na página Consulta Candidatura, os campos “Indique o NIF/NIPC que utilizou para submeter a candidatura” e “Indique o email que utilizou para submeter a candidatura”, os campos são demasiado largos para a informação a inserir.

    O NIF (Número de Identificação Fiscal) e o NIPC (Número de Identificação de Pessoa Coletiva) são dados constituídos por 9 dígitos. Por outro lado, o tamanho esperado de um email também é relativamente curto, entre 30 a 40 caracteres, em média.

    Image

    Figura - Formulário da página Consulta Candidatura.

    Recomendações

    Recomendamos a revisão dos campos dos formulários de forma a garantir que os campos de input tenham uma largura proporcional ao tipo de informação a inserir.

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

etiqueta: N/A

Lista de evidências recolhidas:

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

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

    Evidências

    No Portal da Bolsa de Estudo de Câmara de Lobos, 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”.

    Recomendações

    No response

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

etiqueta: NOK

Lista de evidências recolhidas:

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

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

    Evidências

    Verificámos que, no formulário “Declaração sob compromisso de honra”, presente na página Bolsa de Estudo, 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ã.

    Image

    Figura - Análise do formulário “Declaração sob compromisso de honra”, presente na página Bolsa de Estudo, no browser através do leitor de ecrã NVDA.

    Recomendações

    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 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)” — para que todos os utilizadores consigam identificar facilmente os campos que têm obrigatoriamente de preencher.

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

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

    Evidências

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

    No formulário da página Consulta Candidatura não existe informação sobre o significado do asterisco nos campos.

    Image

    Recomendações

    Recomendamos a revisão dos formulários por forma a adicionarem uma legenda no início do formulário que indique claramente o significado de *. Por exemplo, “* Campos de preenchimento obrigatório”.

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

etiqueta: N/A

Lista de evidências recolhidas:

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

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

    Evidências

    Na análise realizada, não foram identificadas ações longas que exijam comunicação de estado ao utilizador.

    Desta forma, considera-se que o critério é não aplicável.

    Recomendações

    N/A

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 #4 Feedback após submissão não acessível

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

    Evidências

    Após submissão do formulário:

    • A mensagem de feedback não é anunciada por leitores de ecrã
    • Não existe uso de aria-live, role="alert" ou role="status"
    • O foco não é movido para a mensagem
    • A mensagem não é alcançável por navegação por teclado
    • O utilizador pode permanecer no formulário sem perceber que a ação foi concluída

    Este comportamento compromete a compreensão do estado da interface.

    Image

    Figura 1 – Mensagem de feedback não anunciada nem acessível por teclado

    Notas Gerais

    • Sempre que o utilizador realiza uma ação (ex.: submissão de um formulário), o sistema deve fornecer um retorno claro e imediato sobre o resultado dessa ação. Esse feedback deve ser perceptível visualmente e também programaticamente acessível, garantindo que utilizadores de tecnologias de apoio são informados da alteração de estado.

    URL a verificar

    Recomendações

    • Garantir que todas as ações apresentam feedback claro e acessível
    • Utilizar aria-live="polite" ou role="status" para mensagens dinâmicas
    • Mover o foco para a mensagem de sucesso/erro após submissão
    • Assegurar que o feedback é navegável por teclado
    • Garantir que mensagens são visíveis e persistentes
    • Validar com leitores de ecrã e navegação por teclado

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

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

    Evidências

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

    Recomendações

    N/A

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

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

    Evidências

    A mensagem de erro “Por favor, introduza um endereço eletrónico válido” presente no formulário Consulta de candidatura não ajuda no preenchimento do campo:

    Image

    Mensagem de erro que não guia o utilizador na resolução do erro
    Como observado na figura, a mensagem “Por favor, introduza um endereço eletrónico válido” 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.

    Recomendações

    Recomendamos rever todos os formulários do website para garantir que as mensagens de erro apresentadas expliquem para o utilizador como preencher os campos corretamente.

Outras violações

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

Lista de evidências recolhidas:

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

    etiqueta: outras violaçõesetiqueta: melhoria

    Evidências

    Descrição da problemática

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

    Durante a navegação sequencial através da tecla TAB, em alguns momentos o foco não é apresentado de forma perceptível, sendo apenas possível inferir a sua existência através da barra de estado do navegador, o que não constitui uma solução acessível nem adequada. Por exemplo, na página inicial em botões do header, nos cards das “Notícias Educação”(Figura 1)

    Image

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

    O problema se repete em páginas interiores e em todo website, por exemplo na página Notícias e Destaques há componentes que não são circunscritas pelo foco. (Figura 2)

    Image

    Figura 2 – Exemplo de foco visível mas não circunscreve corretamente a componente

    Sendo assim não é possível identificar visualmente a posição do utilizador em cada momento da navegação. Esta situação pode levar o utilizador a perder a noção da sua posição na página, comprometendo a usabilidade e a acessibilidade do website.

    Recomendações

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

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

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

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

    etiqueta: outras violaçõesetiqueta: melhoria

    Evidências

    Descrição da problemática

    Verificamos uma inconsistência linguística, uma vez que o site está em português mas há botões com o textos alternativos em inglês.
    

    O website possui nas notícias interiores nas galerias de imagens, que possuem botões em inglês, com alt="Previous" e  alt="Next", dificultando a compreensão para utilizadores do idioma português, língua em que o site é implementado. (Figura 1 e 2)


    Image

    Figura 1 - Setas interativas em inglês impacta na experiência com leitor de ecrã NVDA

    Image

    Figura 2 - Verificação do texto alternativo das setas interativas

    Outros exemplos:

    Recomendações

    Recomendamos traduzir todos os textos alternativos dos botões para português, idioma principal do website.

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

    etiqueta: outras violaçõesetiqueta: melhoria

    Evidências

    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 menu principal que não está inserido em um <header>, o rodapé que não está no atributo <footer>. (Figura 1)

    Image

    Figura 1 – Website estruturado apenas com atributo <section> no <body>

    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.

    Recomendações

    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.

  • issue #74 Outras violações - Links e botões que direcionam para PDFs sem aviso prévio

    etiqueta: outras violaçõesetiqueta: melhoria

    Verifica‑se que existem páginas que apresentam botões e links que direcionam diretamente para ficheiros PDF, sem informar previamente o utilizador sobre esse comportamento.

    Por exemplo, na página inicial do website Bolsas de Estudo de Câmara de Lobos, os links de “Regulamento” e os que estão sendo apresentados em "Documentos" abrem diretamente um ficheiro PDF, mas não é possível identificar esse comportamento pelo nome do link, o que compromete a previsibilidade e a identificação:

    Não é perceptível que o link Regulamento é um ficheiro PDF

    Image

    Não é perceptível que os links de alteração e declaração são ficheiros PDF

    Recomendação

    • Ajustar as nomenclaturas dos links e botões para informar claramente que o acionamento irá abrir ou descarregar um ficheiro PDF, por exemplo: “Regulamento (PDF)”.
    • Adicionalmente, recomenda-se manter o comportamento consistente em todo o site.

  • issue #70 Outras violações - Imagem duplicada na mesma página

    etiqueta: outras violaçõesetiqueta: melhoria

    Na página da notícia Câmara Municipal de Câmara de Lobos vai atribuir apoios à infância a 236 famílias do concelho está sendo apresentado duas imagens. Contudo, elas são idênticas e possuem o mesmo texto alternativo:

    URLs

    Recomendação

    • Remover a imagem duplicada para evitar redundância desnecessária.
    • Definir a imagem como decorativa quando não acrescenta informação relevante ao conteúdo. Nesse caso, o texto alternativo deve ser nulo (alt=""), evitando excesso de informação para utilizadores de leitores de ecrã.

  • issue #61 Outras violações - Link de saltar para conteúdo principal

    etiqueta: outras violaçõesetiqueta: melhoria

    Verifica-se que o website possui o link “Ir para conteúdo”, cuja finalidade é permitir aos utilizadores contornar blocos repetitivos de navegação e aceder diretamente à área principal do conteúdo.

    No entanto, este link apresenta problemas:

    • Não é apresentado de forma visível quando está em foco.
    • Quando selecionamos o link com o leitor de ecrã, está sendo direcionado para o h1 ao invés do conteúdo principal main.

    Recomendações

    • O link deve ser visualmente perceptível, apresentando-se como um elemento interativo (link ou botão). Devem garantir que o contraste esteja acima do recomendado.
    • Idealmente ele deveria estar sempre visível no ecrã, no entanto, pode ser visível apenas quando recebe foco por teclado ou leitor de ecrã.
    • Estruturalmente deve ser posicionado no início da página como o primeiro elemento interativo.
      O atributo href do link deve conter o id do respectivo main da página.

Significado das etiquetas utilizadas