Relatório Avaliação de Candidatura
Provedoria de Justiça

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #60 Menu mobile com problemas semânticos e de gestão de foco

  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

  Evidências:

  Na versão mobile do website da Provedoria de Justiça, foram identificados problemas de implementação que afetam a utilização do menu através de teclado e tecnologias de apoio.

  Os controlos utilizados para abrir e fechar o menu foram implementados através de elementos genéricos , apesar de representarem ações interativas. Estes elementos não transmitem nativamente a sua função às tecnologias de apoio e dependem de comportamentos adicionais para simular a interatividade esperada.

  Adicionalmente, o botão do menu possui um nome acessível em inglês ("Open - Mobile menu" e "Close - Mobile menu"), enquanto o restante conteúdo do website se encontra em português, criando uma inconsistência linguística para utilizadores de leitores de ecrã.

  Foi também verificado que, após a abertura do menu mobile, a navegação não é corretamente gerida como uma janela modal. Embora visualmente o menu cubra toda a página, o foco continua a ser movido para elementos localizados por trás do menu, impedindo o acesso consistente às opções de primeiro e segundo nível e comprometendo a navegação por teclado e por tecnologias de apoio.

  

  Imagem do botão do menu como <span> em vez de botão e texto alternativo em inglês

  

  Foco a navegar em elementos da página por trás do menu aberto.

  URLs a verificar:
  https://www.provedor-jus.pt/ - menu principal na versão mobile

  Recomendações:

  • Substituir os elementos utilizados como controlos de interface por elementos semânticos .
  • Garantir que o estado de abertura e fecho do menu é comunicado através do atributo aria-expanded.
  • Definir nomes acessíveis no idioma da página, utilizando designações como "Abrir menu" e "Fechar menu".
  • Considerar a apresentação de texto visível "Menu" junto ao ícone do botão.
  • Implementar o menu mobile de acordo com os requisitos de acessibilidade aplicáveis a janelas modais, garantindo que:

  1. O foco é movido para o interior do menu quando este é aberto (Requisito 9.1).
  2. O foco permanece limitado ao conteúdo do menu enquanto este estiver aberto (Requisito 9.2).
  3. Existe um mecanismo acessível para fechar o menu, incluindo suporte para a tecla Esc (Requisito 9.3).
  4. Ao fechar o menu, o foco regressa ao elemento que o abriu (Requisito 9.4).

  • Garantir que os utilizadores de teclado e leitores de ecrã conseguem navegar corretamente por todas as opções de primeiro e segundo nível do menu.

• evidência: issue #58 Não é possível navegar para a opção seguinte do menu sem percorrer as subopções

  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

  Evidências:

  Quando navegamos com o leitor de ecrã e teclado as opções do menu abrem automaticamente quando estão com foco, forçando o utilizador a navegar por todas as subopções antes de encontrar a opção desejada:

  

  Imagem do utilizador navegando apenas com o teclado tendo que navegar por todas as subopções.

  URLs a verificar:

  • https://www.provedor-jus.pt/

  Recomendações:
  As opções do menu devem abrir ou fechar de acordo com a ação do utilizador. Para isso, é necessário utilizar um script que gerencie o estado do menu em conjunto com o atributo aria-expanded.

• evidência: issue #57 Os menus de navegação não estão estruturados como uma navegação de forma apropriada

  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

  Evidências:

  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:

  

  Menu principal sem a tag nav

  

  Menu secundário sem a tag nav

  Adicionalmente o menu principal na versão mobile, apesar de estar apropriadamente estruturado como uma navegação, o botão "Menu" está fora da landmark nav.

  

  Imagem do botão "Menu" da versão mobile fora da landmark nav.

  URLs a verificar:

  • https://www.provedor-jus.pt/ - menus de navegação

  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.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #62 Texto alternativo do menu mobile apresentado em idioma diferente do conteúdo da página

  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

  Evidências:

  Na versão mobile, o botão do menu hambúrguer apresenta textos alternativos em inglês, nomeadamente "Open - Mobile menu" para abrir o menu e "Close - Mobile menu" para o fechar.

  Uma vez que o conteúdo do website se encontra em português, a utilização de textos alternativos noutro idioma pode dificultar a compreensão por parte dos utilizadores de leitores de ecrã, especialmente quando estes não dominam a língua inglesa.

  

  Imagem do menu principal versão mobile com textos alternativos em inglês.

  URLs a verificar:

  • https://www.provedor-jus.pt/ - menu principal versão mobile

  Recomendações:

  • Garantir que os textos alternativos e nomes acessíveis dos componentes estão no mesmo idioma do conteúdo principal da página.
  • Substituir os textos atuais por descrições equivalentes em português, como por exemplo "Abrir menu" e "Fechar menu".

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #34 Saltos na hierarquia de cabeçalhos

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 2.2

  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 página "A quem mais pode dirigir uma queixa" do website foram identificados saltos na hierarquia de cabeçalhos.

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

  

  Figura 1 - Estrutura de cabeçalhos da página .

  URLs a verificar:

  https://www.provedor-jus.pt/quem-somos/perguntas-frequentes/a-quem-mais-pode-dirigir-uma-queixa/

  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.

etiqueta: N/A

Lista de evidências recolhidas:

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

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

  As células que constituem os cabeçalhos da tabela estão marcadas com o elemento <th>.
  – ver requisito 3.1 na lista 10 aspetos

  Evidências:

  Não foram encontradas tabelas no website, por isso este requisito é considerado não aplicável.

  Recomendações:

  Nada a acrescentar.

etiqueta: N/A

Lista de evidências recolhidas:

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

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

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

  Evidências:

  Não foram encontradas tabelas no website, por isso este requisito é considerado não aplicável.

  Recomendações:

  Nada a acrescentar.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #29 Campo de pesquisa com ausência de etiqueta acessível e dependência de placeholder

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.1

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

  Evidencias:

  No código analisado referente ao campo de pesquisa do cabeçalho, verifica-se a ausência de um elemento <label> associado ao campo de pesquisa através de for e id.

  O campo apresenta apenas os seguintes mecanismos de identificação:

  • placeholder="Procurar", utilizado como principal elemento identificador visual
  • Ausência de associação programática entre uma etiqueta e o input

  Adicionalmente, o placeholder não constitui uma etiqueta acessível, uma vez que desaparece durante a interação do utilizador, deixando de fornecer contexto funcional sobre o campo de pesquisa.

  

  Figura 1 - Campo de pesquisa no cabeçalho sem etiqueta acessível associada

  URLs a verificar:

  • https://www.provedor-jus.pt/ (Em todo o website)

  Recomendações:
  Recomenda-se garantir que o campo de pesquisa possui um nome acessível corretamente definido, através da seguinte abordagem:

  • Implementação de um elemento <label> associado ao input através de for e id

  Adicionalmente, recomenda-se:

  • Evitar utilizar o placeholder como substituto de etiqueta, sendo este apenas um elemento de apoio ao preenchimento
  • Garantir que o campo mantém sempre um nome acessível persistente, independentemente do estado de interação
  • Assegurar consistência entre identificação visual e programática do controlo

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #55 Campo de aceitação de política sem indicação de obrigatoriedade

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.2

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

  Evidências:

  Foi identificado um campo de checkbox relativo à aceitação da Política de Privacidade e Segurança.

  O campo não apresenta qualquer indicação explícita de obrigatoriedade, nem através de texto associado ao rótulo, nem através de atributos como required ou aria-required.

  Como consequência, o utilizador não é informado previamente de que a aceitação da política pode ser um requisito obrigatório para submissão do formulário, podendo apenas detetar essa condição após tentativa de submissão.

  

  Figura 1 - Checkbox de aceitação da política de privacidade sem indicação de obrigatoriedade

  URLs a verificar:

  • https://www.provedor-jus.pt/

  Recomendações:

  • Utilizar o atributo required no campo de checkbox quando a aceitação for obrigatória;
  • Indicar claramente no rótulo que a aceitação da política é obrigatória (ex.: “obrigatório”);
  • Garantir que a obrigatoriedade é comunicada também a leitores de ecrã;
  • Evitar depender apenas de validação após submissão para comunicar requisitos do formulário;
  • Opcionalmente, reforçar a obrigatoriedade no contexto do grupo de campos do formulário.

