Relatório Avaliação de Candidatura
Plataforma de indicadores, estatísticas e dados abertos da Justiça

Introdução

O website https://numeros.justica.gov.pt/ etiqueta: não passa nos requisitos mínimos do Selo de Usabilidade e Acessibilidade.

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

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

Níveis de conformidade das avaliações manuais
ChecklistConformidade alcançadaResultado
10 aspetos48.0% (12/25)etiqueta: Não passa
Conteúdo23.5% (4/17)etiqueta: Não passa
Transação25.0% (2/8)etiqueta: Não passa

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

Verificámos também que a Declaração de Acessibilidade não se encontra corretamente afixada. Consulte o capítulo "Declaração de acessibilidade" para saber o que tem de corrigir.

Declaração de Acessibilidade

etiqueta: NOK

De acordo com o artigo 8º do DL n.º 83/2018, todos os sítios web e todas as aplicações móveis têm de ostentar uma Declaração de Acessibilidade. A Declaração é o documento na qual a organização evidencia o trabalho levado a efeito para tornar os seus conteúdos e serviços digitais mais acessíveis, disponibilizando ainda contactos para ajuda adicional.

Lista de evidências recolhidas:

Avaliação automática

etiqueta: NOK

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

Lista de evidências recolhidas:

Avaliação manual

etiqueta: NOK

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

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

Checklist 10 aspetos

etiqueta: NOK

Nível de conformidade:

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

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #38 As navegações estão nomeadas de forma inapropriada

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.2

    Quando se navega com o leitor de ecrã, é possível identificar que a opção de idiomas, a área de autenticação e o menu principal foram estruturados como elementos de navegação (role="navigation"). Contudo, estes elementos estão nomeados de forma inadequada ou, em alguns casos, não possuem qualquer nome acessível, nomeadamente:

    1. O menu principal está identificado com o aria-label="Navegação principal":
    2. A opção de idioma está estruturada como um elemento nav, mas não está sendo atribuído um nome.
    3. A área de autenticação está nomeada em inglês com o aria-label="User navigation".
    Image

    Existem também outras duas áreas de navegação na página — a de breadcrumbs e a do rodapé — que se encontram nomeadas de forma inadequada:

    1. O breadcrumb é um termo técnico e pode não ser comum para utilizadores que não trabalhem com tecnologia.
    2. O footer é um termo técnico e pode não ser comum para utilizadores que não trabalhem com tecnologia.
    Image

    URL

    Sugestão de correção

    • Quando o conteúdo estiver estruturado como nav, o leitor de ecrã já anuncia a sua identificação como "navegação". Para não ficar redundante, recomendamos não utilizar o termo "Navegação" para compor o seu nome.
    • Quando existir mais de uma navegação na página, todos as navegações devem ser nomeadas para garantir que sejam corretamente identificadas, como por exemplo "Opções de idioma".
    • O nome acessível deve ser do mesmo idioma da página.
    • Evitar o uso de termos técnicos ou jargões para nomear áreas de navegação. Por exemplo, em vez de utilizar o termo “Breadcrumb”, pode ser adotada uma alternativa mais compreensível, como “Você está aqui:”. Da mesma forma, em vez de “Footer”, pode ser utilizado um nome mais descritivo, como “Outros recursos”.

  • issue #22 Não é possível navegar com leitores de ecrã pelas opções do menu

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.2

    Quando navegamos com o leitor de ecrã no menu principal do website, embora seja possível abrir o menu e visualizar as opções no ecrã, não é possível selecionar nenhuma delas. Além disso, ao expandir a popup, o leitor de ecrã anuncia todas as opções de uma só vez, mesmo que estas não possam ser selecionadas individualmente:

    Leitor de ecrã anuncia todas as opções quando o menu é aberto

    Estruturalmente, verifica‑se que o atributo responsável por expandir e recolher o menu, permanece sempre definido como aria-expanded="false", independentemente de o menu estar aberto ou fechado. Além disso, observa‑se a utilização do atributo aria-haspopup, que não é recomendado para menus de navegação em websites:

    Menu aberto e o aria-expanded continua como false

    Observação

    • Este problema ocorre especificamente quando se utiliza o leitor de ecrã VoiceOver com o Safari.

    URL

    Sugestão de correção

    • Remover o atributo aria-haspopup.
    • O atributo aria-expanded deve mudar conforme estado do menu (aberto/fechado) e isso deve ser notificado para as tecnologias de apoio.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #69 O texto alternativo das opções está inapropriado

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.3

    As opções do menu estão a ser anunciadas pelos leitores de ecrã da seguinte forma:

    1. O menu é anunciado como “Navegação principal”.
    2. A opção de idioma é anunciada como “PT”.
    3. A área de login é anunciada como “Menu de utilizador”.

    Estas designações podem não ser as mais claras para os utilizadores, sobretudo quando comparadas com termos mais comuns, como “Menu”, “Autenticação” e “Português”, que tendem a ser mais assertivos na maioria dos websites:


    URL

    Sugestão de correção

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

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

