Relatório Avaliação de Candidatura
Portal da Bolsa de Emprego de Câmara de Lobos

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #66 Não é possível identificar quando o menu está aberto ou fechado

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.2

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

  • Ver requisito 1.2 da lista 10 aspetos

  Evidencias:

  Quando abrimos ou fechamos o menu com o leitor de ecrã não é informado se o botão está expandido (aberto) ou colapsado (fechado):

  

  Imagem do NVDA apenas a reconhecer o botão como "abrir menu" mesmo quando é para fechar.

  URL's a verificar:

  https://bolsadeemprego.cm-camaradelobos.pt/ - menu principal

  Recomendações:

  • O estado do botão menu deve ser informado através do atributo aria-expanded.

• evidência: issue #64 O menu principal não está estruturado como uma navegação

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.2

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

  • Ver requisito 1.2 da lista 10 aspetos

  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 desktop não está definido como navegação

  

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

  URL's a verificar:

  https://bolsadeemprego.cm-camaradelobos.pt/ - menu principal

  Recomendações:

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #67 O menu principal não possui texto alternativo

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.3

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

  • Ver requisito 1.3 da lista 10 aspetos

  Evidencias:

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

  

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

  URL's a verificar:
  https://bolsadeemprego.cm-camaradelobos.pt/ - menu principal

  Recomendações:

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

  

  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.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #72 Problemas de cabeçalhos na página lista de candidaturas

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 2.1

  Evidências

  Foram identificados vários problemas de acessibilidade na página da lista de candidaturas:

  • Não é possível ler o cabeçalho “Lista Candidaturas” através de leitores de ecrã, dificultando a utilização da página por pessoas com deficiência visual.
  • Os cabeçalhos da página encontram-se ocultos através de CSS, tornando-os invisíveis para os utilizadores (ver Figuras 1 e 2).
  • O cabeçalho “Candidaturas espontâneas” aparenta não ter relevância contextual na página, além de também se encontrar oculto.

  

  Figura 1 - Página da lista de candidaturas sem alterações .

  

  Figura 2 - Página da lista de candidaturas após alteração do CSS, permitindo visualizar os cabeçalhos .

  

  Figura 3 - Estrutura de cabeçalhos da página identificada através da extensão Web Developer .

  Recomendações

  • Garantir que o cabeçalho principal da página (“Lista Candidaturas”) pode ser corretamente identificado e lido por leitores de ecrã.
  • Alterar “Lista Candidaturas” para o <h1> principal da página, substituindo o <h1> genérico atual (“Bolsa de Emprego de Câmara de Lobos”).
  • Rever o CSS aplicado aos cabeçalhos, garantindo que estes permanecem visíveis para os utilizadores.
  • Remover o cabeçalho “Candidaturas espontâneas” caso este não tenha relevância estrutural ou contextual na página.

• evidência: issue #36 Existência de multiplos h1 na página web

  etiqueta: chk 10 webetiqueta: NOKetiqueta: 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ã.

  

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

  URLs a verificar:

  • https://bolsadeemprego.cm-camaradelobos.pt/acessibilidade

  Recomendações

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

• evidência: issue #35 Cabeçalho h1 genérico em todas as páginas

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 2.1

  Evidências

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

  

  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.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #37 Cabeçalhos no footer

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 2.2

  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>.

  

  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 "Institucional", "Serviços Municipais", "Participação" e "Emprego" para cabeçalhos.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #39 Não foram encontradas tabelas

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

  Evidências

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

  Recomendações

  Nada a acrescentar.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #38 Não foram encontradas tabelas

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

  Evidências

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

  Recomendações

  Nada a acrescentar.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #50 O atributo placeholder está a substituir a etiqueta

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.1

  Evidências

  Nos formulários das páginas lista de candidaturas e ofertas de emprego, verificámos que não existe etiqueta no campo de pesquisa:

  

  Campo de pesquisa sem etiqueta e com atributo placeholder
  Como se pode observar na figura, o campo de pesquisa não tem um elemento , mas sim um atributo placeholder que está a substituir a etiqueta.
  Tal situação não é recomendável, uma vez que o conteúdo do placeholder desaparece da interface assim que se começa a escrever no campo, o que pode ser prejudicial para utilizadores com défice de memória.
  Quando cada campo tem uma etiqueta que lhe está associada programaticamente, é possível focar o campo ao clicar na etiqueta (ampliação da área de clique), o que pode beneficiar pessoas com dificuldades motoras ao selecionar um campo específico.

  Recomendações

  Recomendamos a revisão dos formulários para garantir que todos os campos estejam corretamente construídos:
  • A etiqueta do campo deve estar estruturada como e deve estar associada ao campo.
  • Para estar associada ao campo, o atributo for da etiqueta e o id do campo de input devem ser iguais.
  Alguns exemplos de estrutura seriam:

  <label for="firstname">Primeiro nome:</label>
  <input type="text" name="first" id="firstname">
  

  Ou,

  <label>
      Primeiro nome:
      <input type="text" name="firstname">
  </label>
  

• evidência: issue #49 Existem campos sem etiquetas associadas

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.1

  Evidências

  Nos formulários das páginas lista de candidaturas e ofertas de emprego, verificámos que os campos “Categoria” e “Freguesia” não têm etiquetas associadas:

  

  Campo "Categoria” sem etiquetas associadas

  Recomendações

  Recomendamos a implementação de etiquetas associadas programaticamente a todos os campos dos formulários, seja de forma explícita ou de forma implícita.
  Para além disso recomendamos também uma de duas alternativas para melhoria da acessibilidade das comboboxes:

  • A utilização de elementos combobox nativos, que já oferecem todos os mecanismos de acessibilidade;
  • A restruturação das comboboxes editáveis presentes no site, de modo a torná-las acessíveis. Para tal, podem seguir o exemplo da W3C Editable Combobox With Both List and Inline Autocomplete.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #60 Não há informação clara sobre o que é o asterisco nos campos de preenchimento obrigatório

  etiqueta: chk 10 webetiqueta: NOKetiqueta: 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.

  Verificámos que no formulário da página Anunciar Oferta de Emprego não existe informação sobre o significado do asterisco (*) colocado à frente dos campos.

  

  _Figura 1 - Formulário da página Anunciar Oferta de Emprego. Não existe informação sobre o significado do asterisco (*) colocado à frente dos campos.

  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 *.

• evidência: issue #57 Há campos obrigatórios que não estão identificados programaticamente

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.2

  Evidências

  Verificámos que, em alguns campos dos formulários Anunciar Oferta de Emprego e Candidaturas Espontâneas, existem campos de preenchimento obrigatório que não estão programaticamente definidos como tal.

  

  Figura 1 - Análise do campo "Declaro sob compromisso de honra a veracidade de todas as declarações prestadas e assumo toda a responsabilidade consequente da sua inexatidão ou falsidade.".

  

  Figura 2 - Análise do campo "Declaro que li e aceito a Política de Privacidade.".

  Para além disso, existem campos em que o atributo required tem uma sintaxe incorreta (foi utilizado required = "", em vez de required ou required = "true"), para além de que não é necessário utilizar os dois atributos (required e aria-required) ao mesmo tempo.
  Acresce ainda que foram inseridos atributos aria-required = "true" em etiquetas. Atributos required ou aria-required em etiquetas não têm qualquer efeito, bem pelo contrário, são semanticamente incorretos e dificultam a manutenção do site.

  

  Figura 3 - Etiqueta com o atributo aria-required

  Recomendações

  • Recomendamos que, em todos os campos obrigatórios, seja adicionado o atributo required nos campos de input de forma a reforçar aos utilizadores de tecnologias de apoio que o campo em questão é um campo de preenchimento obrigatório.
  • Também recomendamos ainda que seja verificada a sintaxe do atributo required nos elementos que já o têm, e que, no caso da existência dos atributos required e aria-required, permaneça apenas o atributo required.
  • Finalmente, recomendamos a remoção de todos os atributos required e aria-required de todas as etiquetas (<label>).

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #81 Existem campos sem mensagens de erro na sua vizinhança

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.3

  Evidências

  Os campos “NIF/NIPC” e “Id de candidatura / oferta”, presentes no formulário Alterar Dados, apresentam referências a mensagens de erro através do atributo aria-describedby, mas os respetivos elementos referenciados não existem no DOM.

  Contudo, não foram encontrados elementos com os identificadores fiscalid-error e referencia-error, impossibilitando que leitores de ecrã anunciem mensagens de erro associadas aos campos.

  Adicionalmente, as mensagens de erro existentes (ex.: “O NIF/NIPC indicado é inválido” e “O NIF/NIPC e o id de candidatura/oferta não correspondem.”) surgem separadas dos campos e sem associação programática aos mesmos.

  

  Figura 1- Campos com referências a mensagens de erro inexistentes ou não associadas programaticamente

  URL a verificar

  • https://bolsadeemprego.cm-camaradelobos.pt/alterar-dados

  Recomendações

  • Garantir que todas as mensagens de erro possuem um identificador único existente no DOM;
  • Associar programaticamente as mensagens de erro aos respetivos campos através de aria-describedby ou aria-errormessage;
  • Utilizar aria-invalid="true" quando o campo se encontra em estado inválido;
  • Garantir que as mensagens de erro são anunciadas corretamente por leitores de ecrã quando o foco navega pelos campos;
  • Validar o comportamento com navegação por teclado e tecnologias de apoio.