• evidência: issue #33 Obrigatoriedade de contacto não identificada antes do preenchimento

  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:

  Foi identificado um conjunto de campos de contacto onde a regra “pelo menos um contacto” é apresentada no formulário.

  No entanto, esta instrução encontra-se posicionada no final do formulário, após os campos de preenchimento, reduzindo a sua perceção prévia por parte do utilizador.

  Adicionalmente, a mensagem de erro apresentada após submissão (“+ Pelo menos um contacto”) reforça a obrigatoriedade apenas nesse momento, sem que a regra esteja adequadamente destacada junto ao início da secção de contacto.

  Como consequência, os utilizadores podem não compreender atempadamente que é necessário preencher pelo menos um dos campos de contacto, especialmente quando utilizam tecnologias de apoio ou navegação sequencial.

  

  Figura 1 - Mensagem de obrigatoriedade apresentada apenas após submissão do formulário

  URLs a verificar:

  • https://servicos.provedor-jus.pt:7777/queixas/Step1.aspx

  Recomendações:

  • Posicionar a instrução “pelo menos um contacto é obrigatório” junto ao início da secção de contacto;
  • Garantir que a instrução está associada semanticamente ao grupo de campos;
  • Evitar que a mensagem de erro seja o primeiro ponto de contacto claro com a regra de validação;
  • Garantir consistência entre instrução inicial e mensagem de validação;
  • Assegurar que a informação é facilmente percetível por leitores de ecrã antes da interação com o formulário.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #41 Existem campos cujos erros são comunicados apenas através da cor

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.3

  É 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:
  O erro de preenchimento incorreto do campo de concordância com a política de privacidade do formulário de subscrição de newsletter é comunicado através de um contorno em cor vermelha.

  

  Erro comunicado apenas através da cor
  O preenchimento parcial do campo email do mesmo formulário provoca um erro que é comunicado às tecnologias de apoio quando se foca esse campo e que indica que o email é inválido, mas essa mensagem não é apresentada no ecrã. Acresce que, se esse campo não for preenchido, nenhum erro é comunicado às tecnologias de apoio.

  

  URLs a verificar:
  https://www.provedor-jus.pt/

  Recomendações:
  Recomendamos a introdução de mensagens de erro na vizinhança de cada campo de todos os formulários, que devem estar visíveis para todos os utilizadores e tecnologias, de modo a comunicar as situações de erro também por via textual, permitindo assim a perceção dos erros também pelos utilizadores com limitações ao nível da visão.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #8 Imagens não decorativas com texto alternativo insuficiente ou incorreto

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.1

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

  Evidências:

  Verifica-se que as imagens dos logótipos no rodapé da página incluem a palavra “logo” no texto alternativo. O texto alternativo deve identificar de forma clara a entidade representada, sem incluir termos como “logo” ou “logótipo”, uma vez que as tecnologias de apoio já anunciam o elemento como imagem. Neste caso, o texto alternativo deve limitar-se à identificação da entidade, por exemplo: alt="MAC 2014-2020". Recomenda-se ainda a remoção do atributo title.

  

  URLs a verificar:
  https://www.provedor-jus.pt/

  Recomendações:

  • Imagens não decorativas devem possuir uma descrição breve associada, por exemplo através do atributo alt, que identifique de forma clara a finalidade da imagem no contexto da página.
  • Remover o atributo title.

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

  etiqueta: melhoriaetiqueta: chk 10 webetiqueta: R 5.1

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

  Evidências:
  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="" e removendo atributos redundantes, como title, quando existentes.

  

  Verifica-se que, nos links “MNP — Mecanismo Nacional de Prevenção da Tortura” e “INDH — Instituição Nacional de Direitos Humanos”, os logótipos e imagens apresentados junto ao texto do link têm função meramente ilustrativa, uma vez que a finalidade do link já é comunicada pelo texto visível.

  O mesmo se aplica à imagem do gráfico “Temas das queixas instruídas”, apresentada como apoio visual ao conteúdo já identificado na página.

  

  URLs a verificar:

  • https://www.provedor-jus.pt/
  • https://www.provedor-jus.pt/podcast/os-direitos-sao-conversa-um-podcast-da-provedoria-de-justica/
  • https://www.provedor-jus.pt/quem-somos/historia/anteriores-provedores/galeria-de-retratos-a-oleo-dos-anteriores-provedores-de-justica/
  • https://www.provedor-jus.pt/documentos/recomendacao-apos-inspecoes-as-spe-da-seguranca-social-4-a-2020/

  Recomendações:
  Recomenda-se que as imagens decorativas tenham o atributo alt="". Quando a imagem possuir o atributo title, este deve ser removido para evitar redundância ou duplicação da informação anunciada pelas tecnologias de apoio.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #10 Imagem-link com texto alternativo incorreto

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.3

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

  Evidências:

  Verifica-se que a imagem do logótipo, utilizada como link para a página inicial, apresenta um texto alternativo que não descrevendo adequadamente o seu propósito (acesso à página inicial). Por exemplo: alt= "Provedor de Justiça - página inicial".

  

  ---

  Verifica-se que as imagens-link associadas às plataformas de áudio/redes sociais não possuem um nome acessível que descreva claramente a finalidade do link. Na estrutura analisada, os links são compostos por ícones em SVG e, ao serem percorridos por tecnologias de apoio, é apresentada informação técnica ou pouco significativa, em vez de uma descrição compreensível da ação ou destino do link. Por exemplo: aria-label="Youtube".

  

  ---

  Verifica-se que os links de partilha nas redes sociais são apresentados apenas através de imagens inseridas por CSS. Quando os estilos são desativados, a imagem desaparece, deixando de ser possível perceber a finalidade do link apenas com base no conteúdo disponível no código.

  

  ---

  Verifica-se que a imagem-link “O Futuro dos Direitos é Agora” não possui um nome acessível que descreva claramente a finalidade do link, uma vez que a imagem apresenta o atributo alt vazio (alt=""). Assim, o propósito do link não é comunicado aos utilizadores de tecnologias de apoio. Por exemplo: alt="Aceder a O Futuro dos Direitos é Agora, abre numa nova janela".

  Verifica-se ainda que o link abre numa nova janela ou separador, através do atributo target="_blank", mas essa informação não é comunicada explicitamente ao utilizador. Esta ausência de aviso pode causar desorientação, especialmente para pessoas que utilizam leitores de ecrã ou navegação por teclado.

  

  ---

  Verifica-se que a imagem-link utilizada para fechar a pesquisa na janela modal de pesquisa, depende do atributo title para fornecer o seu nome acessível. Recomenda-se que o nome acessível seja definido através de aria-label no elemento interativo, removendo o atributo title para evitar comportamentos inconsistentes entre tecnologias de apoio.

  

  O mesmo ocorre com o botão voltar ao topo:

  

  URLs a verificar:

  • https://www.provedor-jus.pt/
  • https://www.provedor-jus.pt/podcast/os-direitos-sao-conversa-um-podcast-da-provedoria-de-justica/
  • https://www.provedor-jus.pt/a-provedora-de-justica-promove-o-seminario-transnacional-rede-de-ombudsman-construir-em-conjunto-uma-administracao-mais-eficaz-responsavel-transparente-e-etica/
  • https://www.provedor-jus.pt/documentos/o-futuro-dos-direitos-e-agora/

  Recomendações:

  • O texto alternativo deve transmitir claramente o destino ou finalidade do link.
  • Recomenda-se que sempre que o link abre numa nova janela ou separador, essa informação seja comunicada ao utilizador no próprio nome acessível do link ou através de texto complementar associado.
  • Recomenda-se que, sempre que uma imagem ou ícone seja inserido exclusivamente via CSS (como é o caso dos links de partilha), seja incluído um texto em HTML, por exemplo através do elemento <span>, garantindo que a função do componente permanece disponível para tecnologias de apoio. Esse texto pode ficar visualmente oculto, mas deve continuar acessível a leitores de ecrã. Para mais informações: https://www.acessibilidade.gov.pt/tutorial/css-em-accao-conteudo-invisivel-apenas-para-utilizadores-de-leitor-de-ecra/#page1_topic_7

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

Lista de evidências recolhidas:

• evidência: issue #65 O texto normal não tem contraste suficiente em certos estados

  etiqueta: melhoriaetiqueta: chk 10 webetiqueta: R 6.1

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

  Evidências

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

  A avaliação com a ferramenta Colour Contrast Analyser revela problemas relacionados com insuficiência de contraste, afetando diretamente a legibilidade.

  O website apresenta problemas de contraste nos estados de hover de hiperligações, por exemplo no rodapé com a combinação de cores #880000(cor de primeiro plano) e #424242(cor de plano de fundo) que torna os textos pouco visíveis. (Figura 1)

  

  Figura 1- Texto normal nos estados de hover com problemas de contraste no rodapé, com uma taxa de apenas 1:1

  Além disso, existem imagens complexas com conteúdos informativos e textuais que apresentam problemas de contraste. Por exemplo na página, Relatório 2024 do Provedor da Justiça com o gráfico sobre "Temas das queixas instruídas em 2024" (Figura 2)

  

  Figura 2- Imagens que possuem texto normal com problemas de contraste, com uma taxa de apenas 2,8:1

  Esta implementação dificulta a perceção, compromete a leitura e interpretação da informação, especialmente para utilizadores com baixa visão.

  URLs a verificar

  • https://www.provedor-jus.pt/ (Rodapé de todo website)
  • https://www.provedor-jus.pt/mnp-apresenta-relatorio-tematico-sobre-criancas-e-jovens-em-acolhimento-especializado/ (Rodapé nas páginas interiores)

  Recomendações
  Recomendamos a revisão das combinações de cores das páginas de todo website para garantir os valores mínimos de contraste do texto normal. Garantir consistência nos estados visuais (normal, hover, foco) com contraste adequado;

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #66 O texto grande não tem contraste suficiente

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 6.2

  O rácio de contraste entre a cor do texto de tamanho grande (maior ou igual que 18 pontos ou maior ou igual que 14 pontos negrito) e a cor do fundo é superior a 3:1.
  – ver requisito 6.2 na lista 10 aspetos

  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.

  A avaliação com a ferramenta Colour Contrast Analyser revela problemas relacionados com insuficiência de contraste, afetando diretamente a legibilidade.

  No website, o texto grande do placeholder do formulário de pesquisa não passa na avaliação de contraste, pois utilizam a combinação de cores #D1CFCF(cor de primeiro plano) #FEFEFE(cor de plano de fundo). (Figura 1)

  

  Figura 1 - Título grande com 28px no formulário de pesquisa apresenta problemas de contraste

  URLs a verificar

  • https://www.provedor-jus.pt/newsletter/
  • https://www.provedor-jus.pt/ (Componente disponível em todo website)

  Recomendações
  Recomendamos a revisão das combinações de cores das páginas para garantir os valores mínimos de contraste do texto grande. Garantir consistência nos estados visuais (normal, hover, foco) com contraste adequado;

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #37 Não foi possível ativar os botões de controlo do leitor com o teclado

  etiqueta: chk 10 webetiqueta: NOKetiqueta: 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 foi possível navegar até aos controlos do vídeo e iniciar a reprodução utilizando apenas o teclado.

  

  Figura 1 - Evidência de que não foi possível iniciar a reprodução do vídeo utilizando o teclado .

  URLs a verificar:

  https://www.provedor-jus.pt/

  Recomendações:

  • Garantir que todos os controlos do leitor multimédia podem ser alcançados e ativados através do teclado.
  • Assegurar que é possível iniciar, pausar, retomar e controlar a reprodução do conteúdo sem recorrer ao rato.
  • Verificar a correta gestão do foco de teclado nos controlos do leitor multimédia.
  • Testar o funcionamento do leitor utilizando apenas o teclado, garantindo a sua compatibilidade com tecnologias de apoio.
  • Utilizar um leitor multimédia acessível que disponibilize controlos operáveis tanto por rato como por teclado.

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  Evidências

  No bloco de listagem da equipa são identificados múltiplos elementos clicáveis com o mesmo destino dentro do mesmo componente de conteúdo.

  Em cada item da listagem existe duplicação de links para a mesma página de detalhe:

  • Um elemento <a> envolvido na imagem do elemento (<img> + overlay/icon)
  • Um elemento <a> associado ao nome do membro da equipa (título)

  Ambos os elementos apontam para o mesmo URL, resultando em redundância de navegação e aumento de elementos interativos desnecessários.

  

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

  URLs a verificar

  • https://www.provedor-jus.pt/quem-somos/a-provedoria-2/a-equipa/

  Recomendações

  • Evitar duplicação de links para o mesmo destino dentro do mesmo bloco de conteúdo
  • Manter apenas um elemento clicável principal por item (preferencialmente o título ou o cartão completo como único link)
  • Remover o link associado à imagem ou garantir que a imagem não funciona como elemento interativo independente
  • Se a imagem for decorativa, garantir que não é clicável nem focável
  • Garantir consistência na estrutura de navegação e redução de redundância de elementos interativos