Lista de evidências recolhidas:

  • issue #39 Na homepage o logo não está marcado como h1

    etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 2.1

    Na página inicial o logótipo está atribuído ao título "Bem-vindo à plataforma de indicadores , estatísticas e dados abertos da Justiça". O título está abaixo do logo principal da página.

    Evidencias:

    Image

    Figura 1 - Identificação do logótipo como elemento principal da página, sem marcação como <h1>.

    Image

    Figura 2: Presença de um <h1> associado ao texto descritivo abaixo do logótipo.

    Recomendações:

    • Na página inicial, associar o elemento <h1> ao logótipo do website, por representar o elemento principal e identificador da página.
    • Nas restantes páginas internas, manter o <h1> associado ao título principal do conteúdo da página.
    • Após a correção, o atual <h1> (“Bem-vindo à plataforma de indicadores, estatísticas e dados abertos da Justiça”) deve ser removido ou reclassificado para um nível inferior (ex.: <h2>), de forma a preservar a hierarquia semântica.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #37 Incorreta marcação hierarquizada de títulos e subtítulos

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 2.2

    Nas páginas analisadas, foram identificadas várias inconsistências na utilização de cabeçalhos, nomeadamente:

    • Existência de cabeçalhos vazios (sem conteúdo textual).
    • Saltos na hierarquia de cabeçalhos (ex.: utilização de <h2> sem existência prévia de <h1>, ou <h2> seguido diretamente de <h4>).
    • Utilização de elementos não semânticos (<p>, <div>) para representar títulos visuais.
    • Ausência de marcação semântica adequada em elementos que funcionam como títulos de secções (ex.: "Filtrar pesquisa").

    Estas situações comprometem a correta interpretação da estrutura do conteúdo por tecnologias de apoio.

    Evidencias:

    Image

    Figura 1 - Exemplo de salto na hierarquia de cabeçalhos, com utilização de <h2> sem <h1>.

    Image

    Figura 2 - Exemplo de título marcado com <p> em vez de <h3>.

    Image

    Figura 3 - Exemplo de títulos marcados com <div>, que devem ser substituídos por elementos de cabeçalho apropriados (<h2>, <h3>, <h4>).

    Image

    Figura 4 - Exemplo adicional de títulos marcados com <div> em vez de cabeçalhos.

    Image

    Figura 5 - Exemplo de cabeçalho vazio (sem conteúdo).

    URLs a verificar:

    https://estatisticas.justica.gov.pt/
    https://numeros.justica.gov.pt/dados-abertos - Alterar títulos para cabeçalhos
    https://numeros.justica.gov.pt/estudos-e-reutilizacoes-0 - Alterar títulos para cabeçalhos
    https://numeros.justica.gov.pt/outros-indicadores - Alterar títulos para cabeçalhos como descrito na Figura 4.
    https://numeros.justica.gov.pt/outros-indicadores/atividade-empresarial-e-registos - Alterar títulos para cabeçalhos
    https://numeros.justica.gov.pt/pesquisar - Alterar títulos para cabeçalhos
    https://numeros.justica.gov.pt/sobre - Alterar títulos para cabeçalhos
    https://numeros.justica.gov.pt/ajuda - Alterar títulos para cabeçalhos como descrito na Figura 3.
    https://numeros.justica.gov.pt/estudos-e-reutilizacoes-0 - "Filtrar pesquisa" deve ser marcado como cabeçalho.

    Recomendações:

    • Implementar uma hierarquia consistente de cabeçalhos (<h1> – <h6>) em todas as páginas, respeitando a ordem sequencial (sem saltos de níveis).
    • Garantir a existência de um único <h1> por página, representando o conteúdo principal.
    • Substituir elementos <p> e <div> utilizados como títulos por elementos de cabeçalho semanticamente adequados - vêr exemplo da figura 2 - https://numeros.justica.gov.pt/sobre.)
    • Remover cabeçalhos vazios ou assegurar que contêm conteúdo descritivo relevante.
    • Marcar elementos que funcionam como títulos de secções (ex.: "Filtrar pesquisa") com cabeçalhos apropriados.
    • Rever transversalmente todas as páginas para assegurar consistência na aplicação da estrutura de cabeçalhos.

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

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

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

Requisito 4.1 - Ao clicar com o rato na etiqueta, o cursor surge no respetivo campo de edição

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #41 O atributo placeholder está a substituir a etiqueta

    etiqueta: chk 10 webetiqueta: R 4.1etiqueta: NOK

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

    A caixa de texto do formulário de Pesquisa tem uma etiqueta associada, mas o texto dessa etiqueta está oculto visualmente:

    Image

    Campo de pesquisa com texto da etiqueta oculto visualmente
    Como se pode observar na figura, o texto da etiqueta do campo de pesquisa está num elemento label com uma classe visually-hidden.
    Portanto, do ponto de vista de quem utiliza a visão, é como se o campo não tivesse o elemento label associado.
    Na vizinhança do campo de pesquisa existe um elemento div com o texto “O que procura?”, texto esse que está visível a todos os agentes. Saliente-se ainda que o campo de pesquisa tem também um atributo placeholder.
    O atributo placeholder e o texto da div referida estão, portanto, a substituir a etiqueta.
    Tal situação não é recomendável, uma vez que o conteúdo do placeholder desaparece da interface assim que se começa a escrever no campo, o que pode ser prejudicial para utilizadores com défice de memória.
    Quando cada campo tem uma etiqueta com texto visível e associada programaticamente a esse campo, é possível focar o campo ao clicar na etiqueta (ampliação da área de clique), o que pode beneficiar pessoas com dificuldades motoras ao selecionar um campo específico. Neste caso, não é possível focar o campo ao clicar no texto da div acima referida.

    Recomendamos a revisão dos formulários para garantir que os textos de todas as etiquetas estejam visíveis no ecrã. Para além disso, os elementos com texto que esteja a fazer o papel das etiquetas (como é o caso do elemento div acima referido) devem ser removidos (os atributos placeholder podem permanecer).
    Finalmente, pedimos que questionem se faz sentido manterem um atributo title e um atributo placeholder no mesmo campo, até porque alguns leitores de ecrã lêem o conteúdo dos dois atributos quando se navega com tab e shift+tab, o que configura a leitura de duplicação de informação. O mais comum nestes casos é a existência apenas do atributo placeholder nos campos de formulário.

Requisito 4.2 - É possível identificar os campos de preenchimento obrigatório quando se usa apenas um leitor de ecrã

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #72 Implementação incorreta do atributo “required” em campos obrigatórios

    etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 4.2

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

    No formulário da página Autenticação, foi adicionado aos elementos input dos campos de preenchimento obrigatório o atributo required = “required”.

    Apesar de o leitor de ecrã estar a reconhecer estes campos como de preenchimento obrigatório, a sintaxe não é a mais adequada.

    Recomendamos a revisão dos campos de preenchimento obrigatório dos formulários de forma a substituir required = “required” pelo atributo required, ou na sua versão longa utilizando required = "true".

    Image

    Figura 1 - Análise do formulário da página Autenticação. Os atributos required="required", no input dos campos de preenchimento obrigatório, estão destacados através de retângulos de borda preta.

    Image

    Figura 2 - Análise do formulário da página Autenticação através do leitor de ecrã NVDA.

  • issue #52 Não há informação clara sobre o que é o asterisco nos campos de preenchimento

    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

    Os campos obrigatórios dos formulários devem estar devidamente identificados como tal. Idealmente, devem apresentar o texto “Obrigatório” à frente da legenda do campo. Pode-se colocar um * no campo obrigatório, desde que o significado do * seja mencionado no início do formulário.
    No formulário da página Autenticação não existe informação sobre o significado do asterisco nos campos de preenchimento obrigatório.
    Recomendamos a revisão dos formulários por forma a adicionarem uma legenda no início do formulário que indique claramente o significado do . Por exemplo, “ Campo de preenchimento obrigatório”.
    Recomendamos que seja usado apenas “(obrigatório)” ou “(campo obrigatório)” à frente dos rótulos dos campos, ou em alternativa o uso do * (desde que a indicação do seu significado conste no topo do formulário).

    Image

    Formulário da página Autentiação. Não existe informação sobre o significado do asterisco nos campos de preenchimento obrigatório

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

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

