Relatório Avaliação de Candidatura
Balcão Online Municipal da Câmara de Lobos

Introdução

O website https://balcaomunicipal.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 aspetos37.5% (9/24)etiqueta: Não passa
Conteúdo41.2% (7/17)etiqueta: Não passa
Transação10.0% (1/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: 37.5% (9/24)
    • Requisitos avaliados: 27 (3 N/A excluídos, 24 aplicáveis)
    • Requisitos OK: 9
    • Requisitos NOK: 15
    • 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 #71 Estrutura incorreta das listas no menu do topo

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.1

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

    Evidencias:

    A lista apresentada no menu do topo está estruturada de forma incorreta. Atualmente, existem elementos como span e div diretamente dentro da tag ul, antes dos elementos li.

    A estrutura identificada segue o padrão:
    <ul><span><div><li></li></div></span></ul>

    No entanto, de forma semântica e acessível, uma lista deve conter apenas elementos li como filhos diretos da ul, por exemplo:
    <ul><li></li><li></li></ul>

    Esta implementação pode causar problemas de interpretação para tecnologias de apoio, comprometendo a navegação e compreensão da estrutura do menu.

    Image

    Imagem da lista do menu do topo mal estruturada.

    Recomendações:

    • Garantir que os elementos ul contenham apenas elementos li como filhos diretos.
    • Remover div, span ou outros elementos estruturais colocados incorretamente dentro das listas.
    • Ajustar a estrutura HTML para seguir a semântica correta de listas e melhorar a compatibilidade com leitores de ecrã e navegação assistiva.

  • issue #44 O menu do rodapé 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 apresentadas no menu do rodapé não estão apresentadas como lista:

    Image

    Opções do menu do rodapé.

    URLs a verificar:

    Recomendações:

    • Estruturar as opções do rodapé como uma lista não ordenada. Para isso, devem utilizar a semântica HTML 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 #74 Menu mobile/tablet não acessível por teclado e leitores de ecrã

    etiqueta: NOKetiqueta: R 1.2etiqueta: chk 10 web

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

    Evidencias:

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

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

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

    Image

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

    URLs a verificar

    Recomendações:

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

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

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

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

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

  • issue #54 Menus de navegação sem indicação visual de foco na navegação por teclado

    etiqueta: NOKetiqueta: R 1.2etiqueta: chk 10 web

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

    Evidencias:

    Ao navegar pelos menus utilizando apenas o teclado (Tab e Shift + Tab), o utilizador consegue aceder às diferentes opções de navegação. No entanto, não existe qualquer indicação visual de foco que permita identificar qual o elemento atualmente selecionado.

    Este problema impacta utilizadores que dependem exclusivamente do teclado para navegar no website, uma vez que, sem o apoio de leitores de ecrã, não conseguem perceber qual opção será ativada ao pressionar Enter.

    Image

    Navegação no menu usando o teclado com o foco na opção "Bolsas de estudo" sem identificação de foco.

    Nota geral:

    Este problema ocorre de forma transversal em praticamente todo o website. Atualmente, apenas algumas hiperligações de texto apresentam alteração visual através de sublinhado quando recebem foco.

    URL's a verificar:

    Recomendações:

    • Garantir que todos os elementos interativos apresentem um indicador visual de foco visível e consistente.
    • Utilizar estilos de foco com contraste suficiente e facilmente percetíveis.
    • Assegurar que o foco visual esteja presente em menus, botões, links, formulários e restantes componentes interativos.

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

    etiqueta: NOKetiqueta: R 1.2etiqueta: chk 10 web

    É 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 nos menus de navegação. Isso faz com que ao navegar pelo website com o leitor de ecrã, não é possível realizar saltos diretamente para o menu, nem este é identificado como uma área de navegação:

    Image

    ~

    Imagem do menu secundário sem estar estrurado como navegação apropriadamente.

    Image

    Imagem do menu do rodapé sem estar estruturado como navegação apropriadamente.

    URLs a verificar:

    Recomendações:

    • O menu deve ser estruturado dentro de uma tag nav.
    • Quando existir mais do que 1 nav é necessário nomeá-las par aque seja possivel distingui-las. Isso pode ser feito pelo aria-label.

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

    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 botão mobile de abrir e fechar o menu não têm texto alternativo o que faz com que o leitor de ecrã apenas enuncie que é clicável.

    Image

    Imagem do menu para fechar sem qualquer label

    URL's a verificar:

    Recomendações:

    • Adicionar o nome acessível como aria-label="Menu" e o seu estado corretamente.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    etiqueta: NOKetiqueta: R 2.1etiqueta: chk 10 web

    Existe um título <h1> marcado na página.

    Evidências

    Actualmente, todas as páginas apresentam o mesmo <h1> ("Balcão 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 .

    URLs a verificar:

    Verificar todas as páginas do website.

    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.

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 #28 Saltos na hierarquia de cabeçalhos

    etiqueta: NOKetiqueta: R 2.2etiqueta: chk 10 web

    Existe uma marcação hierarquizada de títulos e subtítulos na página <h1>...<h6>.
    – ver requisito 2.2 na lista 10 aspetos

    Evidências

    Na maioria das páginas do website foram identificados saltos na hierarquia de cabeçalhos, verificando-se a utilização de um elemento <h3> imediatamente após um <h1> , sem existência prévia de um <h2> .

    Esta implementação compromete a correta estrutura semântica da página e dificulta a navegação por utilizadores de tecnologias de apoio.

    Image

    Figura 1 - Estrutura de cabeçalhos da Homepage.

    URLs a verificar:

    Verificar todas as páginas do website.

    Recomendações

    • Ter 1 título h1 (que marca o texto que representa o título da página ou, no caso da Homepage, o logo da entidade);
    • Ter as várias secções do documento marcadas com h2;
    • Ter as várias subsecções de h2 marcadas com h3, as subsecções destas com h4 e assim hierarquicamente encadeados até h6;
    • Evitar ter elementos de hierarquia inferior sem um elemento de hierarquia imediatamente superior (subsecções órfãs). Por exemplo, ter um h3 sem a correspondente h2, ou h4 sem a correspondente h3.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #31 Legenda da tabela sem o elemento caption

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 3.2

    Evidências

    A legenda da tabela está marcada com o elemento <caption>
    – ver requisito 3.2 na lista 10 aspetos

    Na página "Bolsas de estudo" a tabela identificada na Figura 1 não apresenta uma legenda corretamente marcada com o elemento <caption> .
    A ausência deste elemento dificulta a identificação e contextualização do conteúdo da tabela por utilizadores de tecnologias de apoio.

    Image

    Figura 1 - Tabela sem utilização do elemento <caption> para identificação da respetiva legenda .

    URLs a verificar:

    Recomendações

    • Adicionar uma legenda descritiva à tabela através do elemento <caption>.
    • Garantir que a legenda identifica adequadamente o conteúdo e finalidade da tabela.

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 #8 Existem campos de formulário sem etiquetas associadas

    etiqueta: NOKetiqueta: R 4.1etiqueta: chk 10 web

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

    Evidências

    Nas páginas com formulários de filtro, verificámos que os campos de selecionar uma opção têm uma etiqueta corretamente definida no código HTML, associada ao elemento <select> nativo.
    No entanto, este elemento <select> encontra-se oculto (aria-hidden="true") e não corresponde ao componente efetivamente utilizado pelo utilizador.
    A interação é realizada através de um componente personalizado (Select2), renderizado como um elemento <span role="combobox">, que não está associado programaticamente à respetiva etiqueta <label>.

    Image

    Figura 1 - Exemplo de campo "Filtrar por categoria” com etiqueta associada a um campo oculto

    Adicionalmente, foram identificados casos em que a associação entre a etiqueta e o campo é realizada apenas de forma implícita, através do aninhamento do elemento <select> dentro do <label>, sem recurso a associação explícita por for + id.

    Embora esta abordagem seja válida em HTML e possa funcionar corretamente em vários contextos, a utilização de associação explícita tende a proporcionar maior robustez e previsibilidade entre navegadores, tecnologias de apoio e componentes dinâmicos.

    Image

    Figura 2 - Exemplo de campo “Mostrar” sem associação explícita entre <label> e <select>

    Como consequência, a relação entre a etiqueta e o controlo interativo visível pode não ser corretamente interpretada por tecnologias de apoio, afetando a identificação do campo e a coerência da interação para alguns utilizadores.

    URLs a verificar

    Recomendações

    Recomenda-se a revisão das comboboxes presentes nos formulários de filtro, adotando uma das seguintes abordagens:

    • Utilização de elementos nativos <select>, garantindo mecanismos de acessibilidade já suportados de forma consistente pelos navegadores e tecnologias de apoio;

    ou

    • Reestruturação completa das comboboxes personalizadas, de acordo com um padrão acessível reconhecido, assegurando associação correta com a etiqueta, nome acessível, suporte adequado a teclado e tecnologias de apoio.

    Para tal, pode ser seguido o exemplo da W3C:
    Editable Combobox With Both List and Inline Autocomplete (W3C)

    Adicionalmente, recomendamos que os campos

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

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 4.2

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

    Evidências

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

    Verificámos que no formulário "Nova inscrição - Campos de Férias Municipais 2026" não existe informação sobre o significado do asterisco (*) colocado à frente dos campos.

    Image

    Figura 1 - Formulário da página "Nova inscrição - Campos de Férias Municipais 2026". Não existe informação sobre o significado do asterisco (*) colocado à frente dos campos.

    URLs a verificar

    Recomendações

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

  • issue #5 Utilização redundante de atributos de obrigatoriedade

    etiqueta: melhoriaetiqueta: chk 10 webetiqueta: R 4.2

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

    Evidências
    Verificou-se que alguns campos obrigatórios do website utilizam simultaneamente os atributos required e aria-required="true".

    Nos controlos HTML nativos de formulário (<input>, <textarea>, <select>), o atributo required já transmite de forma programática a obrigatoriedade do campo às tecnologias de apoio, sendo também responsável pela validação nativa do browser.

    Assim, a utilização simultânea de required e aria-required="true" torna-se redundante, não trazendo benefícios adicionais para acessibilidade e aumentando a complexidade de manutenção do código.

    Image

    Figura 2 - Etiqueta com o atributo required e aria-required

    URLs a verificar

    Recomendações

    • Manter apenas o atributo required nos controlos HTML nativos de formulário (<input>, <textarea>, <select>), evitando redundância desnecessária;
    • Utilizar aria-required="true" apenas em controlos personalizados que não disponham de suporte nativo de obrigatoriedade;
    • Verificar a consistência desta implementação nos vários formulários do website.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #2 Existem mensagens de erro apresentadas entre a etiqueta e o campo

    etiqueta: NOKetiqueta: R 4.3etiqueta: chk 10 web

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

    Evidências

    Foi identificado um campo de formulário cuja mensagem de erro é apresentada antes do componente visual interativo, quebrando a consistência da estrutura observada nos restantes controlos do website.

    Como consequência, a mensagem de erro surge visualmente entre a etiqueta e o campo percecionado pelo utilizador, em vez de ser apresentada após o controlo do formulário, criando inconsistência visual e podendo dificultar a compreensão da associação entre erro e campo.

    Image

    Figura 1 - Mensagem de erro apresentada a seguir à etiqueta

    URLs a verificar

    Recomendações

    • Garantir que as mensagens de erro são apresentadas após o último elemento visual do campo, mantendo a coerência com os restantes controlos do website.
    • Validar visualmente e por navegação por teclado que a ordem de leitura e apresentação do campo permanece consistente e previsível.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #7 Não foram identificados gráficos no website.

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

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

    Evidências

    Não foram encontrados gráficos ou imagens complexas no website. Assim, este critério é considerado "Não aplicável (N/A)".

    Recomendações

    N/A

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #51 Não foram encontrados players no website.

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

    Deve ser possível ativar os botões de controlo do leitor quer com o rato quer com o teclado.
    – ver requisito 7.1 na lista 10 aspetos

    Evidências

    Não foram encontrados players no website, tornando este critério N/A.

    Recomendações

    • Nada a acrescentar.

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

Lista de evidências recolhidas:

  • issue #52 Não foram encontrados players no website.

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

    Deve ser possível ativar os botões de controlo do leitor quer com o rato quer com o teclado.
    – ver requisito 7.2 na lista 10 aspetos

    Evidências

    Não foram encontrados players no website, tornando este critério N/A.

    Recomendações

    • Nada a acrescentar.

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 #34 Ausência de landmarks semânticos

    etiqueta: NOKetiqueta: R 8.3etiqueta: chk 10 web

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

    Evidências

    Observa-se a ausência de landmarks semânticos que permitam identificar programaticamente as principais regiões da página (ex.: cabeçalho, navegação, conteúdo principal e rodapé). A estrutura da interface aparenta estar predominantemente assente em elementos genéricos (<div>), sem utilização consistente de elementos HTML semânticos ou roles equivalentes.

    A inexistência destas regiões semânticas dificulta a navegação por tecnologias de apoio, nomeadamente leitores de ecrã, impedindo os utilizadores de saltar rapidamente entre áreas relevantes da página.

    Image

    Figura 1 - Ausência de landmarks semânticos identificáveis na estrutura da página

    URLs a verificar

    Recomendações

    • Implementar landmarks semânticos para as principais regiões da página, recorrendo preferencialmente a elementos HTML nativos como <header>, <nav>, <main> e <footer>
    • Garantir a existência de uma única região principal (<main>) por página
    • Quando não for possível utilizar elementos HTML semânticos, aplicar roles ARIA equivalentes, como role="banner", role="navigation", role="main" e role="contentinfo"
    • Validar a estrutura semântica com tecnologias de apoio para confirmar que as regiões são corretamente identificadas e anunciadas ao utilizador.

    Referência: MDN – ARIA landmark roles

Requisito 9.1 - Quando a caixa de diálogo é aberta, o foco (cursor do Browser) move-se para um elemento dentro da caixa de diálogo

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #10 Quando a caixa de diálogo é aberta, não move-se para o primeiro elemento interativo dentro da caixa de diálogo

    etiqueta: NOKetiqueta: R 9.1etiqueta: chk 10 web

    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

    Quando a caixa de diálogo é ativada, o foco do navegador é colocado diretamente no campo “N.º de vagas pretendidas”, em vez de ser posicionado no início da caixa de diálogo, no botão “Fechar” ou no primeiro elemento interativo/editável disponível.

    Image

    URLs a verificar

    https://balcaomunicipal.cm-camaradelobos.pt/inscricoes-user

    Recomendações

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

Requisito 9.2 - Quando uma caixa de diálogo está aberta, a navegação com teclado (Browser ou Tecnologia de apoio) tem de ficar circunscrita aos elementos que compõem a caixa de diálogo

etiqueta: NOK

Lista de evidências recolhidas:

Checklist Conteúdo

etiqueta: NOK

Nível de conformidade:

  • Checklist Conteúdo: 41.2% (7/17)
    • Requisitos avaliados: 17 (17 aplicáveis)
    • Requisitos OK: 7
    • Requisitos NOK: 10

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #40 Falta de resumo na página inicial do website

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

    O sítio Web apresenta um resumo breve do seu propósito, visível sem fazer scroll.
    – ver requisito 1.1 na lista Conteúdo

    Evidências:

    A página inicial do website do Balcão Online de Câmara de Lobos apresenta uma frase visível, sem necessidade de scroll. No entanto, a informação não transmite o propósito do website.

    O propósito do website difere da missão ou do objetivo da entidade. O propósito deve transmitir, de forma clara, o que o utilizador pode efetivamente encontrar e realizar no website. Esse propósito deve ser imediatamente visível na página, sem ser necessário fazer scroll, avançar no slideshow, entre outros.

    Image

    Imagem da página inicial do Balcão Online de Câmara de Lobos sem fazer scroll

    URL's a verificar:

    Recomendações:

    O resumo apresentado na página inicial deve ser revisto de forma a descrever claramente o propósito do website, incluindo os principais tipos de conteúdos e serviços disponibilizados. Esta descrição deve ser concisa, informativa e orientada para ajudar o utilizador a compreender rapidamente a utilidade e abrangência do site.

    Como exemplo, pode ser consultado o website selo.usabilidade.gov.pt, que apresenta um resumo simples e claro logo na página inicial, permitindo compreender rapidamente o seu propósito.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

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

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

    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 possui informações primárias com tamanho inferior a 12pontos(16px).

    Há botões de ação principal, com tamanho inferior ao recomendado. Por exemplo os botões “AMA”, “Início”, “Pesquisar”, “Pedidos Submetidos” e “Sair” na página inicial. (Figura 01)

    Botões de ação principal com tamanho de letra inferior ao recomendado

    Figura 01 — Botões de ação principal com tamanho de letra inferior ao mínimo recomendado.

    Adicionalmente, verificámos que os elementos da navegação da interface, como os separadores “Pesquisa livre” e “Pedidos Submetidos”, utilizam tamanhos de letra 14px inferior ao mínimo recomendado. (Figura 02)

    Elementos de navegação com tamanho de letra inferior ao recomendado

    Figura 02 — Elementos de navegação "Pesquisa livre" com tamanho de letra inferior ao mínimo recomendado.

    Verificámos que, na página Acessibilidade, o corpo principal do conteúdo apresenta texto com tamanho de 14px. Foi identificado que vários parágrafos da declaração de acessibilidade utilizam um tamanho de letra inferior ao mínimo recomendado pelo presente critério. (Figura 03)

    Image

    Figura 03 — Corpo principal do conteúdo apresenta tamanho de letra inferior ao mínimo recomendado.

    Verificámos que, na página Pedidos Submetidos, algumas informações secundárias associadas à tabela de registos apresentam tamanho de letra inferior ao mínimo recomendado.

    Foi identificado que elementos como "Lista 1 a 4 de 4" registos, "datas", "referências", "categorias" e informação auxiliar da listagem possuem um tamanho de letra de 12px, não cumprem o presente critério.(Figura 04)

    Informações secundárias da tabela com tamanho de letra inferior ao recomendado

    Figura 04 — Campos de data e restantes informações secundárias da tabela com tamanho de letra inferior ao mínimo recomendado.

    Verificámos que, nas notificações disponíveis no ícone “Inscrições” do website Balcão Online, algumas informações secundárias apresentam tamanho de letra inferior ao mínimo recomendado.

    Foi identificado que o texto das notificações apresenta tamanho de letra de 11px. (Figura 05)

    Texto e data das notificações com tamanho de letra inferior ao recomendado

    Figura 05 — Texto das notificações com tamanho de letra inferior ao mínimo recomendado.

    Adicionalmente identificamos que a data com hora associada às notificações utiliza tamanho de letra de 9px, comprometendo a legibilidade da informação apresentada. (Figura 06)

    Image

    Figura 06 — Data da notificação com tamanho de letra inferior ao mínimo recomendado.

    URLs a verificar:

    Recomendações:
    É necessário rever todo website, e corrigir os textos de informações primárias, para um tamanho igual ou superior ao recomendado.

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

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

    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:

    Verificamos que, na página inicial Balcão Online Municipal Câmara de Lobos, alguns elementos textuais apresentam tamanho reduzido quando visualizados em resoluções mais pequenas.

    Foi identificado que, em contexto mobile e tablet, o conteúdo da interface fica visualmente reduzido, dificultando a leitura e perceção da informação apresentada. (Figura 01)

    Elementos textuais com tamanho reduzido em resoluções mais pequenas

    Figura 01 — Elementos textuais com tamanho reduzido em contexto mobile e tablet.

    Identificamos que na página Nova Inscrição - Campos de Férias Municipais 2026, o conteúdo apresentado na interface se torna difícil de ler em resoluções mais pequenas devido à redução do tamanho dos elementos textuais. (Figura 02)

    Conteúdo da interface com tamanho reduzido em resoluções mais pequenas

    Figura 02 — Conteúdo da interface com tamanho reduzido, dificultando a leitura em resoluções mais pequenas.

    URLs a verificar:

    Recomendações:
    As páginas deverão ser revistas para garantir que todo o conteúdo se adapta a diferentes resoluções de ecrã.

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:

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #62 Existem blocos de textos com mais de 100 caracteres por linha

    etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 2.3

    Blocos e linhas de texto com largura não superior a 100 caracteres.
    – ver requisito 2.3 na lista Conteúdo

    Evidências:

    Verificámos que, na página inicial Balcão Online Municipal Câmara de Lobos, existem blocos de texto com largura superior ao limite recomendado de 100 caracteres por linha.

    Foi identificado que os textos apresentados nas secções “Informação” e “Support Center” possuem linhas excessivamente longas, dificultando o conforto e acompanhamento da leitura.

    Como exemplo, o texto “Bem-vindo ao Balcão Online de Câmara de Lobos. O Balcão Online encontra-se em constante evolução e brevemente serão acrescidos novos requerimentos e serviços que poderão ser” apresenta 173 caracteres na mesma linha.

    O mesmo comportamento verifica-se no texto “O Support Center de Câmara de Lobos é o seu assistente para as questões de índole tecnológica, de navegabilidade e acessibilidades da plataforma, que visa apoiar os cidadãos”, também com 173 caracteres por linha. (Figura 01)

    Blocos de texto com largura superior ao limite recomendado por linha

    Figura 01 — Blocos de texto com largura superior ao limite recomendado por linha, identificado através da ferramenta [WordCounter](https://wordcounter.net/?utm_source=chatgpt.com).

    Foi identificado na página Apoio à Infância blocos de texto com largura superior ao limite recomendado por linha, como por exemplo, "A candidatura à Atribuição de Apoios à Infância — Mensalidades de Creche, Jardim de Infância e Ensino Pré-Escolar, visa promover a integração positiva das crianças nas instituições" com 180 caracteres. (Figura02)

    Texto da secção de apoio à infância com largura superior ao limite recomendado por linha

    Figura 02 — Texto descritivo da secção “Apoio à Infância” com largura superior ao limite recomendado por linha, identificado através da ferramenta [WordCounter](https://wordcounter.net/?utm_source=chatgpt.com).

    Adicionalmente identificamos o bloco texto "de apoio à infância e de ensino pré-escolar e contribuir para o alívio dos custos económicos suportados pelas famílias, associados à educação das suas crianças, na fase pré-escolar." com 181 caracteres. (Figura 03)

    Texto complementar da secção de apoio à infância com largura superior ao limite recomendado por linha

    Figura 03 — Texto complementar da secção “Apoio à Infância” com largura superior ao limite recomendado por linha, identificado através da ferramenta [WordCounter](https://wordcounter.net/?utm_source=chatgpt.com).

    URLs a verificar:

    Recomendações:
    Recomenda-se a limitação da largura dos blocos de texto, garantindo que as linhas não ultrapassem aproximadamente 100 caracteres, de forma a melhorar o conforto e acompanhamento da leitura.

    Sugere-se ainda a definição de uma largura máxima para os blocos de texto através de CSS max-width, utilizando unidades relativas ao tamanho da fonte, como em ou rem.

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 #63 O espaçamento entre linhas está abaixo do recomendado

    etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 2.4

    O espaçamento entre linhas não é inferior a 1.5x o tamanho da letra.
    – ver requisito 2.4 na lista Conteúdo

    Evidências:

    Verificámos que, na página inicial Balcão Online Municipal Câmara de Lobos, alguns blocos de texto apresentam espaçamento entre linhas inferior ao recomendado para uma leitura confortável.

    Foi identificado que o texto das secção “Informação” utiliza um line-heightde 20px para um tamanho de letra de 14px, valor inferior à proporção recomendada de 1.5x o tamanho da fonte. (Figura 01)

    Blocos de texto com espaçamento entre linhas inferior ao recomendado

    Figura 01 — Bloco de texto da secção “Informação” com espaçamento entre linhas inferior ao mínimo recomendado.

    Adicionalmente o texto da secção “Support Center” também utiliza um line-height aproximado de 20px para um tamanho de letra de 14px. (Figura 02)

    Texto da secção Support Center com espaçamento entre linhas inferior ao recomendado

    Figura 02 — Texto da secção “Support Center” com espaçamento entre linhas inferior ao mínimo recomendado.

    Verificámos que, na página Apoio à Infância, há blocos de texto com espaçamento entre linhas inferior ao recomendado para uma leitura confortável.

    Foi identificado um espaçamento entre linhas de 20px para um tamanho de letra de 14px, abaixo da proporção mínima recomendada de 1.5x relativamente ao tamanho da fonte. (Figura 03)

    Bloco de texto com espaçamento entre linhas inferior ao recomendado

    Figura 03 — Bloco de texto com espaçamento entre linhas inferior ao mínimo recomendado para leitura confortável.

    Identificamos na página Campos de férias, algumas informações secundárias apresentam tamanho de letra inferior ao recomendado.

    Foi identificado que os textos associados aos locais disponíveis para inscrição, como “Lobos Radical - Câmara de Lobos”, utilizam um espaçamento entre linhas de 12px para um tamanho de letra de 12px,, comprometendo a legibilidade da informação apresentada. (Figura 04)

    Informações secundárias da inscrição com tamanho de letra inferior ao recomendado

    Figura 04 — Informações secundárias da inscrição com tamanho de letra inferior ao mínimo recomendado.

    URLs a verificar:

    Recomendações:
    Recomenda-se assegurar que os blocos de texto utilizam um espaçamento entre linhas mínimo de 1.5x relativamente ao tamanho da letra, promovendo uma leitura mais confortável e uma melhor perceção dos conteúdos apresentados.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

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

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

    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:

    Verificamos que, na página inicial Balcão Online Municipal Câmara de Lobos, os elementos “Inscrições”, “Apoio à infância”, “Bolsas de estudo” e “Pesquisar” apresentam uma área interativa inferior à dimensão mínima recomendada para elementos acionáveis.

    Foi identificado um tamanho de 33.4x35px no botão representado pelo ícone de lupa, comprometendo a facilidade de utilização, especialmente em dispositivos táteis. (Figura 01)

    Adicionalmente, foi identificado que o botão “CloseBox” apresenta uma dimensão de 18x19px. (Figura 02)

    Elementos interativos com dimensão inferior ao recomendado

    Figura 01 — Elementos “Inscrições”, “Apoio à infância”, “Bolsas de estudo” e botão “Pesquisar” com área interativa inferior ao mínimo recomendado.

    Botão CloseBox com dimensão inferior ao recomendado

    Figura 02 — Botão “Fechar” com dimensão inferior ao mínimo recomendado para elementos interativos.

    Verificamos que, no menu lateral da página inicial Balcão Online Municipal Câmara de Lobos, existem elementos interativos com área clicável inferior à dimensão mínima recomendada de 44px.

    Foi identificado um tamanho de 38.56px de altura em alguns elementos como por exemplo: "Início", "Pesquisar", "Pedidos Submetidos", "Sair", "Bolsas de Estudo"," Campos de férias", "Apoio à Infância" e "Support Center." (Figura 03)

    Elementos do menu lateral com área clicável inferior ao recomendado

    Figura 03 — Elementos do menu lateral com área clicável inferior à dimensão mínima recomendada.

    Verificamos que, na página Pedidos Submetidos, algumas áreas clicáveis associadas aos campos de pesquisa apresentam altura inferior ao mínimo recomendado de 44px.

    Foi identificada uma altura de 38.85px nos campos “Data”, “Módulo”, “Nome/Assunto”, “Categoria”, “Estado” e "Referência". (Figura 04).

    Campos de pesquisa com área clicável inferior ao recomendado

    Figura 04 — Campos “Data”, “Módulo”, “Nome/Assunto”, “Categoria”, “Estado” e “Referência” com área clicável inferior à dimensão mínima recomendada.

    Adicionalmente foi identificado uma altura de 40px nos campos:

    • Mostrar
    • Pesquisa
    • Filtrar por categoria
    • Filtrar por estado

    Verificamos que, na página Nova Inscrição - Campos de Férias Municipais 2026, alguns elementos interativos apresentam dimensões inferiores ao mínimo recomendado de 44x44px.

    Foi identificado que os controlos utilizados para expandir e recolher secções do formulário apresentam uma dimensão de 20px. (Figura 05)

    Controlos de expansão com dimensão inferior ao recomendado

    Figura 05 — Controlos utilizados para expandir e recolher secções do formulário com dimensão inferior ao mínimo recomendado.

    Adicionalmente, os radio buttons apresentam uma área clicável de 17.6px de altura. (Figura 06)

    Radio buttons com área clicável inferior ao recomendado

    Figura 06 — Radio buttons com área clicável inferior à dimensão mínima recomendada.

    Foi ainda identificado que o botão de atalho para o topo da página apresenta uma dimensão aproximada de 32x26.16px. (Figura 07)

    Botão de atalho para o topo com dimensão inferior ao recomendado

    Figura 07 — Botão de atalho para o topo da página com dimensão inferior à mínima recomendada.

    O botão “Cancelar” apresenta 30.88px de altura, valor inferior ao mínimo recomendado para elementos interativos. (Figura 08)

    Botões “Cancelar” e “Submeter” com dimensão inferior ao recomendado

    Figura 08 — Botões “Cancelar” e “Submeter” no final da página com dimensão inferior à mínima recomendada.

    O botão “Submeter”, localizado no topo da página, apresenta aproximadamente 27.60px de altura. (Figura 09)

    Botões “Voltar” e “Submeter” com dimensão inferior ao recomendado

    Figura 09 — Botões “Voltar” e “Submeter” no topo da página com dimensão inferior à mínima recomendada.

    Verificamos que na página Inscrições, na secção “Minhas Inscrições”, os botões de navegação da paginação da tabela apresentam áreas clicáveis reduzidas, nomeadamente os controlos de navegação entre páginas, com dimensões de 15x17.13px. (Figura 10 )

    Botões de paginação com área clicável reduzida

    Figura 10 — Botões de navegação da paginação com área clicável inferior à dimensão mínima recomendada.

    URLs a verificar:

    Recomendações:
    Recomenda-se o aumento da área acionável dos elementos interativos, garantindo uma dimensão mínima de 44x44px CSS, de forma a melhorar a interação em dispositivos táteis.

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:

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #35 Utilização inconsistente de ícones em elementos interativos

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

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

    Evidências:

    Verificou-se que, na página inicial Balcão Online Municipal Câmara de Lobos, o ícone associado ao elemento “Pedidos Submetidos” apresenta um comportamento visual inconsistente com a ação executada.

    Foi identificado que o ícone utilizado sugere a expansão de conteúdo ou abertura de submenu, apesar de o elemento encaminhar o utilizador para uma nova página. (Figura 01)

    Ícone com comportamento visual inconsistente com a ação executada

    Figura 01 — Ícone do elemento “Pedidos Submetidos” com indicação visual inconsistente com a ação executada.

    Verificámos que, no website Balcão Online Municipal Câmara de Lobos, o elemento “Pedidos Submetidos” apresenta inconsistências visuais na utilização dos ícones associados.

    Foi identificado que o ícone apresentado varia consoante o contexto da interface, sendo utilizado um ícone distinto no menu lateral e outro nos separadores da página.

    Inconsistência visual na utilização do ícone do elemento Pedidos Submetidos

    Figura 02 — Inconsistência visual na utilização do ícone associado ao elemento “Pedidos Submetidos”.

    URL a verificar:

    Recomendações:
    Recomenda-se a utilização de ícones visualmente consistentes e alinhados com a funcionalidade executada pelos elementos interativos da interface.

    Os ícones associados a ações de navegação devem representar de forma clara o comportamento esperado do elemento, evitando interpretações ambíguas ou semelhantes a menus, expansão de conteúdo ou outras funcionalidades distintas. Adicionalmente, o mesmo elemento deverá manter uma representação visual consistente ao longo das diferentes páginas e contextos da interface.

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

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

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

    Evidências:

    Verificámos que, na página Pesquisar, o campo de pesquisa não aparenta de forma clara ser um elemento de edição interativo.

    Foi identificado que o campo apresentado com o texto “Ex: Requerimento para apoio social” utiliza um estilo visual semelhante a caixas informativas ou elementos desativados da interface, dificultando a perceção de que o elemento pode ser selecionado e preenchido pelo utilizador. (Figura 01)

    Elemento “Pesquisa livre” com aparência semelhante a um botão de ação

    Figura 01 — Elemento “Pesquisa livre” com aparência visual semelhante a um botão de ação.

    URLs a verificar:

    Recomendações:
    Recomenda-se a utilização de indicadores visuais mais claros nos campos de preenchimento, garantindo que os elementos interativos sejam facilmente identificados como editáveis pelos utilizadores.

    Os campos de formulário devem apresentar uma aparência visual distinta de elementos informativos ou desativados da interface, através da utilização adequada de contraste, bordas, estilos de foco ou outros indicadores visuais consistentes.

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

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

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

    Evidências:

    Verificámos que, na área de autenticação do website Balcão Online Municipal Câmara de Lobos, o ícone “X” utilizado para fechar a mensagem de erro apresenta contraste insuficiente face à cor de fundo.

    Foi identificado que o elemento apresenta um contraste de 1.32:1, valor inferior ao mínimo recomendado pelas WCAG para componentes visuais da interface.

    Adicionalmente, deverá também ser revista a área clicável do elemento Ver Requisito 5.2. (Figura 01)

    Ícone de fecho da mensagem de erro com contraste insuficiente

    Figura 01 — Ícone “X” da mensagem de erro com contraste insuficiente face à cor de fundo.

    Na página inicial Balcão Online Municipal Câmara de Lobos, o elemento interativo presente no rodapé do website apresenta contraste insuficiente.

    Foi identificado um rácio de contraste de 1.18:1 entre o elemento e a cor de fundo, abaixo do valor mínimo recomendado para conteúdos interativos. (Figura 02)

    Elemento interativo do rodapé com contraste insuficiente

    Figura 02 — Elemento interativo presente no rodapé com contraste insuficiente relativamente ao fundo.

    Verificamos que, na página Pedidos Submetidos, alguns elementos interativos apresentam contraste insuficiente face à cor de fundo.

    Foi identificado um rácio de contraste de 1.35:1 nas setas associadas aos campos “Módulo”, “Nome/Assunto”, “Categoria”, “Estado” e “Referência”, abaixo do valor mínimo recomendado para componentes gráficos da interface. (Figura 03)

    Setas dos campos de seleção com contraste insuficiente

    Figura 03 — Setas associadas aos campos “Módulo”, “Nome/Assunto”, “Categoria”, “Estado” e “Referência” com contraste insuficiente.

    Adicionalmente, foi identificado um rácio de contraste de 2.84:1 nos campos “Filtrar por categoria” e “Filtrar por estado”. (Figura 04)

    Campos de filtro com contraste insuficiente

    Figura 04 — Campos “Filtrar por categoria” e “Filtrar por estado” com contraste insuficiente relativamente ao fundo.

    Na página Dados de Inscrição o elemento "Ficha de inscrição" possue contrast rátio de 3.68:01, não cumpre o critério do requisito.

    Image

    Figura 01 — Elemento “Ficha de Inscrição” com contraste inferior ao mínimo recomendado para elementos interativos da interface.

    URL a verificar:

    Recomendações:
    Recomenda-se a utilização de rácios de contraste adequados nos elementos interativos e respetivos estados de interação, garantindo uma perceção visual clara e consistente dos conteúdos clicáveis.

Checklist Transação

etiqueta: NOK

Nível de conformidade:

  • Checklist Transação: 10.0% (1/10)
    • Requisitos avaliados: 13 (3 N/A excluídos, 10 aplicáveis)
    • Requisitos OK: 1
    • Requisitos NOK: 9
    • 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:

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #43 Os formulários com mais de uma página tem sequência de campos ilustrada

    etiqueta: R 1.3etiqueta: N/Aetiqueta: 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

    Evidências

    Não foram encontrados formulários com mais de uma página dentro do website Balcão Online Municipal . Assim, este requisito fica avaliado como "Não Aplicável".

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: N/A

Lista de evidências recolhidas:

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

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

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

    Evidências

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

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

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

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

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

    Evidências:

    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.

    Verificamos que, na página Nova Inscrição - Campos de Férias Municipais 2026, não existe informação que explique o significado do asterisco (*) utilizado nos campos obrigatórios do formulário.

    Campos obrigatórios sem indicação do significado do asterisco

    Figura 01 — Campos obrigatórios identificados com asterisco sem explicação do seu significado.

    Na página Meus Dados, existem campos obrigatórios identificados apenas através do símbolo “*”, sem qualquer indicação complementar sobre o seu significado. (Figura 02)

    Checkboxes dos termos e condições sem indicação programática de obrigatoriedade

    Figura 02 — Elementos de confirmação dos termos e condições sem indicação programática de obrigatoriedade.

    Na página Dados do Pedido de Suporte, identificamos que os campos obrigatórios “Assunto” e “Descrição” não apresentam qualquer indicação visível que explique o significado do símbolo “*” utilizado no formulário. (Figura 03)

    Campos obrigatórios sem explicação do significado do asterisco

    Figura 03 — Campos obrigatórios “Assunto” e “Descrição” sem explicação do significado do asterisco.

    URLs a verificar:

    Recomendações:
    Recomenda-se a revisão dos formulários, garantindo a apresentação de uma indicação clara sobre o significado do símbolo (*) utilizado nos campos obrigatórios, preferencialmente no início do formulário.

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

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

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

    Evidências:

    Verificamos que o formulário PDF INSCRIÇÃO NO PERÍODO DE INTERVENÇÃO DO PÚBLICO , 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.

    Campos obrigatórios sem identificação clara em formulário PDF

    Figura 01 —Formulário “Modelo de inscrição de intervenção do público” sem identificação clara dos campos de preenchimento obrigatório, quer visualmente quer através de tecnologias de apoio.

    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.

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

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

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

    Evidências:

    Verificamos que, na página Nova Inscrição - Campos de Férias Municipais 2026, alguns campos obrigatórios do formulário não se encontram identificados programaticamente.

    Foi identificado que elementos como radio buttons e botões utilizados para anexação de documentos, apesar de associados a campos obrigatórios assinalados visualmente com o símbolo “*”, não utilizam atributos como required ou aria-required="true", dificultando a correta interpretação da obrigatoriedade dos campos por tecnologias de apoio. (Figura 01 e Figura 02)

    Radio buttons sem indicação programática de obrigatoriedade

    Figura 01 — Radio buttons associados a campos obrigatórios sem indicação programática de obrigatoriedade.

    Botões de anexação de documentos sem indicação programática de obrigatoriedade

    Figura 02 — Botões de anexação de documentos associados a campos obrigatórios sem indicação programática de obrigatoriedade.

    Identificámos que, na página Meus dados, os campos obrigatórios assinalados com o símbolo “*” não apresentam qualquer informação que explique o significado dessa indicação.
    (Figura 02)

    Campos obrigatórios sem explicação do significado do asterisco

    Figura 03 — Campos obrigatórios identificados com asterisco sem explicação do seu significado.

    Na página Meus Dados identificamos que os elementos utilizados para confirmação dos termos apresentados na secção “Termos e Condições” e "Declaro que li e aceito a Política de Privacidade e Termos e Condições de Utilização", apesar de assinalados visualmente como obrigatórios através do símbolo “*”, não utilizam atributos como required ou aria-required="true", dificultando a correta interpretação da obrigatoriedade dos campos por tecnologias de apoio. (Figura 04)

    Checkboxes dos termos e condições sem indicação programática de obrigatoriedade

    Figura 04 — Elementos de confirmação dos termos e condições sem indicação programática de obrigatoriedade.

    Na página Dados do Pedido de Suporte, foi identificado que campo obrigatório “Descrição”, apesar de assinalados visualmente com o símbolo “*”, não utilizam atributos como required ou aria-required="true", dificultando a correta interpretação da obrigatoriedade dos campos por tecnologias de apoio. (Figura 05)

    Campo “Descrição” sem indicação programática de obrigatoriedade

    Figura 05 — Campo obrigatório “Descrição” sem indicação programática de obrigatoriedade.

    Na página Inscrições, o formulário apresentado na janela “Pré Inscrição” contém campos obrigatórios sem identificação clara da sua obrigatoriedade.

    Foi identificado que elementos como “Período pretendido” e “Nº de vagas pretendidas” não apresentam indicação visível suficientemente clara sobre o preenchimento obrigatório dos campos, podendo gerar dúvidas durante a utilização do formulário. (Figura 06)

    Campos obrigatórios sem identificação clara de obrigatoriedade

    Figura 06 — Campos “Período pretendido” e “Nº de vagas pretendidas” sem identificação clara de obrigatoriedade.

    URL a verificar:

    Recomendações:
    Recomendamos que todos os campos obrigatórios dos formulários sejam identificados programaticamente através dos atributos adequados, como required ou aria-required="true", garantindo que essa informação é corretamente transmitida às tecnologias de apoio e validada de forma consistente pelos navegadores.

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

    etiqueta: N/Aetiqueta: 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

    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. (N/A)

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #64 Mensagens de erro de autenticação e validação não totalmente acessíveis nem corretamente anunciadas

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

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

    Evidências

    Foram identificadas situações em que mensagens de erro apresentadas durante processos de autenticação e validação de formulários não são totalmente acessíveis para utilizadores de tecnologias de apoio.

    Em particular:

    • as mensagens de erro não são anunciadas de forma consistente por leitores de ecrã;
    • não existe utilização de mecanismos como aria-live, role="alert" ou role="status" para comunicação automática de erros dinâmicos;
    • em alguns casos, o foco não é direcionado para a mensagem de erro após a sua apresentação;
    • a mensagem de erro pode não ser facilmente percetível através de navegação por teclado;
    • foram observadas situações em que a mensagem de erro é apresentada de forma truncada, não sendo exibido o conteúdo completo ao utilizador.

    Exemplo identificado no login e no Support Center:

    A mensagem apresentada ao utilizador surge parcialmente como:

    “da não possui uma conta”

    quando a mensagem completa corresponde a um texto de erro mais extenso relacionado com credenciais inválidas ou inexistência de conta.

    Adicionalmente, após tentativa de submissão inválida, o foco é colocado diretamente no campo com erro (ex.: password), sem garantia de que a mensagem de erro seja previamente anunciada ou interpretada corretamente por tecnologias de apoio.

    Image

    Figura 1 - Mensagem de erro de autenticação parcialmente apresentada antes do encerramento do pedido na página de Login

    URLs a verificar

    Recomendações

    Recomenda-se a implementação de mecanismos consistentes de comunicação de erros que garantam acessibilidade total das mensagens.

    Em particular:

    • utilizar role="alert" para mensagens de erro críticas;
    • utilizar aria-live="assertive" quando a mensagem de erro deva ser imediatamente anunciada;
    • garantir que mensagens de erro são inseridas num elemento acessível e associado ao campo correspondente através de aria-describedby;
    • assegurar que o foco é gerido de forma adequada após a ocorrência de erro, sem impedir a leitura completa da mensagem;
    • evitar truncamento de mensagens ou cortes visuais que impeçam a leitura integral;
    • validar o comportamento com leitores de ecrã e navegação por teclado.

  • issue #26 Feedback após submissão não acessível

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

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

    Evidências

    Após submissão do formulário:

    • A mensagem de 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 (TAB)
    • 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

    URLs 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.1 - A informação já introduzida deve poder ser corrigida a qualquer momento

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #3 A informação introduzida não pode ser corrigida após erro de validação

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

    A informação já introduzida deve poder ser corrigida a qualquer momento.
    – ver requisito 4.1 na lista Transação

    Evidências

    No formulário analisado, verificou-se que após a submissão do formulário e ocorrência de erro de validação, alguns campos permanecem bloqueados (readonly), impossibilitando a correção da informação introduzida pelo utilizador.

    Apesar de o sistema indicar que o campo contém dados inválidos (“Campo com dados inválidos.”), o mesmo permanece em estado apenas de leitura (readonly), impedindo que o utilizador altere ou corrija a informação.

    Como consequência, o utilizador não consegue corrigir autonomamente os dados submetidos após erro de validação, sendo forçado a abandonar o processo, reiniciar o preenchimento ou recorrer a mecanismos alternativos.

    Image

    Figura 1 - Campo assinalado como inválido após submissão sem possibilidade de correção

    URLs a verificar

    Recomendações

    Recomenda-se garantir que, após uma tentativa de submissão com erro, toda a informação introduzida possa ser corrigida pelo utilizador a qualquer momento.

    Em particular:

    • evitar que campos inválidos permaneçam em estado readonly após falha de validação;
    • garantir que os utilizadores conseguem editar diretamente os dados assinalados como incorretos;
    • caso existam campos preenchidos automaticamente, disponibilizar um mecanismo claro que permita a sua alteração quando necessário;
    • validar o comportamento após erro de submissão, assegurando que o utilizador consegue recuperar e corrigir o formulário sem reiniciar o processo.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #29 Existem mensagens de erro apresentadas entre a etiqueta e o campo

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

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

    Evidências

    Foi identificado um campo de formulário cuja mensagem de erro é apresentada antes do componente visual interativo, quebrando a consistência da estrutura observada nos restantes controlos do website.

    Como consequência, a mensagem de erro surge visualmente entre a etiqueta e o campo percecionado pelo utilizador, em vez de ser apresentada após o controlo do formulário, criando inconsistência visual e podendo dificultar a compreensão da associação entre erro e campo.

    Image

    Figura 1 - Mensagem de erro apresentada a seguir à etiqueta

    URLs a verificar

    Recomendações

    • Garantir que as mensagens de erro são apresentadas após o último elemento visual do campo, mantendo a coerência com os restantes controlos do website.
    • Validar visualmente e por navegação por teclado que a ordem de leitura e apresentação do campo permanece consistente e previsível.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

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

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

    Evidências

    A mensagem de erro “Por favor, introduza um endereço eletrónico válido.” presente nos formulários das páginas "Registar" e "Nova inscrição - Campos de Férias Municipais 2026", 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.

    Image

    Figura 1 - Mensagem de erro que não guia o utilizador na resolução do erro

    URLs a verificar

    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 2 melhorias que se recomenda efetuar)

Lista de evidências recolhidas:

Significado das etiquetas utilizadas