• evidência: issue #62 Existem mensagens de erro apresentadas entre a etiqueta e o campo

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.3

  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.

  

  Figura 1 - Mensagem de erro apresentada a seguir à etiqueta

  URL a verificar

  • https://bolsadeemprego.cm-camaradelobos.pt/anunciar-oferta-de-emprego
  • https://bolsadeemprego.cm-camaradelobos.pt/candidaturas-espontaneas

  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.

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

Lista de evidências recolhidas:

• evidência: issue #3 (Melhoria) Imagens decorativas com texto alternativo indevido

  etiqueta: chk 10 webetiqueta: R 5.1etiqueta: melhoria

  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="".

  

  ---

  Verificado que alguns nomes alternativos das imagens incluem caracteres especiais (como _), que estão a ser lidos pelo leitor de ecrã como "sublinhado".
  Quando a imagem não for decorativa, é recomendado que o equivalente alternativo seja apresentado em linguagem natural, sem identificadores técnicos ou caracteres desnecessários.

  

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

  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.
  • Quando a imagem não for decorativa deverá 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.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #13 O gráfico é acompanhado de uma descrição longa

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

  Evidências

  Não foram identificados gráficos ou imagens complexas no website.

  Recomendações

  N/A

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #77 Imagem-link com nome acessível definido incorretamente através de title

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.3

  Evidências

  Verifica-se que as imagens-link das redes sociais estão a depender exclusivamente do atributo title para fornecer o seu nome acessível. Nesse caso o equivalente alternativo deve ser disponibilizado no mecanismo acessível principal através do aria-label.

  

  URL:

  https://bolsadeemprego.cm-camaradelobos.pt/

  Recomendações

  • O texto alternativo deve transmitir claramente o destino ou finalidade do link. Por exemplo: aria-label="Visite o nosso Twitter"
  • Remover o title.

• evidência: issue #4 Imagens link com texto alternativo incorreto.

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.3

  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 que é acesso à página inicial. Por exemplo: alt="Camara de Lobos - acesso a página inicial".

  

  ---

  

  URL:

  https://bolsadeemprego.cm-camaradelobos.pt/candidaturas-espontaneas

  Recomendações

  • O texto alternativo deve transmitir claramente o destino ou finalidade do link.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #46 Texto normal não tem contraste suficiente

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 6.1

  Evidências

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

  

  Figura 1 - Texto com problemas de contraste nas mensagens de erro.

  

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

  URLs a verificar:

  https://bolsadeemprego.cm-camaradelobos.pt/detalhe-candidatura?Y2FuZGlkYXR1cmFfaWQ9OTIzNzk0Mjc4Nw==
  https://bolsadeemprego.cm-camaradelobos.pt/lista-candidaturas
  https://bolsadeemprego.cm-camaradelobos.pt/ofertas-de-emprego

  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.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #47 Textos grandes em imagens que não cumprem o rácio de contraste

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 6.2

  Evidências

  O contraste no texto grande (superior a 18 pontos ou superior a 14 pontos negrito) das páginas deve ser, no mínimo 3:1, para que as pessoas com baixa visão consigam ler o texto. É necessário também garantir que os textos por cima de imagens possuem contraste, principalmente quando a imagem é alterada ao longo do tempo, mas o estilo do texto mantém-se.


  Na página Oportunidade de Emprego, os textos grandes aplicados às imagens por exemplo “Oportunidade de emprego” e “Bolsa de emprego” apresentam problema de contraste na combinação de cores #FFFFFF(cor de primeiro plano) e #9ECBE8(cor de plano de fundo) pois tornam os textos pouco visíveis. (Figura 1 e 2)

  

  Figura 1- Textos grandes com problemas de contraste .

  

  Figura 2- Textos grandes com problemas de contraste .

  Recomendações

  • Sugerimos que escureçam as imagens (do slideshow/banner por exemplo), colocando um filtro, para que o texto e o botão fiquem mais legíveis.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #42 Não foram encontrados players no website.

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

  Evidências

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

  Recomendações

  Nada a acrescentar.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #43 Não foram encontrados players no website.

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

  Evidências

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

  Recomendações

  Nada a acrescentar.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #79 Ausência de landmarks semânticos

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

  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.

  

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

  URLs a verificar

  • https://bolsadeemprego.cm-camaradelobos.pt/
  • (em todo o website)

  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

• evidência: issue #76 Duplicação de links para o mesmo conteúdo

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

  Evidências

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

  • Um elemento <a> que envolve a imagem (<img>)
  • Um elemento <a> que envolve o título (<h3>), funcionando como chamada principal do conteúdo

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

  

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

  Notas Gerais

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

  URL a verificar

  • https://bolsadeemprego.cm-camaradelobos.pt/

  Recomendações

  • Remover a duplicação de links com o mesmo destino dentro do mesmo bloco de conteúdo
  • Remover o link associado à imagem e manter apenas o link do título como elemento principal de navegação
  • Caso a imagem seja meramente decorativa, garantir que não constitui um elemento interativo autónomo
  • Garantir uma estrutura de navegação mais limpa e consistente para utilizadores e tecnologias de apoio

• evidência: issue #52 Modais sem nome acessível programaticamente determinável

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

  Evidências

  Na janela de candidatura observada, o conteúdo é apresentado visualmente como uma modal (.candidatura), sendo exibido e ocultado dinamicamente através de JavaScript (display: block / display: none).

  Contudo, a estrutura não possui semântica acessível de diálogo, não sendo utilizado role="dialog" nem aria-modal="true" no contentor principal da janela. Adicionalmente, não existe qualquer nome acessível associado ao diálogo.

  Embora exista um título visível - “Candidatura a oferta de emprego” - este não está associado programaticamente à janela através de aria-labelledby, nem é fornecido um nome alternativo com aria-label.

  Como consequência, quando a janela é aberta, tecnologias de apoio podem não anunciar corretamente a abertura de um diálogo, nem o respetivo contexto ou finalidade, dificultando a navegação e compreensão por parte de utilizadores de leitores de ecrã.

  

  Figura 1 - Janela de candidatura sem nome acessível programaticamente determinável

  Notas Gerais

  • As janelas modais devem possuir semântica programaticamente identificável, permitindo que tecnologias de apoio reconheçam corretamente a abertura de um diálogo e anunciem o respetivo contexto ao utilizador.
  • Sempre que exista um título visível, este deve ser associado ao diálogo através de aria-labelledby. Quando não exista título visível, deve ser fornecido um nome acessível através de aria-label.
  • A ausência destas associações pode impedir que leitores de ecrã comuniquem corretamente a finalidade da janela apresentada, comprometendo a compreensão do fluxo de interação.

  URL a verificar

  • https://bolsadeemprego.cm-camaradelobos.pt/detalhe-oferta?b2ZlcnRhX2lkPTQ0Njk0Nzg4NDk=
  • (outras páginas de ofertas de emprego)

  Recomendações

  • Priorizar a utilização do elemento HTML nativo <dialog> para implementação da janela modal, por fornecer semântica apropriada e melhor suporte de acessibilidade
  • Garantir que a modal possui um nome acessível, preferencialmente associando o título visível através de aria-labelledby:

  <dialog aria-labelledby="tituloCandidatura">
      <h3 id="tituloCandidatura">
          Candidatura a oferta de emprego
      </h3>
  </dialog>
  

  • Quando não existir título visível, utilizar aria-label
  • Caso não seja possível utilizar <dialog>, implementar role="dialog" e aria-modal="true" no contentor principal
  • Garantir a gestão correta do foco do teclado durante a abertura e utilização da modal
  • Referência: MDN – HTML <dialog> element