Lista de evidências recolhidas:

  • issue #77 Existem erros que nas etiquetas são transmitidos apenas através da cor

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

    Quando o nome do utilizador e / ou password é / são incorretamente preenchido(s) no formulário da página Autenticação, existe um erro que, ao nível da etiqueta “Nome de utilizador”, é transmitido apenas através da mudança da cor do texto dessa etiqueta:

    Image

    Recomendamos a colocação de uma mensagem de erro textual junto ao campo “Nome de utilizador” comunicando algo genérico como “Erro no preenchimento”, de forma a replicar em texto a mensagem que está a ser transmitida pela cor.
    Em alternativa recomendamos a remoção da alteração da cor da etiqueta “Nome de utilizador”, pois a mensagem genérica de erro já aparece no topo.

  • issue #76 Mensagem de erro difícil de descobrir por utilizadores de tecnologias de apoio

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

    A mensagem de erro apresentada após submissão do formulário da página Autenticação encontra-se no topo da página e não antes e adjacente ao formulário:

    Image

    Mensagem de erro no topo da página
    Como observado na figura, a mensagem de erro encontra-se no topo da página, estruturalmente a seguir ao link de salto para o conteúdo principal. Não sendo a mesma lida automaticamente pelas tecnologias de apoio e não sendo facilmente descoberta pelos utilizadores destas tecnologias, tal impacta negativamente na perceção da mensagem de erro.
    Para além disso, a mensagem encontra-se parcialmente num idioma diferente do configurado no site.
    Recomendamos que a mensagem de erro seja movida para o topo do formulário e, se possível, seja inserido um alerta automático da sua apresentação às tecnologias de apoio (por exemplo, através de aria-live="polite", role="alert" ou role="status").
    Recomendamos ainda que que a totalidade da mensagem seja apresentada no idioma configurado no site.

  • issue #54 Existem formulários sem mensagens de erro junto de cada campo

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

    O formulário da página Autenticação não apresenta mensagens de erro junto de cada campo:

    Image

    Formulário de autenticação sem mensagens de erro junto de cada campo
    Como observado na figura, as mensagens de erro são transmitidas pelo browser, e apenas uma de cada vez.
    Se num formulário pequeno como o referido tal situação tem um impacto muito reduzido, o mesmo não se pode dizer no caso de formulários com muitos campos, em que o utilizador não pretenderá submeter o formulário após cada correção. Para identificar os demais erros ainda existentes após cada submissão.
    Para além disso, note-se que os utilizadores de leitores de ecrã só têm acesso às mensagens de erro quando as mesmas são anunciadas, tendo de proceder a nova submissão para lhes serem anunciadas novamente. Isto deve-se ao facto de estas mensagens não se encontrarem no DOM, e de não existir uma forma fácil de lhes aceder via navegação por elementos dos leitores de ecrã.
    O ponto positivo que atenua este problema é que o foco é direcionado para o campo onde ocorre o erro, e cada mensagem é sempre anunciada. No entanto, os utilizadores de leitores de ecrã podem querer rever essa mensagem, e isso não é possível.

    Recomendamos a inserção de mensagens de erro na vizinhança de cada campo de todos os formulários, de forma a que as mensagens sejam apresentadas todas de uma só vez e possam ser acedidas pelos leitores de ecrã quantas vezes for necessário.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #14 Existem imagens link com texto alternativo incorreto

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.3

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

    Image

    O botão de pesquisa não possui nome acessível, não sendo possível identificá-lo ou utilizá-lo para realizar pesquisas.

    Image

    Também é possível verificar que a funcionalidade de pesquisa é apresentada através de um ícone visual de lupa gerado por CSS, enquanto o formulário de pesquisa associado se encontra oculto no HTML no estado apresentado.

    Image

    URL:

    https://numeros.justica.gov.pt/

    Recomendações:

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

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #31 Critério não aplicável – ausência de leitores multimédia no website

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

    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

    O critério não é aplicável

    O critério não é aplicável, pois não existem conteúdos de áudio ou vídeo com controlos de reprodução no website.

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

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #32 Critério não aplicável – ausência de conteúdo vídeo ou áudio

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

    O vídeo ou áudio deve conter preferencialmente legendas fechadas sincronizadas.
    – ver requisito 7.2 na lista 10 aspetos

    O critério não é aplicável

    O critério não é aplicável, pois o website não apresenta conteúdos multimédia de áudio ou vídeo que exijam a disponibilização de legendas sincronizadas ou transcrição textual.

Requisito 8.3 - Quando se retira a CSS, deve ser possível reconhecer a semântica dos diversos elementos

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #70 Botão de pesquisa com limitações de acessibilidade em tecnologia de apoio

    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

    Notas Gerais

    • Os elementos que estruturam o conteúdo devem ser corretamente expostos na árvore de acessibilidade, garantindo que a sua função e comportamento são compreensíveis e operáveis por tecnologias de apoio.

    URL a verificar

    Evidências:

    O botão/componente de pesquisa encontra-se estruturado como um elemento <div> com role="search", contendo um formulário de pesquisa e respetivos elementos associados.
    Para além da construção não estar apropriada, pois utiliza uma div ao invés de ser um botão, foi identificado que, em contexto de utilização com o leitor de ecrã VoiceOver, a navegação por setas direcionais não permite aceder ou percorrer corretamente o componente de pesquisa, limitando a sua acessibilidade através deste modo de interação.
    A navegação por teclado convencional (tecla Tab) permite algum acesso ao componente, no entanto a experiência não é consistente entre diferentes modos de navegação suportados por tecnologias de apoio.

    Image Image

    Figura 1 & 2 - Botão/componente de pesquisa estruturado como landmark de pesquisa (role="search"), com limitações de navegação em VoiceOver através de setas direcionais.

    Recomendações:

    • Validar a exposição do componente de pesquisa na árvore de acessibilidade em diferentes tecnologias de apoio
    • Garantir consistência na navegação entre modo de teclado (Tab) e navegação linear por leitor de ecrã
    • Assegurar que o componente de pesquisa é completamente operável e percetível em todos os modos de navegação assistida. Para isso, devem estrutura-lo como um botão.

  • issue #40 Uso de elementos não semânticos para ações interativas

    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

    Notas Gerais

    • Os elementos interativos devem ser implementados com HTML semântico apropriado, garantindo que a função de cada elemento é corretamente representada na estrutura da página.

    URL a verificar

    Evidências:

    Os controlos de alternância entre vista em grelha e lista são implementados através de elementos <div> com role="button" e tabindex="0", simulando o comportamento de botões interativos.

    Apesar da inclusão de atributos ARIA para suportar acessibilidade, os elementos não utilizam o elemento HTML semântico <button>, sendo implementada a funcionalidade de interação através de elementos genéricos.

    Image

    Figura 1 - Estrutura HTML dos botões de alternância de visualização (grelha/lista) implementados com elementos <div> com role="button".

    Recomendações:

    • Substituir os elementos <div> por elementos semânticos <button>
    • Remover role="button" e tabindex="0" quando for usado <button>
    • Garantir que a semântica HTML reflete diretamente a função interativa do elemento
    • Manter estilos visuais através de CSS sem comprometer a estrutura semântica

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

    Notas Gerais

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

    URL a verificar

    Evidências:

    Na listagem de documentos, cada item (categoria, título, descrição e ligação para download) é apresentado como um conjunto de informações relacionadas, estruturado com múltiplos elementos <div>.

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

    Image

    Figura 1 – Listagem de documentos 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.

    Recomendações:

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

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.1

    Verifica-se que, ao abrir a modal, o foco não é direcionado para o primeiro elemento interativo, nomeadamente o botão de fechar. Em vez disso, o foco permanece na área envolvente ou no contentor geral da modal, sem posicionamento inicial adequado num elemento interativo.

    Image

    Para além disso, verifica-se que no NVDA e versão específica do Voice Over o foco é direcionado para a opção "Mátomo" que uma das últimas opções de seleção da modal. Isso atrapalha a compreensão do conteúdo:

    Image

    Recomendações:

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

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #21 Durante a navegação o foco não fica limitado a modal

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.2

    Evidências:

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

    Image

    URL:
    https://numeros.justica.gov.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.

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

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