• evidência: issue #61 Controlos interativos implementados com elementos não semânticos

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  Evidências:

  No componente de modal (newsletter) é utilizado um elemento genérico <div> com um <span> interno para representar o controlo de fecho da janela.

  Este elemento é utilizado como controlo de interação (fechar a modal), mas não possui semântica nativa de elemento interativo.

  <div class="block-lightbox-close">
      <span></span>
  </div>
  

  Não é utilizado um elemento semântico apropriado como <button>, o que faz com que a função do controlo não seja corretamente exposta de forma nativa às tecnologias de apoio.

  

  Figura 1 - Controlo de fecho da modal implementado com elemento não semântico

  Adicionalmente, foi identificado o mesmo padrão no botão de abertura do menu principal em versão mobile, implementado através de um elemento utilizado para executar uma ação de interface (abrir menu), quando semanticamente deveria ser utilizado um .

  <div class="sc_layouts_iconed_text sc_layouts_menu_mobile_button">
      <a href="#" class="sc_layouts_item_link sc_layouts_iconed_text_link">
          <span class="sc_layouts_item_icon trx_addons_icon-menu"></span>
      </a>
  </div>
  

  

  Figura 2 - Botão do menu mobile implementado com elemento não semântico

  URLs a verificar:

  • https://www.provedor-jus.pt/ (modal de newsletter)
  • https://www.provedor-jus.pt/ (menu principal versão mobile)

  Recomendações:

  • Substituir o <div> por um elemento semântico <button> para o controlo de fecho da modal
  • Garantir que o botão mantém toda a funcionalidade existente (fecho da modal)
  • Assegurar comportamento acessível por teclado (Enter e Espaço)
  • Garantir foco visível e navegável
  • Evitar uso de elementos genéricos para ações interativas
  • Validar com leitores de ecrã para garantir que a função de fecho é corretamente anunciada