• evidência: issue #51 Controlos de fecho de modal/carousel implementados com elementos não semânticos

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

  Evidências

  No componente de modal/carousel observado, o controlo de fecho é implementado através de um elemento genérico (<div>), utilizado para executar uma ação de interface.

  Apesar de o elemento poder ser focável e interativo através de JavaScript, não utiliza um elemento HTML semântico apropriado para ações, como <button>.

  Como consequência, a função do controlo não é corretamente transmitida de forma nativa às tecnologias de apoio, dependendo de atributos adicionais e comportamento programado para simular a sua funcionalidade.

  

  Figura 1 – Controlo de fecho de modal/carousel implementado com <div> em vez de <button>

  Notas Gerais

  • Elementos interativos como controlos de fecho devem ser implementados com elementos HTML semanticamente apropriados, como <button>, de forma a garantir que são corretamente interpretados por tecnologias de apoio e suportam navegação por teclado.
  • A utilização de elementos genéricos como <div> para representar ações interativas compromete a semântica do componente e obriga à simulação do comportamento através de scripts.

  URL a verificar

  • https://bolsadeemprego.cm-camaradelobos.pt/detalhe-oferta?b2ZlcnRhX2lkPTQ0Njk0Nzg4NDk=
  • (outras páginas de ofertas de emprego)

  Recomendações

  • Substituir o elemento <div> por um elemento semântico <button> para o controlo de fecho.
  • Garantir que o botão mantém toda a funcionalidade existente, incluindo:
    • ativação por teclado (Enter e Espaço);
    • foco acessível e visível;
    • comportamento consistente em diferentes tecnologias de apoio.
  • Evitar o uso de elementos genéricos para representar ações interativas em componentes de modal/carousel.
  • Validar o comportamento com navegação por teclado e leitores de ecrã para garantir que a função é corretamente anunciada e operável.

• evidência: issue #34 Listagem de conteúdos sem estrutura semântica adequada

  etiqueta: chk 10 webetiqueta: NOKetiqueta: 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.

  

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

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

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

  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

  • https://bolsadeemprego.cm-camaradelobos.pt/
  • (vários elementos em todo o website)

  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.