Lista de evidências recolhidas:

  • issue #29 (Melhoria) A caixa dialogo não pode ser encerrada através da tecla ESC

    etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 9.3

    Evidências:
    Verifica‑se que a modal de Pesquisa não pode ser encerrada através da tecla ESC.

    Image

    URL:
    https://numeros.justica.gov.pt/

    Recomendações:

    • Idealmente podem implementar um mecanismo que permita o encerramento das janelas modais através da tecla ESC além do botão de fechar.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #30 Quando a caixa de diálogo fecha, o foco não volta ao elemento interativo que o invocou.

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.4

    Evidências:

    Validado que ao fechar a modal o foco não retorna ao elemento que a acionou, no caso o botão "Preferências". O foco é reposicionado no ecrã de forma inconsistente, comprometendo a continuidade da navegação por teclado e leitor de ecrã.

    Image

    URL:
    https://numeros.justica.gov.pt/

    Recomendações:

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

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #60 Nos ficheiros PDF não é possível, extrair o conteúdo textual para formato TXT

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 10.1

    Não é possível extrair o conteúdo do PDF para formato TXT.

    Evidências:

    Image

    Figura 1 - Imagem onde não é possível exportar qualquer conteúdo.

    Image

    Figura 2 - Imagem onde foi possível apenas exportar parcialmente o conteúdo.

    Image

    Figura 3 - Imagem onde não é possível exportar qualquer conteúdo.

    URLs a verificar:
    https://numeros.justica.gov.pt/estudos-e-reutilizacoes-0?page=1

    Recomendações:

Checklist Conteúdo

etiqueta: NOK

Nível de conformidade:

  • Checklist Conteúdo: 23.5% (4/17)
    • Requisitos avaliados: 17 (17 aplicáveis)
    • Requisitos OK: 4
    • Requisitos NOK: 13

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

etiqueta: NOK

Lista de evidências recolhidas:

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

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

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

    Evidências:

    Na página inicial do website da DGPJ, não aparece presente um resumo breve do próposito do site. Apesar de existir a frase "Bem-vindo à plataforma de indicadores, estatísticas e dados abertos da Justiça" na imagem no banner principal, esta frase não resume fielmente quais as tarefas ou a informação que é possível encontrar no website.

    Image

    Imagem da página inicial sem dar scroll.

    Recomendações:

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

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

    Image

    Image exemplo de uma frase de propósito do website acessibilidade.gov

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #36 Falta de datas de atualização no website

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

    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 foram identificadas datas de atualização ao longo do website, apesar da existência de múltiplos blocos de conteúdo, como indicadores, dados abertos, contactos, estudos e reutilizações. A ausência desta informação dificulta a avaliação da atualidade e fiabilidade dos conteúdos por parte do utilizador.

    Image

    Imagem da página de contactos sem data de atualização.

    Image

    Imagem da página de informação do website sem data de atualização

    Recomendações:

    Devem ser apresentadas datas de atualização visíveis para os diferentes tipos de conteúdo, idealmente junto ao respetivo bloco ou página. Esta prática aumenta a transparência, permite ao utilizador avaliar a atualidade da informação e contribui para uma maior confiança no website.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #25 Informações primárias não possuem tamanho mínimo recomendado

    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

    Notas Gerais

    • Para garantir a legibilidade do corpo de texto, este deve ter um tamanho igual ou superior a 12pt, que equivale a 16px.

    O website possui informações primárias com tamanho inferior a 12pontos(16px). por exemplo na página Pesquisar, o texto informativo “Tipo de conteúdo” está abaixo do valor mínimo recomendado. (Figura 1)

    Image

    Figura 1 - Verificação do tamanho do texto com apenas 14.2px

    A página Ajuda possui textos informativos de conteúdos considerados primários contactos, com tamanho inferior ao recomendado. Por exemplo, nos textos dos contactos “Por telefone”, “Por email” e “Por correio postal” (Figura 2)

    Image

    Figura 2 - Textos de contactos com tamanho de 13px

    O formulário de Autenticação do website possui labels associadas aos campos de preenchimento obrigatório “Nome de utilizador” e “Palavra-passe”
que são considerados informação primária, mas apresentam um tamanho inferior ao recomendado de 14.2px. (Figura 3)

    Image

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

    O mesmo acontece nos filtros de outros formulários:


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

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

etiqueta: NOK