• evidência: issue #53 Modal sem semântica e sem nome acessível

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  Evidências:

  Foi identificado um componente de modal (pesquisa) implementado apenas com elementos genéricos (div), sem qualquer semântica de diálogo associada.

  Não existe utilização de role="dialog" nem aria-modal="true", nem qualquer nome acessível programaticamente determinável (ex.: aria-label ou aria-labelledby).

  Como consequência, quando o componente é aberto, não é possível identificar corretamente a sua função ou contexto através de tecnologias de apoio, sendo apresentado apenas como conteúdo genérico.

  

  Figura 1 - Modal de pesquisa sem semântica de diálogo e sem nome acessível

  Adicionalmente, foi identificado outro componente de modal (newsletter) que apresenta a mesma problemática:

  <div id="block-lightbox-newsletter" class="show">

  A estrutura da modal é composta apenas por elementos genéricos (div), sem semântica de diálogo e sem nome acessível programático.

  

  Figura 2 - Modal de newsletter sem semântica de diálogo e sem nome acessível

  URLs a verificar:

  • https://www.provedor-jus.pt/ (Em todo o website)

  Recomendações:

  • Definir semântica de diálogo para o componente (ex.: role="dialog");
  • Indicar o estado modal através de aria-modal="true";
  • Garantir nome acessível do modal através de aria-label ou aria-labelledby;
  • Aplicar estes requisitos de forma consistente em todas as modais do website;
  • Validar com leitores de ecrã para assegurar identificação correta do contexto.

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

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  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.

  URLs a verificar:

  • https://www.provedor-jus.pt/
  • https://www.provedor-jus.pt/noticias/
  • https://www.provedor-jus.pt/quem-somos/a-provedoria-2/a-equipa/
  • (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.

etiqueta: NOK

Lista de evidências recolhidas:

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

  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:
  Verifica-se que ao aceder ao website, é apresentada a modal da newsletter, mas o foco não é encaminhado para o primeiro elemento interativo no seu interior, nomeadamente o botão “Fechar”. Em vez disso, o foco permanece na página subjacente, fazendo com que a janela modal só seja alcançável por tecnologias de apoio após a navegação por todo o conteúdo da página.

  

  URLs a verificar:
  https://www.provedor-jus.pt/

  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 #4 O foco não fica limitado a caixa de diálogo

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.2

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

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

  

  URLs a verificar:
  https://www.provedor-jus.pt/

  Recomendações:

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #5 Não é possível fechar a caixa de diálogo com tecnologias de apoio

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.3

  A caixa de diálogo tem de ter um mecanismo que permita sair ou fechar a caixa, quer através de teclado quer através de um dispositivo apontador
  – ver requisito 9.3 na lista 10 aspetos

  Evidências:
  Verifica‑se que a caixa de diálogo não pode ser encerrada através da tecla ESC e o botão fechar não é alcançado por tecnologias de apoio (teclado, leitor de ecrã).

  

  URLs a verificar:
  https://www.provedor-jus.pt/

  Recomendações:

  • Idealmente podem implementar um mecanismo que permita o encerramento das janelas modais através da tecla ESC.
  • Recomenda-se que o botão “Fechar” esteja acessível às tecnologias de apoio, permitindo ao utilizador encerrar a janela modal de forma simples, autónoma e previsível.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #18 Falta de resumo na página inicial do website

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 1.1

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

  Evidências:

  Na página principal do website da Provedoria de Justiça, não aparece presente um resumo breve do próposito do site.

  

  Imagem da página principal sem fazer scroll

  URLs a verificar:

  • https://www.provedor-jus.pt/

  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 #30 Falta de glossário para termos complexos

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 1.2

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

  Evidências:

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

  

  Imagem com o termo complexo "CPLP" sem a definição agregada. Disponível em: https://www.provedor-jus.pt/relacoes-internacionais/atividade-internacional/

  

  Imagem com diversos termos complexos sem definição agregada. Disponível em: https://www.provedor-jus.pt/instituicao-nacional-de-direitos-humanos/monitorizacao-das-obrigacoes-internacionais/relatorios-alternativos-e-outras-contribuicoes/processo-de-acreditacao/

  URLs a verificar:

  • https://www.provedor-jus.pt/instituicao-nacional-de-direitos-humanos/relatorios-e-estudos/relatorios-e-estudos-tematicos/ - MNP e PAE
  • https://www.provedor-jus.pt/instituicao-nacional-de-direitos-humanos/o-provedor-de-justica-enquanto-indh/ - INDH
  • https://www.provedor-jus.pt/instituicao-nacional-de-direitos-humanos/o-provedor-de-justica-enquanto-indh/ - GANHRI, ENNHRI e INDH no menu secundário
  • https://www.provedor-jus.pt/mecanismo-nacional-de-prevencao/o-provedor-de-justica-enquanto-mnp/ - MNP na página e no menu secundário
  • https://www.provedor-jus.pt/a-provedora-de-justica-promove-o-seminario-transnacional-rede-de-ombudsman-construir-em-conjunto-uma-administracao-mais-eficaz-responsavel-transparente-e-etica/ - MAC

  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 #20 Falta de datas de atualização em blocos de conteúdo

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 1.3

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

  Evidências:

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

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

  

  Imagem da página dos contactos sem uma data de atualização. Disponível em: https://www.provedor-jus.pt/quem-somos/contactos/

  URLs a verificar:

  • https://www.provedor-jus.pt/quem-somos/contactos/
  • https://www.provedor-jus.pt/quem-somos/perguntas-frequentes/submeter-queixa/
  • https://www.provedor-jus.pt/relacoes-internacionais/rede-europeia-de-provedores-de-justica-eno/
  • https://www.provedor-jus.pt/relacoes-internacionais/instituto-internacional-de-ombudsman/
  • https://www.provedor-jus.pt/recomendacoes-e-outras-decisoes/fiscalizacao-da-constitucionalidade/
  • entre outros

  Recomendações:

  • Incluir a data de publicação e/ou última atualização em todos os conteúdos relevantes;
  • Garantir que essa informação está semanticamente estruturada;
  • Assegurar consistência na apresentação das datas em todo o site.

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 2.1

  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:

  Verificámos que os botões "Saber Mais", "Mais Notícias","Apresentar uma queixa", "Subescrever" e "Consultar" apresentados no banner da página inicial e em outras secções da página inicial do website Provedor de Justiça utiliza um tamanho de letra inferior ao mínimo recomendado de 12 pontos para conteúdos textuais.

  Esta situação pode dificultar a leitura do texto apresentado. (Figura 01)

  

  Figura 01 — Botão "Saber Mais" apresenta tamanho de letra inferior ao mínimo recomendado.

  Verificámos que várias opções do menu principal do website Provedor de Justiça, nomeadamente "Provedor de Justiça", "Quem Somos", "Atividade", "Recomendações e Outras Decisões", "Relações Internacionais", "Apresentar Queixa" e "PT", apresentam um tamanho de letra de 13px, valor inferior ao mínimo recomendado para assegurar uma leitura confortável. (Figura 02)

  

  Figura 02— Elemento do menu principal apresenta tamanho de letra inferior ao mínimo recomendado.

  Adicionalmente, no controlo de seleção de idioma (PT e EN) disponibilizado no menu principal do website, identificámos um tamanho de letra de 11px no elemento "EN", valor inferior ao mínimo recomendado. (Figura 03)

  

  Figura 03 — Elementos do menu principal apresentam tamanhos de letra inferiores ao mínimo recomendado.

  Verificámos que o botão "Pesquisa avançada", disponibilizado na página Pesquisa de documentos, utiliza um tamanho de letra de 11px, valor inferior ao mínimo recomendado de 12 pontos para conteúdos textuais. Esta situação pode dificultar a leitura e identificação da ação disponível. (Figura 04)

  

  Figura 04— Botão "Pesquisa avançada" apresenta tamanho de letra inferior ao mínimo recomendado.

  Verificámos que os elementos do breadcrumb disponibilizados no website, como por exemplo o elemento "Início" identificado na página Resultado da pesquisa, utilizam um tamanho de letra de 13px, valor inferior ao mínimo recomendado de 12 pontos. (Figura 05)

  

  Figura 05 — Breadcrumb apresenta tamanho de letra inferior ao mínimo recomendado, dificultando a leitura do percurso de navegação.

  URLs a verificar:

  • https://www.provedor-jus.pt/
  • https://www.provedor-jus.pt/pesquisa-documentos/?categoria%5B0%5D=fiscalizacao-constitucional
  • https://www.provedor-jus.pt/pesquisa-documentos/?categoria%5B0%5D=fiscalizacao-constitucional

  Recomendações:

  Recomenda-se o aumento do tamanho de letra aplicado aos elementos identificados, garantindo uma dimensão mínima equivalente a 12 pontos para conteúdos informativos e elementos de navegação.

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

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 2.1

  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:

  Verificámos que, na página A Equipa, alguns elementos textuais apresentam uma redução significativa do tamanho da letra em dispositivos móveis.

  Foi identificado, por exemplo, o texto associado ao cargo dos membros da equipa com um tamanho de letra de 10px, valor inferior ao mínimo recomendado para uma leitura confortável. Esta situação pode dificultar a perceção e leitura da informação apresentada em ecrãs de menor dimensão. (Figura 01)

  

  Figura 01 — Texto associado ao cargo dos membros da equipa apresenta tamanho de letra reduzido em dispositivo móvel.

  Urls a verificar:

  • https://www.provedor-jus.pt/quem-somos/a-provedoria-2/a-equipa/
  • https://www.provedor-jus.pt/pesquisa-documentos/?categoria%5B0%5D=fiscalizacao-constitucional

  Recomendações:

  Recomenda-se assegurar que os elementos textuais mantêm um tamanho de letra adequado em diferentes resoluções, garantindo níveis consistentes de legibilidade e conforto de leitura, incluindo em dispositivos móveis.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #43 A informação secundária tem um tamanho de letra inferior a 10pt (equivalente a 13px)

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 2.2

  A informação secundária (datas, autores) utiliza, no mínimo, um tamanho de letra de 10 pontos.
  – ver requisito 2.2 na lista Conteúdo

  Evidencias:

  Verificámos que na página inicial do website Provedor de Justiça a data de publicação apresentada na secção de destaques da página inicial do website utiliza um tamanho de letra de 11px, valor inferior ao mínimo recomendado de 10 pontos para informação secundária.

  Esta situação pode dificultar a leitura e identificação da informação de contexto. (Figura 01)

  

  Figura 01 — Data de publicação apresenta tamanho de letra inferior ao mínimo recomendado.

  Verificámos que a data de publicação apresentada na página MNP apresenta relatório sobre crianças e jovens em acolhiment utiliza um tamanho de letra de 11px, valor inferior ao mínimo recomendado de 10 pontos para informação secundária. Esta situação pode dificultar a leitura e identificação da informação de contexto. (Figura 02)

  

  Figura 02 — Data de publicação apresenta tamanho de letra inferior ao mínimo recomendado.

  Verificámos que, na página A Equipa, a identificação dos cargos associados aos membros da equipa apresenta um tamanho de letra de 11px, valor inferior ao mínimo recomendado para informação secundária. Esta situação foi identificada, por exemplo, no texto "PROVEDORA-ADJUNTA". (Figura 03)

  

  Figura 03 — Identificação do cargo apresenta tamanho de letra inferior ao mínimo recomendado para informação secundária.

  URLs a verificar:

  • https://www.provedor-jus.pt/
  • https://www.provedor-jus.pt/mnp-apresenta-relatorio-tematico-sobre-criancas-e-jovens-em-acolhimento-especializado/
  • https://www.provedor-jus.pt/a-provedora-de-justica-promove-o-seminario-transnacional-rede-de-ombudsman-construir-em-conjunto-uma-administracao-mais-eficaz-responsavel-transparente-e-etica/
  • https://www.provedor-jus.pt/quem-somos/a-provedoria-2/a-equipa/
  • https://www.provedor-jus.pt/relatorio-2024-problemas-da-atuacao-do-estado-face-a-contextos-de-pobreza-num-ano-em-que-o-tema-deficiencia-e-inclusao-foi-prioridade-estrategica/

  Recomendações:

  Rever os tamanhos de letra utilizados para informação secundária, como datas de publicação, cargos e outros elementos de contexto, assegurando que estes utilizam, no mínimo, 10 pontos e mantêm níveis adequados de legibilidade em diferentes dispositivos e resoluções.

• evidência: issue #42 Logótipo institucional apresenta texto com dimensão reduzida

  etiqueta: melhoriaetiqueta: chk conteúdoetiqueta: R 2.2

  A informação secundária (datas, autores) utiliza, no mínimo, um tamanho de letra de 10 pontos.
  – ver requisito 2.2 na lista Conteúdo

  Evidencias:

  No topo do website Provedor de Justiça, o logótipo institucional apresenta texto com dimensão reduzida, dificultando a leitura e perceção da informação associada. (Figura 01)

  

  Figura 01— Logótipo institucional no topo do website com texto de dimensão reduzida, dificultando a leitura da informação associada.

  Adicionalmente, identificámos que os logótipos disponibilizados no rodapé da página também incluem texto com dimensão reduzida. (Figura 02)

  

  Figura 02 — Logótipos disponibilizados no rodapé da página apresentam texto com dimensão reduzida, dificultando a leitura da informação associada.

  O tamanho reduzido das letras compromete a legibilidade da informação apresentada no logótipo, especialmente em resoluções mais pequenas ou em situações de ampliação do conteúdo, não garantindo uma leitura clara dos elementos disponibilizados.

  URL a verificar:

  • https://www.provedor-jus.pt/

  Recomendações:

  Aumentar o tamanho do texto associado aos logótipos, assegurando níveis adequados de legibilidade para o tamanho de letra de informações secundárias.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #40 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 a página A Provedora de Justiça promove o seminário transnacional... apresenta blocos de texto com 147 caracteres por linha, valor superior ao limite recomendado de 100 caracteres. Esta situação pode comprometer o conforto de leitura, especialmente em textos mais extensos. (Figura 01)

  

  Figura 01 — Análise de bloco de texto da página "A Provedora de Justiça promove o seminário transnacional..." na ferramenta WordCounter, com 147 caracteres por linha.

  Verificámos que a página Os Direitos são Conversa – Um Podcast da Provedoria de Justiça apresenta blocos de texto com mais de 100 caracteres por linha, tendo sido identificadas ocorrências com 144 caracteres e 108 caracteres. Esta situação pode comprometer o conforto de leitura e dificultar o acompanhamento do conteúdo em textos mais extensos. (Figura 02)

  

  Figura 02 — Análise do bloco de texto introdutório da página "Os direitos são conversa? – Um Podcast da Provedoria de Justiça" na ferramenta WordCounter, onde foram identificadas linhas com até 144 caracteres.

  URLs a verificar:

  • https://www.provedor-jus.pt/a-provedora-de-justica-promove-o-seminario-transnacional-rede-de-ombudsman-construir-em-conjunto-uma-administracao-mais-eficaz-responsavel-transparente-e-etica/ - 155 caracteres.
  • https://www.provedor-jus.pt/podcast/os-direitos-sao-conversa-um-podcast-da-provedoria-de-justica/ - 144 caracteres.
  • https://www.provedor-jus.pt/linha-da-crianca/ - 144 caracteres.
  • https://www.provedor-jus.pt/relatorio-2024-problemas-da-atuacao-do-estado-face-a-contextos-de-pobreza-num-ano-em-que-o-tema-deficiencia-e-inclusao-foi-prioridade-estrategica/ - 146 caracteres.

  Recomendações:

  Recomenda-se a revisão dos blocos de texto do website, de forma a evitar linhas excessivamente longas e garantir uma leitura mais confortável dos conteúdos.

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #78 Posição do utilizador no menu principal destacados apenas pela cor

  etiqueta: melhoriaetiqueta: chk conteúdoetiqueta: R 3.2

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

  Evidências:

  A posição atual do utilizador no menu principal é identificada exclusivamente através da cor. Não existe qualquer indicador visual adicional que permita distinguir a página ativa das restantes opções de navegação.

  Esta abordagem pode dificultar a identificação da localização atual por utilizadores com baixa visão ou com dificuldades na perceção de cores, reduzindo a compreensão do contexto de navegação.

  

  URLs a verificar:

  • https://www.provedor-jus.pt/

  Recomendações:

  • Complementar a identificação da página ativa com indicadores visuais adicionais para além da cor.
  • Utilizar, por exemplo, sublinhado, alteração de espessura da fonte, ícones ou outros elementos visuais que permitam distinguir claramente a opção ativa.

• evidência: issue #76 Inconsistências de navegação entre menu principal, menu secundário e breadcrumbs

  etiqueta: melhoriaetiqueta: chk conteúdoetiqueta: R 3.2

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

  Evidências:

  Ao aceder à opção Atividade → 50 anos, 50 casos, o menu secundário apresentado não corresponde à secção "Atividade". Em vez disso, surge o menu secundário da secção "Quem somos".

  Esta situação dificulta a compreensão da localização atual do utilizador e da relação entre os diferentes níveis de navegação.

  

  Figura 01: Página "50 anos, 50 casos" com apresentação do menu secundário de "Quem somos".

  Adicionalmente, verificam-se inconsistências de nomenclatura que reforçam esta desarticulação. Por exemplo, a opção de primeiro nível do menu “Apresentar Queixa” encaminha para a página "Submeter Queixa”
, evidenciando uma discrepância entre a designação no menu principal e o título da página de destino.

  Estas incoerência, tanto ao nível do percurso refletido nos breadcrumbs como da nomenclatura utilizada prejudicam a clareza da arquitetura de informação e a consistência da experiência de navegação, dificultando o reconhecimento da localização do utilizador dentro do site.

  

  Figura 02: Imagem da página se Submeter Queixa com o título diferente à opção do menu.

  URLs a verificar:

  • https://www.provedor-jus.pt/atividade/50-anos/
  • https://www.provedor-jus.pt/quem-somos/perguntas-frequentes/submeter-queixa/

  Recomendações:

  Recomenda-se a revisão da lógica de navegação, assegurando que o menu secundário reflete o caminho do menu principal e o percurso do utilizador, de modo a garantir a correta perceção, consistência da nomenclatura e sua localização no site.

• evidência: issue #54 Não é percetível qual a posição atual do utilizador através do menu

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 3.2

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

  Evidências:

  A opção do menu selecionada deve ser visualmente diferente das restantes opções para evidenciar a página onde o utilizador se encontra na arquitetura de informação. Em alternativa, a posição do utilizador pode ser transmitida através das breadcrumbs, desde que estas transmitam claramente o percurso feito até à página atual.

  Há páginas que atualmente não existe qualquer indicação da posição do utilizador. Como se observa na Figura 01, o menu não tem um estilo que distinga a página atual onde o utilizador se encontra, neste caso a página Outras decisões, e as breadcrumbs não refletem o percurso do utilizador até essa página.

  

  Figura 01: Breadcrumb da página de pesquisa após acesso por "Outras Decisões".

  • Exemplos - Nenhuma opção do menu principal com destaque.

  Neste caso a opção "Quem somos" devia estar com foco, visto que este foi o percurso do utilizador.

  

  Figura 02: Resultado da navegação ao selecionar a opção principal "Quem somos".

  URLs a verificar:

  • https://www.provedor-jus.pt/mecanismo-nacional-de-prevencao/o-provedor-de-justica-enquanto-mnp/
  • https://www.provedor-jus.pt/instituicao-nacional-de-direitos-humanos/o-provedor-de-justica-enquanto-indh/
  • https://www.provedor-jus.pt/pesquisa-documentos/?categoria%5B0%5D=outras-decisoes

  Recomendações:

  Para o requisito ser cumprido, devem garantir que a posição atual do utilizador é evidenciada por pelo menos uma destas duas opções: no menu ou breadcrumbs. No menu, é necessário adicionar o atributo aria-current para que seja percetível também pelas tecnologias de apoio. Para além da cor, deve ser utilizada a forma para destacar a página (sublinhado, por exemplo).

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 4.1

  Os documentos longos têm um índice no topo com hiperligações internas para o mesmo.
  – ver requisito 4.1 na lista Conteúdo

  Evidências:

  Verificámos que a página Constituição da República Portuguesa (extratos) disponibiliza um conteúdo extenso, organizado por vários artigos, sem apresentar um índice de navegação no início da página.
  Esta situação dificulta a localização e o acesso direto às diferentes secções do documento, obrigando os utilizadores a percorrer todo o conteúdo para encontrar a informação pretendida. (Figura 01)

  

  Figura 01— Página extensa não apresenta índice de navegação para as diferentes secções do conteúdo.

  URLs a verificar:

  • https://www.provedor-jus.pt/quem-somos/legislacao-base/constituicao-da-republica-portuguesa-extratos/
  • https://www.provedor-jus.pt/quem-somos/legislacao-base/estatuto-do-provedor-de-justica/
  • https://www.provedor-jus.pt/quem-somos/legislacao-base/lei-organica-da-provedoria-de-justica/
  • https://www.provedor-jus.pt/quem-somos/legislacao-base/lei-de-acesso-dos-militares-ao-provedor-de-justica/

  Recomendações:

  Disponibilizar um índice de navegação no início dos documentos extensos, com hiperligações internas para os diferentes capítulos, artigos ou secções do conteúdo. Esta abordagem facilita a localização da informação e permite aos utilizadores aceder diretamente às áreas de interesse sem necessidade de percorrer todo o documento.

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 4.2

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

  Evidências:

  Verificámos que, em larguras de ecrã reduzidas, a secção Newsletter do website Provedor de Justiça não se adapta corretamente ao espaço disponível e texto associado à opção de consentimento ("Li e aceito a Política de Privacidade e Segurança") apresenta-se desalinhado relativamente à caixa de seleção, comprometendo a legibilidade e a apresentação do conteúdo. (Figura 01)

  

  Figura 01 — Secção Newsletter e Texto associado à caixa de seleção não se adapta corretamente a larguras de ecrã reduzidas.

  Adicionalmente, em alguns dispositivos móveis, o banner principal não se ajusta corretamente à largura do ecrã. Parte do conteúdo fica cortada e não são visíveis quaisquer controlos de navegação do carrossel em versões mobile. (Figura 02)

  

  Figura 02 — Banner principal apresenta conteúdo cortado e não exibe controlos de navegação nesta visualização.

  URLs a verificar:

  • https://www.provedor-jus.pt/
  • https://www.provedor-jus.pt/newsletter/

  Recomendações:

  Garantir que os diferentes componentes do website se adaptam corretamente a larguras de ecrã reduzidas, preservando o alinhamento dos conteúdos, a legibilidade da informação e a visibilidade de todos os elementos funcionais. Deverá ser efetuada uma validação dos principais componentes em diferentes resoluções e dispositivos móveis, assegurando uma apresentação consistente sem perda de conteúdo ou funcionalidades.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #21 Elementos interativos com área clicável inferior à dimensão mínima recomendada

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 5.2

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

  Evidências:

  Verificámos que o botão de pesquisa "Lupa" presente no menu principal do website Provedor de Justiça, apresenta uma dimensão de 21.23 x 19.43px, valor inferior à dimensão mínima recomendada de 44 x 44px para elementos interativos.
  (Figura 01)

  

  Figura 01— Botão de pesquisa apresenta dimensão inferior ao mínimo recomendado.

  Verificamos que na página Recomendações MNP os elementos de paginação, como por exemplo, o elemento correspondente ao número "2"apresenta uma dimensão de 19.6 x 28px, podendo dificultar a sua seleção, especialmente em dispositivos táteis.
  (Figura 02)

  

  Figura 02— Elemento de paginação apresenta dimensão inferior ao mínimo recomendado.

  Verificámos que, na página A Provedora de Justiça promove o seminário transnacional..., os ícones de partilha para redes sociais apresentam uma dimensão aproximada de 36.01px, valor inferior à dimensão mínima recomendada de 44 x 44px para elementos interativos. (Figura 03)

  

  Figura 03— Ícones de partilha para redes sociais apresentam dimensão inferior ao mínimo recomendado.

  Verificámos que a caixa de seleção disponibilizada na página Pesquisa de documentos apresenta uma dimensão de 30px de altura, valor inferior à dimensão mínima recomendada de 44 x 44px para elementos interativos. (Figura 04)

  

  Figura 04 — Caixa de seleção apresenta dimensão inferior ao mínimo recomendado.

  Verificámos que os controlos de navegação "Mais recentes" e "Mais antigas" da página Todas as notícias apresentam uma altura de 22.4px, valor inferior à dimensão mínima recomendada de 44 x 44px para elementos interativos. (Figura 05)

  

  Figura 05 — Controlos de navegação apresentam dimensão inferior ao mínimo recomendado.

  URLs a verificar:

  • https://www.provedor-jus.pt/ - Botão pesquisar no menu principal de todo website.
  • https://www.provedor-jus.pt/a-provedora-de-justica-promove-o-seminario-transnacional-rede-de-ombudsman-construir-em-conjunto-uma-administracao-mais-eficaz-responsavel-transparente-e-etica/ - Ícones de redes sociais.
  • https://www.provedor-jus.pt/mecanismo-nacional-de-prevencao/recomendacoes-mnp/?ano=2017 - Elementos de paginação.
  • https://www.provedor-jus.pt/mecanismo-nacional-de-prevencao/relatorios-anuais-de-atividade-mnp/ - Elementos de paginação.
  • https://www.provedor-jus.pt/mecanismo-nacional-de-prevencao/visitas-realizadas/?ano=2018 - Elementos de paginação.
  • https://www.provedor-jus.pt/pesquisa-documentos/?categoria[0]=fiscalizacao-constitucional - Checkbox.
  • https://www.provedor-jus.pt/noticias/page/2/ - Controlos de navegação.
  • https://www.provedor-jus.pt/podcast/os-direitos-sao-conversa-um-podcast-da-provedoria-de-justica/ - Ícones de redes sociais.

  Recomendações:

  Garantir que todos os elementos interativos apresentam uma área acionável mínima de 44 x 44px, de forma a facilitar a sua utilização em dispositivos táteis e com diferentes dispositivos apontadores. Sempre que não seja possível aumentar visualmente a dimensão dos componentes, deverá ser ampliada a respetiva área clicável, assegurando uma interação mais confortável e consistente.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #72 Botão secundário assume o destaque visual da ação principal no estado hover

  etiqueta: melhoriaetiqueta: chk conteúdoetiqueta: R 5.3

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

  Evidências:

  Verificámos que, na secção Newsletter do website Provedor de Justiça, o botão "Consultar" apresenta no estado hover o mesmo estilo visual do botão "Subscrever", identificado como a ação principal do formulário. Esta situação pode dificultar a identificação imediata da ação principal por parte dos utilizadores. (Figura 01)

  

  Figura 01— Botão "Consultar" apresenta o mesmo destaque visual da ação principal no estado hover.

  URLs a verificar:

  • https://www.provedor-jus.pt/ - Todo website.

  Recomendações:

  Garantir que o botão "Consultar" mantém uma aparência distinta da ação principal em todos os estados de interação, incluindo no estado hover.

• evidência: issue #25 Hierarquia visual insuficiente entre ações principais e elementos informativos

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 5.3

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

  Evidências:

  Verificámos que, na página Submeter Queixa, o botão de submissão apresenta o mesmo tratamento visual utilizado no botão "Subscrever" disponível no rodapé do website. Esta situação pode dificultar a identificação da ação principal associada a cada contexto. (Figura 01)

  

  Figura 01— Botão de "Submeter Queixa" apresenta o mesmo destaque visual do botão "Subscrever".

  Verificámos que, na página Pesquisa de documentos, o botão "Pesquisa avançada" apresenta o mesmo destaque visual utilizado nos botões de ação principal do website, como o botão "Submeter" disponibilizado no rodapé da página. Esta situação pode dificultar a identificação da ação principal associada a cada contexto e reduzir a hierarquia visual entre as diferentes ações disponíveis. (Figura 02)

  

  Figura 02 — Botão "Pesquisa avançada" apresenta o mesmo destaque visual utilizado em ações principais do website.

  URLs a verificar:

  • https://www.provedor-jus.pt/quem-somos/perguntas-frequentes/submeter-queixa/
  • https://www.provedor-jus.pt/pesquisa-documentos/?categoria[0]=fiscalizacao-constitucional

  Recomendações:

  Garantir uma hierarquia visual consistente entre as diferentes ações disponibilizadas nas páginas do website, reservando o maior destaque visual para a ação principal de cada contexto. As restantes ações deverão apresentar um tratamento visual diferenciado, permitindo aos utilizadores identificar de forma clara a importância e finalidade de cada ação.

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 5.4

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

  Evidências:

  Verificámos que a imagem de apresentação do relatório, disponibilizada na página Relatório à Assembleia da República 2024, não apresenta indicadores visuais claros que permitam identificá-la como um elemento clicável, dificultando a perceção da sua interação. (Figura 01)

  

  Figura 01 — Imagem do relatório não apresenta indicadores visuais de interação.

  Verificámos que os campos de pesquisa disponibilizados na página Pesquisa Avançada, na secção de "Pesquisa" apresentam reduzidos indicadores visuais de interação, dificultando a sua identificação como áreas editáveis.

  Em estado normal, os campos apresentam-se visualmente de forma semelhante aos elementos separadores utilizados na página (Linhas), não existindo indicadores suficientemente evidentes que permitam distinguir de imediato os componentes de introdução de dados. (Figura 02)

  

  Figura 02 — Campos de pesquisa apresentam reduzidos indicadores visuais de interação.

  Verificámos que vários elementos interativos disponibilizados na página A quem mais pode dirigir uma queixa apresentam-se visualmente como texto simples, sem indicadores claros que permitam identificá-los como elementos clicáveis.

  Exemplos desta situação são os elementos "Relações de consumo", "Relações de trabalho", "Banca e seguradoras", "Tribunais" e "Entidades estrangeiras ou da União Europeia", que não apresentam indicadores visuais de interação nem alterações visuais relevantes que permitam reconhecer facilmente a sua funcionalidade. (Figura 03)

  

  Figura 03— Elementos interativos apresentam-se visualmente como texto simples, sem indicadores claros de interação.

  Verificámos que os elementos "Caso 1" e "Caso 2" presentes na página Linha da Criança apresentam características visuais normalmente associadas a hiperligações, nomeadamente através da utilização de texto sublinhado e destacado do restante conteúdo. Esta apresentação pode levar os utilizadores a interpretar estes elementos como clicáveis, quando funcionam apenas como títulos ou identificadores de secção. (Figura 04)

  

  Figura 04 — Elementos não interativos apresentam aparência semelhante a hiperligações.

  Verificámos que, na página de Pesquisa, o componente de calendário apresenta elementos interativos que não são percecionados de forma clara como clicáveis.

  As datas disponíveis para navegação são apresentadas visualmente de forma semelhante a texto comum, sendo que apenas algumas datas apresentam um sublinhado para indicar a existência de conteúdos associados.

  Adicionalmente, o dia atual surge com um destaque visual semelhante a um botão, apesar de não disponibilizar qualquer interação. Esta inconsistência dificulta a identificação das datas e controlos efetivamente interativos do calendário. (Figura 05)

  

  Figura 05 — O componente de calendário apresenta datas e elementos de navegação sem indicadores visuais consistentes de interatividade.

  URLs a verificar:

  • https://www.provedor-jus.pt/documentos/relatorio-a-assembleia-da-republica-2024-mecanismo-nacional-de-prevencao/
  • https://www.provedor-jus.pt/pesquisa-documentos/?categoria%5B0%5D=fiscalizacao-constitucional
  • https://www.provedor-jus.pt/pesquisa-documentos/?categoria%5B0%5D=outras-decisoes
  • https://www.provedor-jus.pt/quem-somos/perguntas-frequentes/a-quem-mais-pode-dirigir-uma-queixa/
  • https://www.provedor-jus.pt/quem-somos/perguntas-frequentes/#1604423453246-e2462df8-a767
  • https://www.provedor-jus.pt/linha-da-crianca/ -_Verificar todas as páginas de linhas de atendimento (Linha do cidadão com deficiência e Linha do cidadão idoso)
  • https://www.provedor-jus.pt/2026/05/
  • https://www.provedor-jus.pt/2026/04/

  Recomendações:

  Garantir que os elementos gráficos clicáveis apresentam indicadores visuais que permitam identificar de forma imediata a sua possibilidade de interação. Para tal, poderão ser utilizados elementos como estilos diferenciados, ícones, legendas ou alterações visuais nos estados de interação, tornando mais evidente a natureza clicável dos componentes.

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

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 5.4

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

  Evidências:

  Verificámos que alguns ícones presentes no rodapé do website Provedor de Justiça apresentam relações de contraste inferiores ao mínimo recomendado para componentes de interface.

  O ícone de fechar o aviso de cookies apresenta contraste de 1.82:1. (Figura 01)

  

  Figura 01 — Ícone de fechar o aviso de cookies com contraste insuficiente.

  O botão "Voltar ao topo" apresenta um contraste de 1.23:1 no estado normal e 1.4:1 no estado hover, no estado hover, dificultando a sua identificação e perceção. (Figura 02)

  

  Figura 02 — Botão "Voltar ao topo" apresenta contraste insuficiente, dificultando a sua identificação.

  O botão "Aceito" apresenta uma relação de contraste de 1.15:1. (Figura 03)

  

  Figura 03 — Botão "Aceito" apresenta contraste insuficiente, dificultando a sua identificação.

  Em algumas imagens do banner principal, os controlos de navegação do carrossel apresentam contraste insuficiente no estado hover.
  Numa das situações analisadas foi identificada uma relação de contraste de 1.18:1 entre o controlo e o fundo da imagem, valor inferior ao mínimo recomendado para componentes de interface, dificultando a sua identificação durante a interação.
  (Figura 04)

  

  Figura 04— Controlo de navegação do carrossel apresenta contraste insuficiente face ao fundo da imagem.

  Verificámos que os botões de expansão do menu principal, apresentados na versão móvel do website, apresentam uma relação de contraste de 1.35:1 entre o ícone e o fundo envolvente, valor inferior ao mínimo recomendado para componentes de interface. Esta situação dificulta a identificação dos controlos responsáveis pela expansão das opções de navegação. (Figura 05)

  

  Figura 05 — Botões de expansão do menu principal apresentam contraste insuficiente.

  Verificámos que o elemento de paginação da página Recomendações correspondente ao ano selecionado apresenta uma relação de contraste de 1.18:1 entre o seu fundo e o fundo da página, valor inferior ao mínimo recomendado para componentes de interface. (Figura 06)

  

  Figura 06 — Elemento de paginação selecionado apresenta contraste insuficiente face ao fundo da página.

  Verificámos que os campos de pesquisa disponibilizados na secção Pesquisa Avançada apresentam um contraste de 1.03:1 entre o fundo do campo e o fundo da área envolvente. Esta situação dificulta a identificação visual dos campos de introdução de dados, uma vez que os mesmos se confundem com o restante conteúdo da página. (Figura 07)

  

  Figura 07— Campos de pesquisa apresentam contraste insuficiente face ao fundo da área envolvente.

  URLs a verificar:

  • https://www.provedor-jus.pt/
  • https://www.provedor-jus.pt/recomendacoes-e-outras-decisoes/recomendacoes/?ano=1992
  • https://www.provedor-jus.pt/pesquisa-documentos/?categoria%5B0%5D=fiscalizacao-constitucional
  • https://www.provedor-jus.pt/pesquisa-documentos/?categoria%5B0%5D=outras-decisoes

  Recomendações:

  Garantir que os elementos interativos apresentam indicadores visuais suficientemente percetíveis que permitam identificar de forma clara a sua presença, estado e funcionalidade. Para tal, deverá ser reforçado o contraste visual dos componentes face ao fundo envolvente, assegurando uma diferenciação adequada dos elementos interativos e dos respetivos estados de interação.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #67 Ordem de tabulação inconsistente em formulários

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

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

  Evidências:
  No website há um formulário de pesquisa no menu principal, com a ordem de navegação por teclado (tecla TAB) que não segue a sequência lógica de preenchimento dos campos. Ao navegar utilizando o teclado, a sequência de foco deve corresponder à ordem visual e funcional esperada para o preenchimento do formulário. No entanto, na modal analisada, verificou-se que a ordem de tabulação uma experiência de utilização incoerente e potencialmente confusa.

  Embora a ordem anunciada pelo leitor de ecrã siga a sequência lógica (Campo de edição de texto → Botão “Pesquisar” → Botão “Fechar”), a navegação efetiva com o teclado não respeita essa mesma ordem. Adicionalmente, do ponto de vista visual, o botão “Pesquisar” apresenta-se numa posição que não corresponde à ordem lógica de interação para submissão da pesquisa, reforçando a inconsistência entre navegação, leitura assistiva e apresentação (Figura 1 e 2).

  

  Figura 1 - Ordem visual incorreta do botão “Pesquisar” e na navegação por teclado (TAB)

  

  Figura 2 - Ordem sequencial correta com leitor de ecrã, mas não alinhada com a visual

  Esta implementação, dificulta o preenchimento eficiente do formulário e compromete a acessibilidade para utilizadores de teclado e tecnologias de apoio. Além disso, o problema é agravado pela ausência de indicação visível de foco (ver também outras violações relacionadas com foco), dificultando ainda mais a orientação durante a navegação.

  URLs a verificar

  • https://www.provedor-jus.pt/ (Componente disponível em todas páginas do website)
  • https://www.provedor-jus.pt/?s=eventos (Ordem correta nas página de Eventos)
  • https://www.provedor-jus.pt/noticias/ (Ordem correta nas página de Notícias)

  Recomendações:
  Definir a ordem de tabulação de forma a refletir a estrutura lógica e visual do formulário.
 Garantir que:

  • A sequência de foco segue a ordem natural de leitura e preenchimento
  • O foco é sempre visível
  • A navegação por teclado é consistente com o comportamento esperado pelos leitores de ecrã

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #68 Formulários de curta dimensão

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

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

  Evidências:
  Não foram encontrados formulários com mais de 2 ecrãs de altura, pelo que o requisito é considerado não aplicável (N/A).

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

Lista de evidências recolhidas:

• evidência: issue #69 Há formulários com mais de uma página que não têm passos com designação

  etiqueta: melhoriaetiqueta: R 1.3etiqueta: 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:
  Em formulários compostos por várias etapas, deve ser assegurada a identificação clara da sequência de passos, incluindo a designação de cada etapa, de forma a indicar ao utilizador, de forma imediata, o seu ponto atual no processo.
  No formulário Submeter Queixa, existe um formulário de Pedidos a preencher com várias páginas/etapas, mas estas não apresentam uma designação visível e persistente que permita identificar claramente cada fase do preenchimento.

  Por exemplo, nas etapas “Dados do(a) Reclamante” e “Outros Dados do(a) Interessado(a)”, não é explicitamente indicado ao utilizador em que passo se encontra durante o preenchimento (Figuras 1 e 2), dificultando a perceção da progressão no processo.

  

  Figura 1 - Simulação de preenchimento do formulário, Etapa 1: Dados do(a) Reclamante

  

  Figura 2 - Simulação de preenchimento do formulário, Etapa 2: Outros Dados do(a) Interessado(a)

  Além disso, ao final do formulário, é apresentada uma página de Validação de Dados que reduz o processo a apenas duas etapas, quando, na realidade, o formulário é composto por três fases distintas, o que pode induzir o utilizador em erro quanto ao número total de passos. (Figura 3)

  

  Figura 3 - Etapa final de validação de Dados com síntese incoerente com o preenchimento das etapas

  As etapas existentes no formulário são:

  • Dados do(a) Reclamante
  • Outros Dados do(a) Interessado(a) / Queixa a reportar
  • Queixa (Descrição da Queixa)

  URLs a verificar

  • https://servicos.provedor-jus.pt:7777/queixas/Step1.aspx
  • https://servicos.provedor-jus.pt:7777/queixas/Step1c.aspx
  • https://servicos.provedor-jus.pt:7777/queixas/Step2.aspx
  • https://servicos.provedor-jus.pt:7777/queixas/Step4.aspx

  Recomendações:
  Rever a estrutura dos formulários multi-etapas, assegurando a inclusão de um indicador de progresso claro, visível e acessível, que identifique cada passo e a posição atual do utilizador no processo. Garantir que esta informação está presente em todas as etapas, é percecionável por todos os utilizadores, incluindo leitores de ecrã e por fim apresenta a sequência e o estado das etapas (ex.: atual, concluída, pendente)

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #28 Não foram identificados formulários que utilizem revelação progressiva

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

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

  Evidências:

  Dentro do domínio do site da Provedoria de Justiça, 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”.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #36 O texto placeholder está a substituir a label

  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

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

  Evidências:
  Nos formulários de subscrição da newsletter — tanto no final da página como na modal — os placeholders estão a ser usados no lugar dos rótulos dos campos.

  

  Figura 1 - Análise do formulário para subscrição da newsletter, no final da página, através do Google Inspector.

  

  Figura 2 - Análise do formulário para subscrição da newsletter, na modal de newsletter, através do Google Inspector.

  URL a verificar:
  Página da Homepage

  Recomendações:
  Recomendamos a revisão dos formulários para garantir que:

  • são atribuídas legendas aos campos utilizando o elemento ;
  • 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 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.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #64 Significado do asterisco não é visível no início do formulário

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

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

  Evidências:
  No formulário da página Dados do(a) Reclamante, a legenda que indica o significado do asterisco (“*”), encontra-se quase no final do formulário.

  

  Figura - Formulário da página Dados do(a) Reclamante.

  URL a verificar:
  Página Dados do(a) Reclamante

  Recomendações:
  Recomendamos que esta informação seja apresentada no início do formulário, para que os utilizadores compreendam desde logo que o asterisco identifica campos de preenchimento obrigatório.

• evidência: issue #51 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:
  O campo “Li e aceito a Política de Privacidade e Segurança”, presente tanto no formulário de subscrição no final da página como na modal de Newsletter, não inclui qualquer indicação programática de que é obrigatório.

  

  Figura 1 - Análise do campo "Li e aceito a Política de Privacidade e Segurança", presente no formulário para subscrição da newsletter no final da página, através do leitor de ecrã NVDA. A leitura que o leitor de ecrã faz deste elemento está destacada através de um retângulo de borda preta.

  

  Figura 2 - Análise do campo "Li e aceito a Política de Privacidade e Segurança", presente no formulário para subscrição da newsletter no final da página, através do Google Inspector.

  

  Figura 3 - Análise do campo "Li e aceito a Política de Privacidade e Segurança", presente na modal com o formulário para subscrição da newsletter, através do Google Inspector.

  URL a verificar:
  Página da Homepage

  Recomendações:
  Recomendamos adicionar o atributo required a todos os campos obrigatórios, para que as tecnologias de apoio os consigam identificar corretamente como campos de preenchimento obrigatório.

• evidência: issue #47 Os campos obrigatórios não estão identificados visualmente

  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:
  O campo “Li e aceito a Política de Privacidade e Segurança”, presente tanto no formulário de subscrição no final da página como na modal, não apresenta qualquer indicação visual de que é um campo obrigatório.

  

  Figura 1 - Formulário para subscrição da newsletter no final da página.

  

  Figura 2 - Modal com formulário para subscrição da newsletter.

  URL a verificar:
  Homepage

  Recomendações:
  Recomendamos identificar os campos obrigatórios adicionando a indicação “Obrigatório” após o respetivo rótulo. Em alternativa, pode ser usado um asterisco (“*”) acompanhado de uma legenda que explique o seu significado, por exemplo: “* Campos de preenchimento obrigatório.” colocada no início do formulário.

etiqueta: N/A

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

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

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

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

  

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

  URL a verificar:

  • https://www.provedor-jus.pt/ (no footer em todo website - subscrição newsletter)

  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

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #50 Não existem formulários que permitam ações destrutivas pelo utilizador

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

  As ações destrutivas nunca devem ser permanentes, deve ser sempre possível desfazer a operação.
  – ver requisito 4.2 na lista Transação

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #46 Existem campos cujos erros são comunicados apenas através da cor

  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:
  O erro de preenchimento incorreto do campo de concordância com a política de privacidade do formulário de subscrição de newsletter é comunicado através de um contorno em cor vermelha.

  

  Erro comunicado apenas através da cor
  O preenchimento parcial do campo email do mesmo formulário provoca um erro que é comunicado às tecnologias de apoio quando se foca esse campo e que indica que o email é inválido, mas essa mensagem não é apresentada no ecrã. Acresce que, se esse campo não for preenchido, nenhum erro é comunicado às tecnologias de apoio.

  

  URLs a verificar:
  https://www.provedor-jus.pt/

  Recomendações:
  Recomendamos a introdução de mensagens de erro na vizinhança de cada campo de todos os formulários, que devem estar visíveis para todos os utilizadores e tecnologias, de modo a comunicar as situações de erro também por via textual, permitindo assim a perceção dos erros também pelos utilizadores com limitações ao nível da visão.

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

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

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

  Nota: verificámos que no formulário da página Pedido a preencher (formulário num domínio externo mas hiperligado a partir de uma página no domínio do site em análise) as mensagens de erro também não foram programaticamente associadas aos respetivos campos. Neste caso recomendamos que entrem em contacto com a entidade responsável do formulário, se possível, indicando as melhorias acima referidas.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #52 Não existem mensagens de erro que ajudam na resolução do problema

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

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

  Evidências:

  No formulário da página subscrição de newsletter não existe uma mensagem de erro que ajude no preenchimento do campo email:

  

  Ausência de mensagem de erro que ajude no correto preenchimento do campo

  Como observado na figura, quando o campo é preenchido com um formato incorreto não existe mensagem de erro que indique qual o formato a ser inserido, não ajudando a preencher o campo.
  URLs a verificar:

  • https://www.provedor-jus.pt/
  • https://servicos.provedor-jus.pt:7777/odfrontend/publico/formulario/1

  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.

  Nota: verificámos que o mesmo problema ocorre também no formulário da página Pedido a preencher (formulário num domínio externo mas hiperligado a partir de uma página no domínio do site em análise).
  Neste caso recomendamos que entrem em contacto com a entidade responsável do formulário, se possível, indicando as melhorias acima referidas.

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

Lista de evidências recolhidas:

• evidência: issue #77 Falhas de navegação em formulário ao utilizar o botão “retroceder” do navegador

  etiqueta: melhoriaetiqueta: outras violações

  Evidências:
  Na página Submeter Queixa, existe um formulário de Queixas em que foi identificado um comportamento inconsistente no decorrer da navegação, ao pressionar o botão “retroceder” do navegador através do browser:

  • As etapas anteriormente preenchidas não são corretamente restabelecidas;
  • Alguns conteúdos são indisponíveis ou incompletos;
  • Em certos casos, o fluxo do formulário torna-se inconsistente, impedindo a continuação normal do processo, por exemplo nesta página https://servicos.provedor-jus.pt:7777/odfrontend/publico/pedido/122017

  Este comportamento compromete a previsibilidade e a robustez da interação, podendo causar perda de informação já introduzida e frustração do utilizador. (Figura 1 e 2)

  

  Figura 1 - Aparecimento de Página sem contexto no fluxo de preenchimento da "Queixa"

  

  Figura 2 - Durante acesso ao formulário público, mensagem de erro "Não está autorizado a ver este recurso"

  URLs a verificar

  • https://servicos.provedor-jus.pt:7777/odfrontend/publico/pedido/121786
  • https://servicos.provedor-jus.pt:7777/odfrontend/publico/pedido/121787
  • https://servicos.provedor-jus.pt:7777/odfrontend/publico/pedido/121788
    (Páginas com etapas disponível só ao retroceder e não está funcional)

  Recomendações
  Considerar a implementação de controlos internos de navegação (botões “Anterior” e “Seguinte”) devidamente sincronizados com o estado da aplicação, em vez de depender exclusivamente do navegador.

  • Apresentar mensagens claras ao utilizador sempre que ocorra perda de sessão ou necessidade de reinício do processo;
  • Validar o comportamento do formulário em diferentes navegadores e cenários de navegação (incluindo retrocesso e avanço);

• evidência: issue #75 Outras violações - Há botões em inglês na versão portuguesa do website

  etiqueta: melhoriaetiqueta: outras violações

  Evidências:
  Verificámos uma inconsistência linguística, uma vez que o site está em português mas há botões e conteúdos com o textos alternativos em inglês.

  O website apresenta problemas de inconsistência linguística em elementos interativos como o link “Skip to content”, que indica para utilizador navegar para conteúdo principal, dificultando a compreensão para utilizadores do idioma português, língua em que o site é implementado. (Figura 1)


  

  Figura 1 - Link para “Saltar para o conteúdo principal da página” em inglês impacta na experiência com leitor de ecrã NVDA

  O menu principal apresenta os mesmos problemas, verifica‑se a existência de conteúdos textuais em inglês. Esta inconsistência linguística acontece em diferentes botões do website, como o “Voltar ao topo” com title="Scroll to top" e por exemplo no botão da pesquisa com title="Search" (Figura 2)

  

  Figura 2 - Texto alternativo dos botões do idioma e pesquisa incorretos

  A mistura de idiomas pode causar confusão aos utilizadores, afetar a compreensão da informação e constituir uma barreira à acessibilidade, especialmente para pessoas com dificuldades cognitivas, utilizadores de leitores de ecrã ou cidadãos com menor proficiência em inglês. 

  URLs a verificar

  • https://www.provedor-jus.pt/
- https://www.provedor-jus.pt/quem-somos/perguntas-frequentes/submeter-queixa/ (Verificar texto alternativo dos botões também nas páginas interiores. Ex: Botão “voltar ao topo”)

  Recomendações:
  Recomenda‑se a uniformização do idioma de todos os conteúdos apresentados na página, garantindo que o texto se encontra integralmente em português quando o idioma principal definido é PT. Deverá ser assegurado que quaisquer termos, componentes ou conteúdos sejam devidamente traduzidos e revistos, promovendo a coerência linguística, a clareza da informação.

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

  etiqueta: melhoriaetiqueta: outras violações

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

  Durante a navegação sequencial através da tecla TAB e SHIFT+TAB, 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 secção “Destaques” em que as notícias não possuem foco visível em relação a navegação com leitor de ecrã (Figura 1)

  

  Figura 1 – Exemplo de ausência de foco visível na navegação por com leitor de ecrã NVDA

  O problema se repete em páginas interiores e em todo website, por exemplo na navegação por teclado com o breadcrumb com as hiperligações que não são circunscritas pelo foco, o mesmo acontece com menu principal e hiperligações do rodapé. (Figura 2)

  

  Figura 2 – Exemplo de foco que não circunscreve as hiperligações pela navegação com teclado para indicar interatividade clicável

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

  URLs a verificar

  • https://www.provedor-jus.pt/ (Todo website)
  • https://www.provedor-jus.pt/mnp-apresenta-relatorio-tematico-sobre-criancas-e-jovens-em-acolhimento-especializado/ (Páginas interiores)

  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 #73 Outras violações - Existem páginas que apresentam quebra de layout

  etiqueta: melhoriaetiqueta: outras violações

  Evidências:

  Verificámos uma quebra de layout nos elementos interativos da paginação. Por exemplo, a secção Newsletter na página da Pesquisa, com problemas de quebra de layout, nomeadamente a checkbox da Política de Privacidade e Segurança, onde a componente surge visual e estruturalmente desformatada.(Figura 1)

  

  Figura 1 - Problemas de quebra de layout na componente da Checkbox da Newsletter

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

  URLs a verificar

  • https://www.provedor-jus.pt/?s=eventos
  • https://www.provedor-jus.pt/noticias/

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