• evidência: issue #33 Campo de seleção não comunica corretamente a opção selecionada

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

  Evidências

  Nas páginas de lista de candidaturas e ofertas de emprego, os filtros de pesquisa incluem campos do tipo seleção (dropdown), nomeadamente “Categoria” e “Freguesia”.

  Foi identificado que a seleção destes campos não comunica corretamente o estado atual da opção selecionada:

  • visualmente, o valor apresentado no componente pode não refletir de forma clara a opção ativa;
  • com leitor de ecrã, não é corretamente indicado o estado selecionado do campo;
  • o campo de seleção nativo (<select>) encontra-se oculto das tecnologias de apoio, sendo substituído por um componente personalizado baseado em <span role="combobox">. Esta implementação pode impedir a correta identificação da opção atualmente selecionada e do estado do campo por leitores de ecrã.

  Como consequência, o utilizador pode não compreender qual a opção atualmente ativa, comprometendo a interpretação e utilização dos filtros.

  

  Figura 1 - Campo de seleção (Freguesia) com indicação inconsistente da opção selecionada na interface e leitor de ecrã

  Notas Gerais

  • Campos de formulário devem comunicar de forma clara e consistente o valor atualmente selecionado.
  • A substituição de controlos nativos por componentes estilizados deve garantir equivalência semântica completa.
  • Tecnologias de apoio devem conseguir identificar:
    • o elemento como um campo de seleção;
    • a opção atualmente selecionada;
    • alterações de estado quando o utilizador interage com o campo.
  • O valor selecionado deve ser refletido de forma inequívoca tanto visualmente como via acessibilidade.

  URL a verificar

  • https://associativismo.cm-camaradelobos.pt/menu/lista-associacoes?Y2F0PTE=

  Recomendações

  • Garantir que o componente de seleção mantém a semântica nativa de <select> sempre que possível.
  • Caso seja necessário manter o Select2, assegurar que:
    • o estado selecionado é corretamente exposto via ARIA;
    • o valor ativo é atualizado e anunciado corretamente por leitores de ecrã;
    • existe coerência entre o valor visual e o valor acessível.
  • Validar o comportamento dos filtros com navegação por teclado e leitores de ecrã.
  • Confirmar que qualquer alteração de seleção é imediatamente refletida no estado acessível do componente.

  Recomendações

  • Garantir que o componente de seleção mantém a semântica nativa de <select> sempre que possível.
  • Caso seja necessário manter o Select2, assegurar que:
    • o estado selecionado é corretamente exposto via ARIA;
    • o valor ativo é atualizado e anunciado corretamente por leitores de ecrã;
    • existe coerência entre o valor visual e o valor acessível.
  • Validar o comportamento dos filtros com navegação por teclado e leitores de ecrã.
  • Confirmar que qualquer alteração de seleção é imediatamente refletida no estado acessível do componente.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #26 Ticker de ofertas de emprego com movimento automático sem mecanismo percetível de controlo

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.4

  Evidências

  Na homepage foi identificado um ticker de ofertas de emprego com deslocação horizontal automática contínua.

  O componente apresenta conteúdos que se deslocam automaticamente da direita para a esquerda sem interação inicial do utilizador.

  Embora existam controlos de navegação e reprodução/pausa no componente, estes são apresentados apenas através de ícones sem identificação textual visível, podendo não ser suficientemente percetíveis ou compreensíveis para todos os utilizadores.

  Adicionalmente, o conteúdo inicia automaticamente o movimento logo após o carregamento da página.

  Como consequência, os utilizadores podem ter dificuldade em:

  • interromper o movimento;
  • compreender a existência dos controlos;
  • ler ou acompanhar o conteúdo em movimento contínuo.

  

  Figura 1 – Ticker de ofertas de emprego com deslocação automática contínua e controlos de pausa/navegação pouco percetíveis

  Notas Gerais

  Conteúdos em movimento automático podem dificultar a leitura, a concentração e a interação, sobretudo quando os mecanismos de controlo não são claramente identificáveis ou facilmente utilizáveis.

  Sempre que existam componentes com animação contínua, deslocação automática ou atualização dinâmica, deve existir um mecanismo acessível e facilmente identificável que permita:

  • pausar;
  • parar;
  • retomar;
  • navegar manualmente pelo conteúdo.

  Os controlos devem ser visualmente claros, semanticamente corretos e facilmente compreendidos por todos os utilizadores.

  URL a verificar

  • https://bolsadeemprego.cm-camaradelobos.pt/ (Homepage - ticker de ofertas de emprego

  Recomendações

  • Garantir que os controlos de pausa, reprodução e navegação são claramente percetíveis na interface e que o deslocamento automático do ticker é pausado quando o foco de teclado entra no componente ou num dos seus elementos interativos, evitando movimento contínuo durante a navegação por teclado.
  • Adicionar identificação textual ou nomes acessíveis aos botões de controlo.
  • Garantir que o utilizador consegue interromper facilmente o movimento automático.
  • Validar que os controlos são operáveis por teclado e corretamente anunciados por tecnologias de apoio.
  • Considerar evitar o início automático da animação sem ação explícita do utilizador.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #5 Quando a caixa de diálogo é aberta, o foco não move-se para um elemento dentro da caixa de diálogo

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.1

  Evidências

  Verifica-se que a modal não se encontra acessível a tecnologias de apoio. Quando é aberta, o foco não é deslocado para o seu interior, impedindo que utilizadores de leitor de ecrã e navegação por teclado consigam alcançar e interagir com os campos da modal.

  

  URL:

  https://bolsadeemprego.cm-camaradelobos.pt/detalhe-oferta?b2ZlcnRhX2lkPTQ0Njk0Nzg4NDk=
  https://bolsadeemprego.cm-camaradelobos.pt/lista-candidaturas
  https://bolsadeemprego.cm-camaradelobos.pt/candidaturas-espontaneas
  https://bolsadeemprego.cm-camaradelobos.pt/ofertas-de-emprego
  https://bolsadeemprego.cm-camaradelobos.pt/alterar-dados
  https://bolsadeemprego.cm-camaradelobos.pt/detalhe-candidatura?Y2FuZGlkYXR1cmFfaWQ9OTQxOTEyOTI3Ng==

  Recomendações

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #6 O foco não fica limitado a caixa de diálogo

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.2

  Evidências

  Verifica-se que quando a modal esta aberta o foco não fica limitado a modal (teclado, leitor de ecrã).

  

  **URL: **

  https://bolsadeemprego.cm-camaradelobos.pt/detalhe-oferta?b2ZlcnRhX2lkPTQ0Njk0Nzg4NDk=
  https://bolsadeemprego.cm-camaradelobos.pt/anunciar-oferta-de-emprego
  https://bolsadeemprego.cm-camaradelobos.pt/detalhe-oferta?b2ZlcnRhX2lkPTQ0Njk0Nzg4NDk=
  https://bolsadeemprego.cm-camaradelobos.pt/lista-candidaturas
  https://bolsadeemprego.cm-camaradelobos.pt/candidaturas-espontaneas
  https://bolsadeemprego.cm-camaradelobos.pt/alterar-dados
  https://bolsadeemprego.cm-camaradelobos.pt/detalhe-candidatura?Y2FuZGlkYXR1cmFfaWQ9OTQxOTEyOTI3Ng==

  Recomendações

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #7 A caixa de diálogo não pode ser encerrada através de tecnologias de apoio.

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.3

  Evidências

  Verifica‑se que a modal não está acessível às tecnologias de apoio, impedindo que a modal seja encerrada por leitor de ecrã ou teclado.

  

  URL:

  https://bolsadeemprego.cm-camaradelobos.pt/detalhe-oferta?b2ZlcnRhX2lkPTQ0Njk0Nzg4NDk=
  https://bolsadeemprego.cm-camaradelobos.pt/lista-candidaturas
  https://bolsadeemprego.cm-camaradelobos.pt/candidaturas-espontaneas
  https://bolsadeemprego.cm-camaradelobos.pt/ofertas-de-emprego
  https://bolsadeemprego.cm-camaradelobos.pt/alterar-dados
  https://bolsadeemprego.cm-camaradelobos.pt/detalhe-candidatura?Y2FuZGlkYXR1cmFfaWQ9OTQxOTEyOTI3Ng==

  Recomendações

  • A modal deve ser acessível por tecnologias de apoio (leitor de ecrã e teclado).

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #8 Ao fechar a caixa de diálogo o foco não retorna ao elemento que o invocou.

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.4

  Evidências

  Validado que ao fechar a modal o foco não retorna ao elemento que o invocou.

  

  URL:

  https://bolsadeemprego.cm-camaradelobos.pt/detalhe-oferta?b2ZlcnRhX2lkPTQ0Njk0Nzg4NDk=
  https://bolsadeemprego.cm-camaradelobos.pt/lista-candidaturas
  https://bolsadeemprego.cm-camaradelobos.pt/candidaturas-espontaneas
  https://bolsadeemprego.cm-camaradelobos.pt/ofertas-de-emprego
  https://bolsadeemprego.cm-camaradelobos.pt/alterar-dados
  https://bolsadeemprego.cm-camaradelobos.pt/detalhe-candidatura?Y2FuZGlkYXR1cmFfaWQ9OTQxOTEyOTI3Ng==

  Recomendações

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

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #41 Não foram encontrados ficheiros PDF

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

  Evidências

  Não foram encontrados ficheiros PDF. tornando este critério N/A.

  Recomendações

  Nada a acrescentar.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #9 Falta de resumo visível na página principal

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 1.1

  Evidências

  Na página principal do website de Bolsas de Emprego da Câmara Municipal de Câmara de Lobos, não aparece presente um resumo breve do próposito do site.

  

  Imagem da página principal sem fazer scroll

  Recomendações

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

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

  

  Imagem exemplo de uma frase de propósito do website selo.usabilidade.gov

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #19 Falta de glossário para termos complexos

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 1.2

  Evidências

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

  

  Imagem com diversos termos complexos no rodapé sem definição agregada.

  

  Imagem com diversos termos complexos sem definição agregada. Disponível em: https://bolsadeemprego.cm-camaradelobos.pt/programas-de-emprego

  Outros Exemplos:

  • CV, IEM e RAM no menu principal
  • NIPC e NIF: https://bolsadeemprego.cm-camaradelobos.pt/o-que-pode-ser-publicado-pelas-empresas
  • NIPC: https://bolsadeemprego.cm-camaradelobos.pt/anunciar-oferta-de-emprego
  • IEM-IP e RAM: https://bolsadeemprego.cm-camaradelobos.pt/programas-para-estagios-profissionais
  • IEM-IP e RAM: https://bolsadeemprego.cm-camaradelobos.pt/programas-para-empreendedores
  • IEM, IP-RAM, IEM-IP e RAM: https://bolsadeemprego.cm-camaradelobos.pt/polo-de-emprego-de-camara-de-lobos
  • RAM: https://bolsadeemprego.cm-camaradelobos.pt/bolsa-de-emprego-publico-ram

  Recomendações

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

  Como exemplo podem visualizar o glossario do acessibilidade.gov.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #70 O conteúdo do site fica desformatado em resoluções mais pequenas

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 2.1

  Evidências

  O website apresenta inconsistências na adaptação dos tamanhos de texto em resoluções mais reduzidas.
  Durante a navegação em formato mobile, verificou-se que, alguns links e elementos textuais da página apresentam dimensões reduzidas, comprometendo a legibilidade e dificultando a leitura do conteúdo. (Figura 1)

  

  Figura 01 — Elementos textuais com dimensão reduzida em dispositivos móveis.

  

  Figura 02 — Botões da secção de ofertas com texto de dimensão reduzida em mobile.

  

  Figura 03 — Texto descritivo da candidatura com dimensão reduzida em mobile.

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



  • https://bolsadeemprego.cm-camaradelobos.pt/polo-de-emprego-de-camara-de-lobos
  • https://bolsadeemprego.cm-camaradelobos.pt/o-que-pode-ser-publicado-pelas-empresas
  • https://bolsadeemprego.cm-camaradelobos.pt/o-que-pode-ser-publicado-pelos-jovens-e-residentes

  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.