Lista de evidências recolhidas:

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

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

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

    Notas Gerais

    • Para assegurar uma boa leitura, as linhas de texto devem ter até 80 caracteres (incluindo espaços). No limite, podem ir até aos 100 caracteres (incluindo espaços).

    Verificamos que na página Sobre há blocos de textos, por exemplo “O que somos” que apresentam largura superior ao recomendado por linha. (Figura 1)

    Image

    Figura 1 - Análise de bloco de texto com ferramenta WordCounter com 155 Caracteres por linha

    Exemplos de outras evidências (NOK)

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

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #46 A navegação principal do site está colapsada em desktop

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

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

    Boas práticas:

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

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

    Problema específico:

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

    Image

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

    Recomendação:

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

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #11 Falhas de responsividade e inconsistência de layout em diferentes dispositivos

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

    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

    Ponto 01
    Página: https://numeros.justica.gov.pt/declaracao-de-acessibilidade-e-usabilidade

    Na página “Declaração de Acessibilidade e Usabilidade” foi identificado um comportamento inconsistente em dispositivos móveis onde o breadcrumb de navegação não se adapta corretamente.

    Em alguns dispositivos (ex: iPhone 12 Pro) o elemento “Início” (atalho de navegação para a página inicial) não é exibido e em outros casos (ex: iPhone SE) ocorre desalinhamento entre o breadcrumb e o título da página com quebra de linha e posicionamento inconsistente.

    Esta variação compromete a consistência visual e a clareza da navegação em diferentes tamanhos de ecrã.

    Dispositivo móvel (iPhone 12 Pro) onde o elemento ‘Início’, utilizado como atalho de navegação para a página inicial, não é exibido, comprometendo a consistência da navegação

    Figura 01 – Em alguns dispositivos móveis (ex: iPhone 12 Pro), o atalho “Início” não é exibido, afetando a navegação.

    Dispositivo móvel (iPhone SE) com desalinhamento entre o breadcrumb e o título da página, apresentando quebra de linha e posicionamento inconsistente dos elementos

    Figura 02 – Em alguns dispositivos móveis (ex: iPhone SE), ocorre desalinhamento entre o breadcrumb e o título da página, com quebra de linha e posicionamento inconsistente.

    Outros exemplos:
    https://numeros.justica.gov.pt/ajuda/dados-abertos
    https://numeros.justica.gov.pt/ajuda/estatisticas-oficiais-da-justica
    https://numeros.justica.gov.pt/ajuda/estudos-e-reutilizacoes
    https://numeros.justica.gov.pt/ajuda/outros-indicadores
    https://numeros.justica.gov.pt/dados-abertos/movimento-de-processos-nos-tribunais-judiciais
    https://numeros.justica.gov.pt/dados-abertos/criminalidade-registada

    Recomendação
    Deve ser garantida a adaptação responsiva consistente do breadcrumb em todos os dispositivos móveis assegurando que os elementos de navegação permanecem visíveis e corretamente alinhados independentemente do tamanho do ecrã e que a estrutura mantém coerência visual entre o breadcrumb e o título da página evitando quebras ou deslocamentos inesperados.

    Recomenda-se ainda a verificação transversal de todo o website uma vez que este comportamento foi identificado em várias páginas e camadas da estrutura.

    Ponto 02
    Página: https://numeros.justica.gov.pt/

    Na página inicial foram identificados problemas de adaptação responsiva em diferentes dispositivos móveis e resoluções.

    No card de pesquisa rápida ocorre desalinhamento dos elementos em ecrãs mais pequenos como iPhone SE, comprometendo a organização visual do conteúdo.

    O card de “Dados Abertos” esta a sobrepor-se ao rodapé em algumas resoluções como em dispositivos com largura intermédia ou elevada como o Asus Zenbook.

    Adicionalmente, no rodapé verifica-se que alguns elementos como o logótipo da DGPJ e o botão “Declaração de Acessibilidade” com o respetivo ícone se encontram demasiado próximos da borda inferior do ecrã, comprometendo o espaçamento visual e podendo afetar a consistência do layout em diferentes dispositivos.

    Card de pesquisa rápida em ecrã móvel (iPhone SE) com desalinhamento dos elementos, comprometendo a organização visual do conteúdo em resoluções mais pequenas

    Figura 03 – Card de pesquisa rápida com desalinhamento dos elementos em ecrãs pequenos (ex: iPhone SE), comprometendo a organização visual.

    Card de ‘Dados Abertos’ a sobrepor-se ao rodapé em algumas resoluções (ex: dispositivos com largura intermédia ou elevada como o Asus Zenbook), afetando a estrutura do layout

    Figura 04 – Card de “Dados Abertos” com sobreposição ao rodapé em resoluções intermédias e elevadas (ex: Asus Zenbook), afetando o layout.

    Rodapé do website com logótipo da DGPJ e botão ‘Declaração de Acessibilidade’ com ícone demasiado próximos da borda inferior do ecrã, comprometendo o espaçamento visual e a consistência do layout em diferentes dispositivos

    Figura 05 – Rodapé com elementos (logótipo da DGPJ e “Declaração de Acessibilidade”) demasiado próximos da borda inferior, afetando o espaçamento e a consistência visual.

    Outro exemplo:
    https://estatisticas.justica.gov.pt/

    Recomendação
    Deve ser garantida a adaptação responsiva consistente dos componentes da página inicial assegurando que todos os cards mantêm alinhamento correto e respeitam os limites do layout em diferentes tamanhos de ecrã e dispositivos evitando sobreposições e quebras de estrutura.

    Recomenda-se a validação transversal em múltiplas resoluções para assegurar comportamento consistente.

    Ponto 03
    Página: https://numeros.justica.gov.pt/dados-abertos?search_api_fulltext=&field_categoria=80&items_per_page=10&sort_bef_combine=title_ASC

    Na página de listagem de “Dados Abertos” é apresentada no rodapé da listagem a informação de paginação e controlo de resultados como “Itens por página”, bem como a indicação do intervalo de resultados (ex: “1 a 4 de 4”). No entanto, em alguns dispositivos móveis esta informação e controlo deixam de ser exibidos, comprometendo a consistência da navegação e a perceção do número de resultados disponíveis.

    Página de listagem de ‘Dados Abertos’ em dispositivo móvel onde a paginação e controlo de resultados (itens por página e intervalo de resultados) não são apresentados, comprometendo a consistência da navegação e a perceção dos resultados disponíveis

    Figura 06 – Em alguns dispositivos móveis, a paginação e o controlo de resultados na listagem de “Dados Abertos” não são exibidos, afetando a navegação.

    Outros exemplos
    https://numeros.justica.gov.pt/pesquisar?keys=Processos%20pendentes
    https://numeros.justica.gov.pt/pesquisar?keys=Pedidos%20de%20nacionalidade
    https://numeros.justica.gov.pt/pesquisar?keys=Sentimento%20de%20inseguran%C3%A7a
    https://numeros.justica.gov.pt/pesquisar?keys=Inven%C3%A7%C3%B5es

    Recomendação
    Deve ser garantida a adaptação responsiva consistente do componente de paginação assegurando que a informação de “Itens por página” e a indicação de resultados permanecem visíveis e acessíveis em todos os dispositivos independentemente da resolução do ecrã.
    Recomenda-se a validação em múltiplos tamanhos de ecrã para garantir que nenhum elemento essencial de navegação é ocultado em contexto móvel.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #24 Elementos interativos com dimensão inferior ao mínimo recomendado (44px)

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

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

    Ponto 01
    Página: https://numeros.justica.gov.pt/

    Os ícones de redes sociais presentes no website apresentam uma dimensão reduzida de 24px, o que dificulta a sua perceção visual e interação, especialmente em dispositivos táteis.
    Esta dimensão está abaixo do tamanho recomendado para elementos interativos, podendo comprometer a usabilidade e aumentar a dificuldade de acionamento correto.

    Ícones de redes sociais no website com dimensão reduzida (24px), dificultando a perceção visual e a interação em dispositivos táteis, podendo comprometer a usabilidade

    Figura 01 – Ícones de redes sociais com dimensão reduzida (24px), dificultando a perceção e interação, especialmente em dispositivos táteis.

    Recomendação
    Deve ser aumentada a dimensão dos ícones de redes sociais para um tamanho mínimo recomendado de 44px CSS em altura e largura, garantindo maior facilidade de interação em diferentes dispositivos, melhor acessibilidade e conformidade com boas práticas de usabilidade para elementos interativos.

    Ponto 02
    Página: https://numeros.justica.gov.pt/outros-indicadores/modernizacao-administrativa-dos-servicos-publicos

    Na página “Modernização Administrativa dos Serviços Públicos”, os controlos de navegação do carrossel apresentam inconsistência de dimensionamento.
    Verifica-se que as setas de navegação e a numeração das páginas (“1” e “2”) possuem uma dimensão fixa de 32px.

    Esta dimensão é considerada reduzida para elementos interativos de navegação, especialmente em contexto de acessibilidade e utilização em dispositivos táteis, podendo dificultar a interação precisa por parte dos utilizadores.

    Carrossel na página ‘Modernização Administrativa dos Serviços Públicos’ com setas de navegação e numeração de páginas (‘1’ e ‘2’) apresentando dimensão de 32px, podendo dificultar a interação em dispositivos táteis

    Figura 02 – Controlos do carrossel com dimensão fixa de 32px nas setas de navegação e numeração de páginas, podendo comprometer a usabilidade em dispositivos táteis.

    Outros exemplos:
    https://numeros.justica.gov.pt/pesquisar?keys=Sentimento%20de%20inseguran%C3%A7a&page=1
    https://numeros.justica.gov.pt/pesquisar?keys=Processos%20pendentes

    Recomendação
    Deve ser aumentada a dimensão dos controlos de navegação do carrossel para pelo menos 44px garantindo melhor acessibilidade e facilidade de interação em dispositivos táteis e diferentes resoluções.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #4 Inconsistência na affordance e indicação visual de elementos interativos

    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

    Ponto 01
    Página: https://numeros.justica.gov.pt/

    Os ícones de redes sociais presentes no rodapé do website não apresentam qualquer indicação de interatividade ao passar o rato não existindo estado de hover como alteração visual ou feedback que indique que são elementos clicáveis

    Ícones de redes sociais no rodapé do website sem qualquer indicação de interatividade ao passar o rato, não apresentando estado de hover ou feedback visual que indique que são elementos clicáveis

    Figura 01 – Ícones de redes sociais no rodapé sem estado de hover ou feedback visual que indique interatividade.

    Recomendação
    Deve ser adicionado um estado de hover aos ícones de redes sociais de forma a indicar claramente a sua interatividade através de alterações visuais como mudança de cor opacidade ou efeito de destaque garantindo melhor perceção de clicabilidade e melhoria da experiência de utilização

    Ponto 02
    Página: https://numeros.justica.gov.pt/#dados-abertos

    Na secção “Outros indicadores” da página inicial, os controlos de navegação “Anterior” e “Próximo” não apresentam um estilo visual consistente de botão nem indicação clara de interatividade em estado normal.
    Estes elementos funcionam como controlos de navegação, mas não possuem destaque suficiente, o que dificulta a perceção de que são clicáveis.

    Controlos de navegação ‘Anterior’ e ‘Próximo’ na secção Outros indicadores sem estilo visual consistente de botão nem indicação clara de interatividade no estado normal, dificultando a perceção de que são elementos clicáveis

    Figura 02 – Controlos de navegação “Anterior” e “Próximo” na secção Outros indicadores sem estilo de botão consistente nem indicação clara de interatividade no estado normal.

    Recomendação
    Deve ser garantida uma representação visual consistente de botão para os controlos “Anterior” e “Próximo”, assegurando que estes elementos apresentam claramente indicação de interatividade em estado normal e durante o hover, através de estilos como destaque visual, alteração de cor ou formato de botão.

    Ponto 03
    Página: https://numeros.justica.gov.pt/dados-abertos/movimento-de-processos-nos-tribunais-judiciais

    Em várias páginas do website existem elementos de texto apresentados com estilo visual semelhante a links (cor azul e destaque) como “Movimento”, “Processos” e “Tribunais” na secção “Movimento de processos nos tribunais judiciais”. No entanto estes elementos não são interativos, funcionando apenas como texto informativo.

    Esta inconsistência entre aparência e comportamento pode induzir o utilizador em erro ao sugerir que se tratam de elementos clicáveis.

    Secção ‘Movimento de processos nos tribunais judiciais’ com elementos de texto como ‘Movimento’, ‘Processos’ e ‘Tribunais’ apresentados com estilo semelhante a links, embora não sejam elementos interativos

    Figura 03 – Elementos de texto com aparência de links (ex: “Movimento”, “Processos” e “Tribunais”) que não são interativos, podendo induzir o utilizador em erro.

    Outros exemplos:
    https://numeros.justica.gov.pt/dados-abertos?search_api_fulltext=&field_categoria=80&items_per_page=10&sort_bef_combine=title_ASC
    https://numeros.justica.gov.pt/dados-abertos/pedidos-de-nacionalidade

    Recomendação
    Deve ser garantida consistência entre a aparência e a funcionalidade dos elementos evitando que texto não interativo seja apresentado com estilo de link.
    Caso os elementos não sejam clicáveis devem ser removidos estilos de destaque típicos de links como cor azul assegurando uma distinção clara entre informação e interação.

    Ponto 04
    Página: https://numeros.justica.gov.pt/outros-indicadores/modernizacao-administrativa-dos-servicos-publicos

    Na página de Modernização administrativa dos serviços públicos, os controlos de navegação do carrossel (setas de indicadores de página) não apresentam feedback visual de interatividade ao passar o rato.
    Não ocorre alteração de estado (como cor, fundo ou destaque), nem indicação clara de elemento clicável, o que dificulta a perceção de que se tratam de controlos interativos.

    Carrossel na página ‘Modernização Administrativa dos Serviços Públicos’ com controlos de navegação (setas e indicadores de página) sem feedback visual de interatividade no estado de hover, não apresentando alteração de cor, fundo ou destaque

    Figura 04– Controlos de navegação do carrossel sem feedback visual de interatividade no estado de hover, dificultando a perceção de elementos clicáveis.

    Outro exemplo
    https://numeros.justica.gov.pt/pesquisar?keys=Sentimento%20de%20inseguran%C3%A7a&page=0

    Recomendação
    Deve ser implementado um estado de hover nos controlos do carrossel, garantindo feedback visual claro de interatividade através de alterações como cor, destaque ou efeito visual.
    Esta melhoria deve assegurar melhor perceção de clicabilidade e uma experiência de utilização mais intuitiva.

Checklist Transação

etiqueta: NOK

Nível de conformidade:

  • Checklist Transação: 25.0% (2/8)
    • Requisitos avaliados: 13 (5 N/A excluídos, 8 aplicáveis)
    • Requisitos OK: 2
    • Requisitos NOK: 6
    • Requisitos N/A: 5

Requisito 1.1 - A sequência de tabulação entre campos segue a sequência de preenchimento

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #15 Não foram encontrados formulários com mais de 2 ecrãs no website

    etiqueta: chk transaçãoetiqueta: R 1.2etiqueta: N/A

    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

    Não foram encontrados formulários com mais de dois ecrãs no site em questão. Assim, este critério é considerado "Não aplicável (N/A)".

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

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #16 Não foram encontrados formulários com mais de uma página

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

    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

    Não foram encontrados formulários com mais de uma página no site em questão. Assim, este requisito é avaliado como "Não Aplicável".

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #58 O tamanho do campo de pesquisa não reflete o tamanho previsível dos dados

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

    O tamanho dos campos deve refletir o tamanho previsível dos dados.
    – ver requisito 2.1 na lista Transação

    A largura do próprio campo deve refletir o tamanho previsível dos dados a preencher, principalmente em campos de escrita livre em que o utilizador deve inserir os seus próprios dados.

    Verificámos que o campo de pesquisa geral presente no cabeçalho das páginas interiores tem uma largura insuficiente para o texto que os utilizadores precisam de introduzir.

    Recomendamos que este campo seja revisto e ajustado, de modo a garantir uma largura adequada ao tipo e à quantidade de informação que pode ser inserida.

    Image

    Figura - Pesquisa pela página Estudos e Reutilizações através do campo de pesquisa geral do site.

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