• evidência: issue #54 O corpo de texto tem um tamanho inferior a 12pt (equivalente a 16px)

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 2.1

  Evidências

  O website possui informações primárias com tamanho de letra inferior ao mínimo recomendado de 12 pontos (16px).

  Entre os casos identificados encontram-se o botão “Digital” presente na barra superior do website (disponível em todas as páginas do website), bem como os botões “Candidaturas/Procura”, “Ofertas emprego”, “Efetuar uma proposta de emprego”, “Polos de Emprego (IEM)”, “Programas para estágios (IEM)” e “Programas para empreendedores (IEM)”, que apresentam tamanho de letra inferior ao recomendado no estado analisado.

  

  Figura 01 — Botão “Digital” com tamanho de letra inferior ao recomendado.

  Há elementos clicáveis com tamanho de texto inferior ao recomendado.
  Por exemplo os botões “Ver todas as candidaturas” e “Limpar filtro” na página Lista de candidaturas apresentam tamanho de letra de apenas 14px no estado analisado.

  

  Figura 02 — Botões “Ver todas as candidaturas” e “Limpar filtro” com tamanho de letra inferior ao recomendado.

  Recomendações

  Recomendamos que os elementos textuais principais e ações clicáveis do website apresentem um tamanho de letra mínimo de 12 pontos (16px), de forma a garantir uma leitura confortável e consistente em diferentes dispositivos e contextos de utilização.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #55 Existem blocos de textos com mais de 100 caracteres por linha

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 2.3

  Evidências

  Verificámos que no website há blocos de textos apresentam largura superior ao recomendado por linha.
  Por exemplo na página Bolsa de Emprego Público - RAM
  (Figura 01)

  

  Figura 01 — Análise de bloco de texto na ferramenta WordCounter com 130 caracteres.

  Outras Evidências (NOK)

  • https://bolsadeemprego.cm-camaradelobos.pt/polo-de-emprego-de-camara-de-lobos (148 caracteres)
  • https://bolsadeemprego.cm-camaradelobos.pt/detalhe-candidatura?Y2FuZGlkYXR1cmFfaWQ9OTIzNzk0Mjc4Nw== (192 caracteres)
  • https://bolsadeemprego.cm-camaradelobos.pt/o-que-pode-ser-publicado-pelas-empresas (161 caracteres)
  • https://bolsadeemprego.cm-camaradelobos.pt/a-bolsa-de-emprego-de-camara-de-lobos (164 caracteres)

  Recomendações

  Revisar blocos de textos para garantir que não é ultrapassado o número máximo de caracteres por linha. Recomendamos que seja definida uma largura máxima para as caixas de texto (max-width, em CSS), com unidades relativas ao tamanho de fonte (unidades em ou rem).

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #59 O espaçamento entre linhas está abaixo do recomendado

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 2.4

  Evidências

  Na página Anunciar oferta de emprego há bloco de textos com espaçamento inferior ao recomendado, espaçamento de 22.85px para um tamanho de letra de 16px. (Figura 01)



  

  Figura 01 — Espaçamento insuficiente entre linhas de texto.

  No rodapé do website há bloco de texto que apresenta espaçamento entre linhas inferior ao recomendado relativamente ao tamanho da letra ultilizado, espaçamento de 20px para um tamanho de letra 14px. (Figura 02)

  

  Outras evidências de espaçamento incorreto:

  • https://bolsadeemprego.cm-camaradelobos.pt/
  • https://bolsadeemprego.cm-camaradelobos.pt/detalhe-oferta?b2ZlcnRhX2lkPTQ0Njk0Nzg4NDk=

  Recomendações

  Para a evidência da figura 01 apresentada, o espaçamento deveria ser, no mínimo 24px. É necessário rever todo website para garantir o espaçamento mínimo recomendado, relativo ao tamanho da letra.
  Relativamente à figura 02, o espaçamento deveria ser, no mínimo 21px, garantindo maior conforto e legibilidade na leitura do conteúdo apresentado no rodapé.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #44 A navegação principal do site está colapsada em desktop

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 3.2

  Evidências

  Boas práticas:

  No caso de breakpoints superiores, normalmente considerados para desktop, devem estar imediatamente visíveis no ecrã pelo menos as opções de 1º nível porque, à partida, existe espaço para tal.

  No caso de breakpoints inferiores, normalmente considerados para tablet e mobile, o menu pode manter-se colapsado.
  Independentemente da página, o menu deve estar sempre posicionado no mesmo local.

  Problema específico:

  Em breakpoints superiores, o menu principal do site está colapsado e só é possível expandi-lo a partir do botão “Menu hambúrguer” (ver Figura 01). Por isso, as opções de primeiro nível não são imediatamente visíveis para os utilizadores.

  

  Figura 01: Imagem da página inicial com o menu principal colapsado no topo direito.

  Recomendações

  Em breakpoints superiores, as opções de 1º nível do menu devem estar sempre visíveis na página enquanto existir espaço.

  Adicionalmente, recomenda-se alinhar a nomenclatura entre ambos os menus, ajustando as opções do menu principal, ou, em alternativa, remover as opções da barra superior.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #45 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:

  

  Imagem de hiperligações do menu do rodapé sem indicação visual.

  

  Imagem dos títulos de notícias com hiperligações sem indicação visual complementar.

  URL's a verificar:

  • https://bolsadeemprego.cm-camaradelobos.pt/

  Recomendações:

  Garantir que todos os links:

  • 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).

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #25 Páginas extensas sem índice de navegação interna entre secções

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 4.1

  Evidências

  Ponto 01
  Página: https://bolsadeemprego.cm-camaradelobos.pt/o-que-pode-ser-publicado-pelos-jovens-e-residentes

  Verificou-se que a página apresenta uma extensão considerável de conteúdo, distribuído por várias secções temáticas, sem disponibilizar um índice no topo com hiperligações internas para navegação entre os diferentes conteúdos.

  A ausência deste mecanismo dificulta a navegação rápida e a localização das diferentes secções da página, sobretudo em dispositivos móveis e para utilizadores que recorrem a navegação por teclado.

  

  Figura 01 — Página extensa sem mecanismo de navegação interna entre secções.

  Outro exemplo:
  https://bolsadeemprego.cm-camaradelobos.pt/o-que-pode-ser-publicado-pelas-empresas

  Recomendações

  Recomenda-se a inclusão de um índice no topo das páginas mais extensas, com hiperligações internas para as diferentes secções do conteúdo, facilitando a navegação e localização rápida da informação.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #15 Inconsistências de adaptação responsiva e apresentação de conteúdos em dispositivos móveis

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 4.2

  Evidências

  Ponto 01
  Página: https://bolsadeemprego.cm-camaradelobos.pt/detalhe-candidatura?Y2FuZGlkYXR1cmFfaWQ9MzY1MjgwOTQxOQ==

  Foi identificado que, em alguns dispositivos móveis, o formulário de submissão de candidatura não se adapta corretamente à área visível do ecrã.
  No estado analisado, o botão “Submeter” encontra-se demasiado próximo da borda inferior do ecrã e o botão “X” de fecho do formulário surge parcialmente cortado, dificultando a sua utilização.

  Este comportamento pode comprometer a navegação e interação em dispositivos móveis.

  

  Figura 01 — Botão “X” de fecho do formulário parcialmente cortado em ecrãs de menor dimensão.

  

  Figura 02 — Botão “Submeter” apresentado demasiado próximo da borda inferior do ecrã em dispositivos móveis.

  Outro exemplo:
  https://bolsadeemprego.cm-camaradelobos.pt/detalhe-oferta?b2ZlcnRhX2lkPTQ0Njk0Nzg4NDk=

  Ponto 02
  Página: https://bolsadeemprego.cm-camaradelobos.pt/anunciar-oferta-de-emprego

  Verificou-se que, em alguns dispositivos móveis, os textos associados às caixas de verificação (“checkbox”) do formulário deixam de manter alinhamento consistente com os respetivos elementos de seleção.

  No estado analisado, o conteúdo apresenta quebras e desalinhamentos que dificultam a leitura e associação entre o controlo e a respetiva descrição.

  

  Figura 03 — Elementos checkbox com desalinhamento entre o controlo e o respetivo conteúdo em ecrãs de menor dimensão.

  **Outro exemplo:
  https://bolsadeemprego.cm-camaradelobos.pt/candidaturas-espontaneas

  Ponto 03
  Página: https://bolsadeemprego.cm-camaradelobos.pt/a-bolsa-de-emprego-de-camara-de-lobos

  Verificou-se que, em alguns dispositivos móveis, o botão “Banco de Ideias – A Tua Ideia Conta!” surge desalinhado relativamente ao conteúdo envolvente, sobrepondo-se parcialmente ao texto e à informação apresentada no final do bloco.

  

  Figura 04 — Botão “Banco de Ideias – A Tua Ideia Conta!” desalinhado relativamente ao conteúdo envolvente em ecrãs de menor dimensão.

  Recomendações

  Recomenda-se a revisão da adaptação dos formulários e componentes em dispositivos móveis, garantindo o correto posicionamento e alinhamento dos elementos em ecrãs de menor dimensão, evitando cortes, sobreposições e desalinhamentos do conteúdo.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #16 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://bolsadeemprego.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.

  

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

  Recomendações

  Recomenda-se que os elementos interativos permaneçam visíveis independentemente da utilização de hover, garantindo o acesso às funcionalidades também em dispositivos táteis e navegação por teclado.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #17 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://bolsadeemprego.cm-camaradelobos.pt/

  Verificou-se que alguns elementos interativos presentes no cabeçalho da página apresentam dimensões inferiores ao mínimo recomendado de 44x44 píxeis CSS.

  Entre os casos identificados encontram-se os ícones das redes sociais, com aproximadamente 27x27 píxeis, o botão do menu de navegação (“hambúrguer”), com aproximadamente 37x25 píxeis, bem como os botões “Jovens e Residentes”, “Empresas” e “Digital”, que apresentam alturas inferiores à dimensão mínima recomendada no estado analisado.

  Estas dimensões podem dificultar a interação em dispositivos táteis e por utilizadores com limitações motoras.

  

  Figura 01 — Ícones de redes sociais com dimensão inferior à área interativa mínima recomendada.

  

  Figura 02 — Botão do menu de navegação “hambúrguer” com dimensão inferior à área interativa mínima recomendada.

  

  Figura 03 — Botão “Empresas” com altura inferior à dimensão mínima recomendada para elementos interativos.

  Ponto 02
  Página: https://bolsadeemprego.cm-camaradelobos.pt/detalhe-candidatura?Y2FuZGlkYXR1cmFfaWQ9MzY1MjgwOTQxOQ==

  Verificou-se que o elemento de seleção associado à opção “Declaro que li e aceito a Política de Privacidade” apresenta uma área interativa com altura de apenas 35px

  Esta limitação pode dificultar a interação em dispositivos táteis e por utilizadores com limitações motoras.

  

  Figura 01 — Elemento de seleção da Política de Privacidade com altura inferior à dimensão mínima recomendada.

  Outro exemplo:
  https://bolsadeemprego.cm-camaradelobos.pt/detalhe-oferta?b2ZlcnRhX2lkPTQ0Njk0Nzg4NDk=
  https://bolsadeemprego.cm-camaradelobos.pt/detalhe-candidatura?Y2FuZGlkYXR1cmFfaWQ9MzY1MjgwOTQxOQ==

  Ponto 03
  Página: https://bolsadeemprego.cm-camaradelobos.pt/anunciar-oferta-de-emprego

  Entre os casos identificados encontram-se os campos de seleção de hora, com altura de apenas 34 px. Caixas de verificação (“checkbox”) associadas às declarações obrigatórias, com apenas 35px de altura, bem como botões de opção (“radio button”), com apenas 22.84 px de altura na área clicável.

  Estas dimensões podem dificultar a interação em dispositivos táteis e por utilizadores com limitações motoras.

  

  Figura 02 — Campo de seleção de hora com área interativa inferior à dimensão mínima recomendada.

  

  Figura 03 — Elemento checkbox com área interativa inferior à dimensão mínima recomendada.

  

  Figura 04 — Elemento radio button com área interativa inferior à dimensão mínima recomendada.

  Outro exemplo:
  https://bolsadeemprego.cm-camaradelobos.pt/candidaturas-espontaneas

  Recomendações

  Recomenda-se a revisão das dimensões dos elementos interativos do sítio Web, garantindo áreas clicáveis adequadas em botões, campos, checkboxes, radio buttons e restantes controlos de interação, de forma a facilitar a utilização em dispositivos táteis e por utilizadores com limitações motoras.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #18 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://bolsadeemprego.cm-camaradelobos.pt/lista-candidaturas

  Verificou-se que a ação “Ver todas as candidaturas” não apresenta hierarquia visual clara enquanto ação secundária, aproximando-se visualmente de texto simples.
  Adicionalmente, o botão “Limpar filtro”, correspondente à principal ação do formulário de pesquisa, não apresenta destaque visual suficiente relativamente aos restantes elementos apresentados.

  

  Figura 01 — Ações secundárias apresentadas sem hierarquia visual clara relativamente ao conteúdo envolvente.

  Ponto 02
  Página: https://bolsadeemprego.cm-camaradelobos.pt/detalhe-oferta?b2ZlcnRhX2lkPTQ0Njk0Nzg4NDk=

  Verificou-se que o botão “Submeter” do formulário “Envie para um amigo” apresenta o mesmo tratamento visual do botão de fecho (“X”) da modal, não havendo uma diferenciação clara entre estes elementos interativos.

  Esta ausência de distinção dificulta a perceção da ação principal do formulário (botão Submeter) face à ação secundária de encerramento, podendo comprometer a usabilidade e a compreensão por parte do utilizador

  

  Figura 02 — Botão “Enviar” sem hierarquia visual clara relativamente à ação de fecho da janela.

  Recomendações

  Recomenda-se a revisão da hierarquia visual dos botões e ações do sítio Web, garantindo diferenciação clara entre ações principais e secundárias através de destaque visual consistente e adequado ao contexto de utilização.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #20 Elementos interativos com contraste insuficiente relativamente ao fundo

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 5.4

  Evidências

  Ponto 01
  Página: https://bolsadeemprego.cm-camaradelobos.pt/anunciar-oferta-de-emprego

  Verificou-se que os seletores presentes no formulário da oferta de emprego apresentam contraste insuficiente entre o texto e o fundo no estado analisado.
  Foram identificados rácios de contraste de 2.84:1, abaixo do valor mínimo recomendado para conteúdo textual.

  Esta situação pode dificultar a leitura e identificação das opções disponíveis por utilizadores com baixa visão.

  

  Figura 01 — Seletores do formulário com contraste insuficiente entre o texto e o fundo.

  Outro exemplo:
  https://bolsadeemprego.cm-camaradelobos.pt/candidaturas-espontaneas

  Ponto 02
  Página: https://bolsadeemprego.cm-camaradelobos.pt/detalhe-oferta?b2ZlcnRhX2lkPTQ0Njk0Nzg4NDk=

  Verificou-se que o botão “Envie para um amigo” apresenta contraste insuficiente entre o texto e o fundo no estado hover.

  No estado analisado, foi identificado um rácio de contraste de 1.23:1, abaixo do valor mínimo recomendado para conteúdo textual.

  Adicionalmente, o botão “Candidate-se” apresenta também contraste insuficiente entre o texto e o fundo, devido à combinação da cor de primeiro plano (#FFFFFF) com a cor de fundo (#EAAA26), dificultando a legibilidade do conteúdo textual, foi identificado um rácio de contraste de 2.04:1

  

  Figura 02 — Botão “Envie para um amigo” com contraste insuficiente no estado hover.

  

  Figura 03 — Botão “Candidate-se” com contraste insuficiente.

  Recomendações

  Recomenda-se a revisão do contraste dos seletores e restantes campos do formulário, garantindo níveis de contraste adequados entre o texto e o fundo para facilitar a leitura e identificação das opções disponíveis.

• evidência: issue #11 Elementos interativos sem diferenciação visual clara ou comportamento consistente de interação

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 5.4

  Evidências

  Ponto 01
  Página: https://bolsadeemprego.cm-camaradelobos.pt/detalhe-oferta?b2ZlcnRhX2lkPTQ0Njk0Nzg4NDk=

  Verificou-se que o botão “Envie para um amigo” não apresenta características visuais suficientemente claras que permitam identificá-lo imediatamente como elemento interativo.
  No estado analisado, o botão apresenta reduzida perceção visual de profundidade e aproxima-se visualmente de texto simples, tornando a sua interatividade apenas mais percetível no estado hover.

  Adicionalmente, o botão apresenta problemas de contraste no estado hover, dificultando a perceção visual do elemento (Ver issue R 5.4 - Conteúdo - Elementos interativos com contraste insuficiente relativamente ao fundo)

  

  Figura 01 — Botão “Envie para um amigo” com reduzida perceção de interatividade.

  Ponto 02
  Página: https://bolsadeemprego.cm-camaradelobos.pt/lista-candidaturas

  Verificou-se que os botões “Ver todas as candidaturas”, “Ver todas as ofertas” e “Limpar filtro” não apresentam características visuais suficientemente claras que permitam identificá-los imediatamente como elementos interativos.

  

  Figura 02 — Botões com reduzida perceção de interatividade.

  Outro exemplo:
  https://bolsadeemprego.cm-camaradelobos.pt/ofertas-de-emprego

  Recomendações

  Recomenda-se a utilização de elementos visuais consistentes que permitam identificar claramente ações interativas, garantindo que botões e hiperligações sejam facilmente percecionados como clicáveis pelos utilizadores.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #27 Existem campos do formulário que são ignorados quando se navega com o teclado

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

  Evidências

  Verifica-se que, ao utilizar a navegação por teclado (VO+Tab), a sequência de foco não percorre todos os campos do formulário, ignorando alguns campos obrigatórios.
  Como por exemplo no formulário "Submeter candidatura espontânea" a navegação por teclado não esta a passar pelo campo "Subcategoria". Esta situação compromete a ordem lógica de preenchimento e impede que todos os elementos necessários sejam alcançados.

  

  Outro exemplo é a Lista Candidaturas - Os campos “Categoria” e “Freguesia” não recebem foco por teclado.

  

  Oferta de emprego - Os mesmos campos, “Categoria” e “Freguesia”, também não são focáveis.

  

  URL:

  https://bolsadeemprego.cm-camaradelobos.pt/candidaturas-espontaneas (Campos: Freguesia e subcategoria)
  https://bolsadeemprego.cm-camaradelobos.pt/anunciar-oferta-de-emprego (Campos: Categoria, Freguesia e subcategoria)
  https://bolsadeemprego.cm-camaradelobos.pt/lista-candidaturas (Campos: Categoria e Freguesia)
  https://bolsadeemprego.cm-camaradelobos.pt/ofertas-de-emprego (Campos: Categoria e Freguesia)

  Recomendações

  • Recomenda-se assegurar que o campo visível pode ser alcançado pela navegação por teclado;
  • Recomenda-se privilegiar o uso de elementos HTML nativos e semânticos nos formulários. Quando forem usados componentes personalizados, estes devem reproduzir corretamente o comportamento do controlo original, incluindo foco, estado, nome acessível e navegação por teclado. Para componentes como campos de texto e listas suspensas, sugerimos a consulta da página Creating Accessible Forms da WebAIM, que apresenta boas práticas de acessibilidade.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #30 Existem formulários longos sem divisão por passos

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

  Evidências

  Verifica-se que existem formulários no website muito longos, nos quais é solicitada ao utilizador toda a informação de uma só vez.

  

  URL:
  https://bolsadeemprego.cm-camaradelobos.pt/candidaturas-espontaneas
  https://bolsadeemprego.cm-camaradelobos.pt/anunciar-oferta-de-emprego

  Recomendações

  • Recomendamos rever a estrutura dos formulários mais longos, de forma a segmentar os passos em várias páginas ou secções.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #31 Não foram encontrados formulários com mais de uma página

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

  Evidências

  Não foram encontrados formulários com mais de uma página dentro do website. Assim, este requisito é avaliado como "Não aplicável".

  Recomendações

  N/A

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #73 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 Candidaturas, os campos NIF/NIPC do interessado*”, “Email do interessado”, "Confirmação do email", "Telefone do candidato", "Nome do candidato" , 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.

  

  Figura 1 - Formulário da página .

  

  Figura 1 - Formulário da página .

  URLs a verificar:
  https://bolsadeemprego.cm-camaradelobos.pt/detalhe-candidatura?Y2FuZGlkYXR1cmFfaWQ9OTIzNzk0Mjc4Nw==
  https://bolsadeemprego.cm-camaradelobos.pt/detalhe-oferta?b2ZlcnRhX2lkPTQ0Njk0Nzg4NDk=

  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.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #32 Existem campos dependentes de outros campos que estão imediatamente visíveis mas estão inativos

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

  Evidências

  Verifica-se que o campo “Subcategoria” somente fica ativo após o preenchimento do campo Categoria, mas permanece exposto às tecnologias de apoio mesmo quando não existe qualquer categoria selecionada e o respetivo controlo se encontra desativado. Embora visualmente o campo apareça inativo, continua presente na navegação por leitor de ecrã, o que pode levar o utilizador a tentar interagir com um elemento que ainda não está disponível para preenchimento.

  

  URL:
  https://bolsadeemprego.cm-camaradelobos.pt/candidaturas-espontaneas

  Recomendações

  • No formulário deve-se esconder os campos dependentes do campo-chave sempre que este ainda não tenha sido ativado.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #75 O texto placeholder está a substituir o rótulo

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

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

  Evidências:

  Não deve ser usado o texto placeholder em substituição de uma label, porque ao escrever no campo esse texto irá desaparecer e torna a tarefa difícil para pessoas com problemas de memória ou na revisão das respostas do formulário. Para além disso, alguns leitores de ecrã podem não estar preparados para ler esse texto.
  Manter a label visível no ecrã, amplia-se a área de clique, o que pode beneficiar pessoas com dificuldades motoras ao selecionar um campo específico.

  No campo “Pesquisa Livre” da pesquisa da página de Ofertas de emprego, há apenas um texto placeholder associado ao campo e não existe qualquer legenda associada ao mesmo.

  

  Figura - Análise do campo "Pesquisa Livre", na página Ofertas de emprego, através do Google Inspector.

  Recomendações:

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

  • são atribuídas legendas aos campos utilizando o elemento <label>;
  • o texto placeholder, quando utilizado, auxilia no preenchimento do campo em vez de substituir a legenda;
  • caso seja usada a legenda dentro do campo, esta deve estar identificada como <label> e não deve desaparecer quando o campo está em foco, como acontece no exemplo do Campos de formulário - Material Design e/ou Caixa de seleção - Material Design

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

• evidência: issue #74 Caixas de combinação não estão estruturadas de forma acessível

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

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

  Evidências:

  Verificámos que, nas comboboxes presentes no website o leitor de ecrã não consegue aceder aos rótulos dos campos — quando o utilizador navega com Tab ou Shift+Tab — nem às opções disponíveis dentro de cada combobox. Quando o utilizador tenta navegar pelas opções, o leitor de ecrã anuncia apenas “blank”, em vez de ler cada opção disponível. Isto significa que estas caixas de combinação não estão estruturadas de forma acessível.

  

  Figura 1 - Análise do campo "Categoria", na página Ofertas de emprego, através do leitor de ecrã. Quando o utilizador tenta navegar pelas opções do campo, o leitor de ecrã anuncia apenas “blank”, em vez de ler cada opção disponível.

  URL's a verificar:

  • https://bolsadeemprego.cm-camaradelobos.pt/candidaturas-espontaneas
  • https://bolsadeemprego.cm-camaradelobos.pt/ofertas-de-emprego
  • https://bolsadeemprego.cm-camaradelobos.pt/anunciar-oferta-de-emprego
  • https://bolsadeemprego.cm-camaradelobos.pt/lista-candidaturas

  Recomendações:

  Recomendamos que estes componentes sejam reestruturados para garantir total compatibilidade com tecnologias de apoio.

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

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #28 Há campos obrigatórios que não estão identificados programaticamente

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

  Evidências

  Verificámos que, no formulário da página Oferta de emprego, os campos de seleção “Requer carta de condução?”, “Declaro sob compromisso de honra a veracidade de todas as declarações prestadas e assumo toda a responsabilidade consequente da sua inexatidão ou falsidade” e “Declaro que li e aceito a Política de Privacidade” não estão programaticamente definidos como obrigatórios.

  

  Figura 01 — Campos obrigatórios sem identificação programática.

  Na página Candidatura a oferta de emprego verificámos que alguns campos não estão programaticamente definidos como obrigatórios, nomeadamente:

  • Nome do candidato;
  • NIF do candidato;
  • Email do candidato;
  • Confirmação de email;
  • “Declaro sob compromisso de honra a veracidade de todas as declarações prestadas e assumo toda a responsabilidade consequente da sua inexatidão ou falsidade”;
  • “Declaro que li e aceito a Política de Privacidade”.

  

  Figura 03 — Validação de campos obrigatórios.

  Outros exemplos (NOK):

  Na página Candidaturas espontâneas e na página Detalhe da candidatura verificou-se que os seguintes campos não se encontram programaticamente definidos como obrigatórios:

  • Confirmação de email;
  • “Declaro sob compromisso de honra a veracidade de todas as declarações prestadas e assumo toda a responsabilidade consequente da sua inexatidão ou falsidade”;
  • “Declaro que li e aceito a Política de Privacidade”.

  Recomendações

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

• evidência: issue #10 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

  Evidência 01
  Página: https://bolsadeemprego.cm-camaradelobos.pt/detalhe-oferta?b2ZlcnRhX2lkPTQ0Njk0Nzg4NDk=

  Os campos obrigatórios do formulário encontram-se identificados através de asterisco (“*”).

  No entanto, não é apresentada qualquer indicação no formulário sobre o significado deste símbolo.

  

  Figura 01 — Campos obrigatórios identificados por “*” sem indicação do significado do símbolo.

  Outros exemplos:
  https://bolsadeemprego.cm-camaradelobos.pt/detalhe-candidatura?Y2FuZGlkYXR1cmFfaWQ9MzY1MjgwOTQxOQ==
  https://bolsadeemprego.cm-camaradelobos.pt/anunciar-oferta-de-emprego
  https://bolsadeemprego.cm-camaradelobos.pt/candidaturas-espontaneas
  https://bolsadeemprego.cm-camaradelobos.pt/detalhe-oferta?b2ZlcnRhX2lkPTQ0Njk0Nzg4NDk=

  Recomendações

  Recomenda-se a inclusão de uma indicação clara sobre o significado do símbolo “*” nos formulários, informando que este identifica campos de preenchimento obrigatório.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #12 Inexistência de ações longas

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

  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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #14 Feedback após submissão não acessível

  etiqueta: NOKetiqueta: chk transaçãoetiqueta: 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
  • A mensagem de sucesso/erro é apresentada apenas durante alguns segundos, sendo posteriormente removida com retorno automático à página do formulário, o que pode comprometer a sua perceção e leitura por alguns utilizadores

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

  

  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

  • https://bolsadeemprego.cm-camaradelobos.pt/candidaturas-espontaneas
  • https://bolsadeemprego.cm-camaradelobos.pt/anunciar-oferta-de-emprego

  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 as mensagens permanecem visíveis durante tempo suficiente ou até ação do utilizador, evitando desaparecimento automático prematuro
  • Validar com leitores de ecrã e navegação por teclado

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #56 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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #65 Existem campos sem mensagens de erro na sua vizinhança

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

  Evidências

  Os campos “NIF/NIPC” e “Id de candidatura / oferta”, presentes no formulário Alterar Dados, apresentam referências a mensagens de erro através do atributo aria-describedby, mas os respetivos elementos referenciados não existem no DOM.

  Contudo, não foram encontrados elementos com os identificadores fiscalid-error e referencia-error, impossibilitando que leitores de ecrã anunciem mensagens de erro associadas aos campos.

  Adicionalmente, as mensagens de erro existentes (ex.: “O NIF/NIPC indicado é inválido” e “O NIF/NIPC e o id de candidatura/oferta não correspondem.”) surgem separadas dos campos e sem associação programática aos mesmos.

  

  Figura 1- Campos com referências a mensagens de erro inexistentes ou não associadas programaticamente

  URL a verificar

  • https://bolsadeemprego.cm-camaradelobos.pt/alterar-dados

  Recomendações

  • Garantir que todas as mensagens de erro possuem um identificador único existente no DOM;
  • Associar programaticamente as mensagens de erro aos respetivos campos através de aria-describedby ou aria-errormessage;
  • Utilizar aria-invalid="true" quando o campo se encontra em estado inválido;
  • Garantir que as mensagens de erro são anunciadas corretamente por leitores de ecrã quando o foco navega pelos campos;
  • Validar o comportamento com navegação por teclado e tecnologias de apoio.

• evidência: issue #61 Existem mensagens não associadas programaticamente aos campos

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

  Evidências

  Foram identificados checkboxes obrigatório cuja mensagem de erro não está programaticamente associada ao campo interativo.

  No caso observado, a mensagem “Campo de preenchimento obrigatório.” existe visualmente, mas encontra-se associada a um campo oculto (input type="hidden") em vez do checkbox (veracid) com o qual o utilizador interage.

  Como consequência, leitores de ecrã podem não anunciar a mensagem de erro ao navegar para o checkbox, dificultando a identificação do problema por utilizadores de tecnologias de apoio.

  

  Figura 1 - Checkbox sem mensagem de erro programaticamente associada

  URL a verificar

  • https://bolsadeemprego.cm-camaradelobos.pt/anunciar-oferta-de-emprego
  • https://bolsadeemprego.cm-camaradelobos.pt/candidaturas-espontaneas
  • https://bolsadeemprego.cm-camaradelobos.pt/alterar-dados

  Recomendações

  • Associar a mensagem de erro diretamente ao checkbox através de aria-describedby.
  • Exemplo:

  <input type="checkbox"
         id="veracid"
         aria-describedby="veracid-error"
         aria-invalid="true">
  
  <span id="veracid-error" class="help-block">
      Campo de preenchimento obrigatório.
  </span>
  

  • Evitar associar mensagens de erro a campos ocultos (input type="hidden").
  • Validar com leitor de ecrã para confirmar que a mensagem é anunciada ao focar o checkbox.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #68 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 da página Anunciar Oferta de Emprego não ajuda no preenchimento do campo:

  

  Figura 1 - 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.

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

Lista de evidências recolhidas:

• evidência: issue #82 Outras violações - Existem páginas que apresentam quebras de layout

  etiqueta: outras violaçõesetiqueta: melhoria

  Verifica-se uma quebra de layout na apresentação das mensagens de erro do formulário. Como por exemplo na modal "Responder à candidatura" parte do texto de validação (“Campo de preenchimento obrigatório.”) não é corretamente acomodada na grelha da interface, ficando truncada e deslocada para a lateral direita da modal, fora do alinhamento esperado com os respetivos campos.

  

  URL:

  https://bolsadeemprego.cm-camaradelobos.pt/detalhe-candidatura?Y2FuZGlkYXR1cmFfaWQ9OTIzNzk0Mjc4Nw==

  Recomendações

  Recomenda-se rever a implementação do layout responsivo e das regras de posicionamento das mensagens de validação, garantindo que:

  • as mensagens de erro permanecem visualmente associadas ao respetivo campo;
  • o texto é apresentado integralmente, sem truncamento nem sobreposição;
  • o contentor do formulário acomoda corretamente o conteúdo dinâmico gerado após validação;
  • a grelha e os alinhamentos não se quebram quando são exibidas mensagens longas ou múltiplos erros em simultâneo.

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

  etiqueta: outras violaçõesetiqueta: melhoria

  Evidências

  Ao navegar pelo website utilizando 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 nos botões da sessão Emprego Online:

  

  URL:

  https://bolsadeemprego.cm-camaradelobos.pt/

  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

• evidência: issue #78 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.

• evidência: issue #69 Outras violações - Pesquisa sem mensagem de retorno quando não existem resultados.

  etiqueta: outras violaçõesetiqueta: melhoria

  Verifica-se que, quando a pesquisa não devolve resultados, não é apresentada qualquer mensagem de retorno ao utilizador que indique explicitamente a inexistência de correspondências para os critérios introduzidos. Na ausência dessa informação, o utilizador pode interpretar o comportamento da página como falha de carregamento, erro de funcionamento ou ausência de atualização do conteúdo.

  

  URL:

  https://bolsadeemprego.cm-camaradelobos.pt/ofertas-de-emprego

  Recomenda-se apresentar uma mensagem de retorno clara, visível e imediata sempre que a pesquisa não produza resultados, informando explicitamente o utilizador desse estado.

• evidência: issue #58 Outras violações - Botão submeter não fica imediatamente visível ao aceder a modal.

  etiqueta: outras violaçõesetiqueta: melhoria

  Verificado que ao abrir a modal “Candidate-se”, o botão “Submeter” não fica imediatamente visível, surgindo apenas após deslocação do scroll no interior da própria modal.

  

  URL:

  https://bolsadeemprego.cm-camaradelobos.pt/detalhe-oferta?b2ZlcnRhX2lkPTQ0Njk0Nzg4NDk=
  https://bolsadeemprego.cm-camaradelobos.pt/detalhe-candidatura?Y2FuZGlkYXR1cmFfaWQ9OTQxOTEyOTI3Ng==

  Recomendações

  Recomenda-se rever a implementação da modal, garantindo que o botão “Submeter” fique contido no interior do contentor visível do diálogo e integrado na mesma área de scroll do restante formulário.