etiqueta: N/A

Lista de evidências recolhidas:

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

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

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

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

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #63 Implementação incorreta do atributo “required” em campos obrigatórios

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

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

    No formulário da página Autenticação, foi adicionado aos elementos input dos campos de preenchimento obrigatório o atributo required = “required”.

    Apesar de o leitor de ecrã estar a reconhecer estes campos como de preenchimento obrigatório, a semântica não é a mais adequada.

    Recomendamos a revisão dos campos de preenchimento obrigatório dos formulários de forma a substituir required = “required” pelo atributo required.

    Image

    Figura 1 - Análise do formulário da página Autenticação. Os atributos required="required", no input dos campos de preenchimento obrigatório, estão destacados através de retângulos de borda preta.

    Image

    Figura 2 - Análise do formulário da página Autenticação através do leitor de ecrã NVDA.

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

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

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

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

    No formulário da página Autenticação não existe informação sobre o significado do símbolo asterisco (“*”).

    Recomendamos a revisão dos formulários, de forma a adicionarem uma legenda no início do formulário que indique claramente o significado de *.

    Image

    Figura - Análise do formulário da página Autenticação através do leitor de ecrã NVDA.

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

etiqueta: N/A

Lista de evidências recolhidas:

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

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

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

    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.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #6 Confirmação de sucesso invisível para tecnologias de apoio.

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

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

    Notas Gerais

    • Sempre que um utilizador realiza uma ação que implica o envio de informação (como a submissão de um formulário), o sistema deve fornecer uma confirmação clara de que a operação foi concluída com sucesso.
    • Esta confirmação deve ser apresentada de forma imediata, visível e programaticamente determinável, garantindo que todos os utilizadores, incluindo aqueles que utilizam navegação por teclado ou tecnologias de apoio, conseguem perceber que a ação foi concluída corretamente.

    URL a verificar

    Evidências:

    No formulário de autenticação (login), após a submissão de credenciais inválidas, a mensagem de erro não é apresentada de forma acessível a utilizadores de tecnologias de apoio.

    A mensagem não é incluída no fluxo de foco da página nem anunciada automaticamente por leitores de ecrã, o que impede que o utilizador seja informado de forma imediata sobre o erro ocorrido.

    Adicionalmente, não é possível aceder a essa mensagem através de navegação por teclado (Tab e Shift+Tab), indicando que o conteúdo não está corretamente exposto no DOM de forma acessível.

    Como consequência, utilizadores que dependem de tecnologias de apoio podem não perceber que a autenticação falhou nem compreender a causa do erro.

    Image

    Figura 1 – Mensagem de erro após tentativa de autenticação não acessível para tecnologias de apoio

    Recomendações:

    • Garantir que a mensagem de sucesso é apresentada imediatamente após a submissão e posicionada junto ao formulário
    • Tornar a mensagem acessível no fluxo de foco (ex.: elemento focável ou gestão de foco automática para a mensagem)
    • Implementar anúncio automático para tecnologias de apoio (ex.: aria-live="polite" ou role="status")

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

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #57 Não existem formulários que permitam ações destrutivas pelo utilizador

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

    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

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

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #78 Existem erros que nas etiquetas são transmitidos apenas através da cor

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

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

    Quando o nome do utilizador e / ou password é / são incorretamente preenchido(s) no formulário da página Autenticação, existe um erro que, ao nível da etiqueta “Nome de utilizador”, é transmitido apenas através da mudança da cor do texto dessa etiqueta:

    Image

    Recomendamos a colocação de uma mensagem de erro textual junto ao campo “Nome de utilizador” comunicando algo genérico como “Erro no preenchimento”, de forma a replicar em texto a mensagem que está a ser transmitida pela cor.
    Em alternativa recomendamos a remoção da alteração da cor da etiqueta “Nome de utilizador”, pois a mensagem genérica de erro já aparece no topo.

  • issue #75 Mensagem de erro difícil de descobrir por utilizadores de tecnologias de apoio

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

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

    A mensagem de erro apresentada após submissão do formulário da página Autenticação encontra-se no topo da página e não antes e adjacente ao formulário:

    Image

    Mensagem de erro no topo da página
    Como observado na figura, a mensagem de erro encontra-se no topo da página, estruturalmente a seguir ao link de salto para o conteúdo principal. Não sendo a mesma lida automaticamente pelas tecnologias de apoio e não sendo facilmente descoberta pelos utilizadores destas tecnologias, tal impacta negativamente na perceção da mensagem de erro.
    Para além disso, a mensagem encontra-se parcialmente num idioma diferente do configurado no site.
    Recomendamos que a mensagem de erro seja movida para o topo do formulário e, se possível, seja inserido um alerta automático da sua apresentação às tecnologias de apoio (por exemplo, através de aria-live="polite", role="alert" ou role="status").

    Recomendamos ainda que que a totalidade da mensagem seja apresentada no idioma configurado no site.

    Finalmente, recomendamos que a mensagem de erro seja associada aos dois campos do formulário, 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 campos.
    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.

  • issue #55 Existem formulários sem mensagens de erro junto de cada campo

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

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

    O formulário da página Autenticação não apresenta mensagens de erro junto de cada campo:

    Image

    Formulário de autenticação sem mensagens de erro junto de cada campo
    Como observado na figura, as mensagens de erro são transmitidas pelo browser, e apenas uma de cada vez.
    Se num formulário pequeno como o referido tal situação tem um impacto muito reduzido, o mesmo não se pode dizer no caso de formulários com muitos campos, em que o utilizador não pretenderá submeter o formulário após cada correção. Para identificar os demais erros ainda existentes após cada submissão.
    Para além disso, note-se que os utilizadores de leitores de ecrã só têm acesso às mensagens de erro quando as mesmas são anunciadas, tendo de proceder a nova submissão para lhes serem anunciadas novamente. Isto deve-se ao facto de estas mensagens não se encontrarem no DOM, e de não existir uma forma fácil de lhes aceder via navegação por elementos dos leitores de ecrã.
    O ponto positivo que atenua este problema é que o foco é direcionado para o campo onde ocorre o erro, e cada mensagem é sempre anunciada. No entanto, os utilizadores de leitores de ecrã podem querer rever essa mensagem, e isso não é possível.

    Recomendamos a inserção de mensagens de erro na vizinhança de cada campo de todos os formulários, de forma a que as mensagens sejam apresentadas todas de uma só vez e possam ser acedidas pelos leitores de ecrã quantas vezes for necessário.
    Recomendamos ainda que essas mensagens sejam associadas programaticamente a cada campo, de forma a fornecer uma associação de cada mensagem de erro ao respetivo campo quando se navega com o modo de foco dos leitores de ecrã.
    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.
      Um exemplo de associação seria:
    <input type = "text" name = "email" aria-invalid = "true" aria-describedby = "msgerroremail">
<div id = "msgerroremail">Email não válido</div>

Outras violações

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

Lista de evidências recolhidas:

  • issue #67 Outras violações - Link “Saltar para o conteúdo principal” não é visível

    etiqueta: melhoriaetiqueta: outras violações
    Descrição da problemática

    Na estrutura do website encontra‑se disponível o link “Saltar para o conteúdo principal”, cuja finalidade é permitir aos utilizadores contornar blocos repetitivos de navegação e aceder diretamente à área principal do conteúdo. No entanto, este link não é apresentado de forma visível, não sendo identificado como um botão ou link interativo durante a navegação visual. (Figura 1)

    Image

    Figura 1 – Inspeção do link “Saltar para o conteúdo principal” funcionalidade visível apenas para leitores de ecrã

    Adicionalmente, não é devidamente percetível, comprometendo a sua função para utilizadores que navegam exclusivamente por teclado. Esta situação impede que o mecanismo de salto cumpra o seu propósito de facilitar a navegação eficiente e inclusiva, e criando barreiras operacional para utilizadores que utilizam esta funcionalidade.

    Recomendação de melhoria
    Assegurar que o link “Saltar para o conteúdo principal” seja:

    • Visualmente percetível, apresentando-se como um elemento interativo (link ou botão);
    • Disponível e visível quando recebe foco por teclado;
    • Posicionado de forma lógica no início da página, antes dos blocos de navegação repetitivos.

    O link deverá tornar‑se visível aquando da navegação por teclado (por exemplo, ao receber foco através da tecla TAB) e permitir que todos os utilizadores compreendam claramente a sua função.

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

    etiqueta: melhoriaetiqueta: outras violações

    Descrição da problemática:

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

    O website disponibiliza em todas as páginas o botão "voltar ao topo" no entanto, com texto alternativo em inglês title="Go to top", aria-label=“Scroll to top”, sem indicação adequada do atributo lang. (Figura 1)

    Image

    Figura 1 - Textos alternativos em inglês em análise com leitor de ecrã NVDA

    Image

    Figura 2 - Textos alternativos title e aria-label do botão "Voltar ao topo" está em inglês

    Essa prática pode gerar confusão para utilizadores de leitores de ecrã e outras tecnologias assistivas, além de comprometer a consistência do idioma principal da página.

    Recomendação de melhoria
    Recomendamos traduzir todos os textos alternativos dos botões para português, idioma em que o website está implementado.

  • issue #64 Outras violações - Limitações de acessibilidade com o Power BI

    etiqueta: melhoriaetiqueta: outras violações
    Descrição da problemática
    • A ferramenta Power BI apresenta limitações de acessibilidade, principalmente com leitores de ecrã. Elementos interativos e componentes da interface podem não ser totalmente reconhecidos, anunciados ou operáveis por tecnologias de apoio.

    Embora o Power BI permita a visualização e a navegação por alguns conteúdos, existem limitações e incompatibilidades tecnológicas que podem afetar negativamente o funcionamento das tecnologias de apoio, como os leitores de ecrã. Essas limitações podem manifestar‑se de diferentes formas.

    Por exemplo, na página Criminalidade Registada, a estrutura do conteúdo assemelha‑se à existência de uma página inserida dentro de outra página, com múltiplos elementos estruturais redundantes (como <head> e <body>), o que dificulta a correta interpretação e navegação por parte das tecnologias de apoio. (Figura 1)

    Image

    Figura 1 - Conteúdos de páginas disponibilizados através implementação de iFrame com o PowerBI

    Exemplo de navegação com leitor de ecrã NVDA, pela página, onde os cabeçalhos são anunciados pelo leitor de ecrã como "Caixa de texto", por exemplo o cabeçalho "Métricas". (Figura 2)

    Image

    Figura 2 - Não é possível navegar por cabeçalhos na página Criminalidade Registada

    Outras páginas com implementação de iFrame com PowerBI:

    Adicionalmente, importa salientar que a utilização do PowerBI evidencia outros problemas críticos de acessibilidade, nomeadamente a apresentação de informação em tabelas sem a devida utilização de caption, bem como a ordem de tabulação entre os elementos.

    Recomendações de melhoria:
    Recomendamos que seja evitada a utilização desta ferramenta, uma vez que garantir a acessibilidade implica um esforço significativo, de forma a assegurar que estes e outros pontos críticos são devidamente identificados e corrigidos. Outra alternativa seria disponibilizar o conteúdo em outros formatos, como um ficheiro (pdf, excel), e descrição em texto do conteúdo.

Significado das etiquetas utilizadas