Relatório Avaliação de Candidatura
POLEN - FCCN

Introdução

O website https://polen.fccn.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 aspetos33.3% (9/27)etiqueta: Não passa
Conteúdo47.1% (8/17)etiqueta: Não passa
Transação37.5% (3/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.

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: 33.3% (9/27)
    • Requisitos avaliados: 27 (27 aplicáveis)
    • Requisitos OK: 9
    • Requisitos NOK: 18

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #12 As opções do rodapé não estão estruturadas como lista

    etiqueta: NOKetiqueta: R 1.1etiqueta: chk 10 web

    As imagens‑link de “República Portuguesa — Educação, Ciência e Inovação”, “FCCN — Serviços Digitais FCT” e “FCT — Fundação para a Ciência e Tecnologia” estão atualmente agrupadas em divs, em vez de serem estruturadas como uma lista:

    URL

    Sugestão de correção

    • Estruturar as imagens-links como uma lista não ordenada ul li.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #15 O menu mobile está construído de forma inapropriada

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.2

    Quando navegamos com o leitor de ecrã no menu, identifica-se os seguintes problemas:

    • O menu não é identificado como navegação pelo leitor de ecrã. Apesar de existir uma tag nav, o uso de role="dialog" altera a sua semântica.
    • O botão que abre o menu não está dentro da nav, tal como as opções.
    • O botão “Fechar” aparece no final da lista, mas não tem foco do leitor de ecrã. Isso impede o fechamento do menu.

    URL

    Sugestão de correção

    • Remover o atributo role="dialog" da landmark nav. Assim garantimos que o menu seja reconhecido como navegação pelas tecnologias de apoio.
    • O botão deve ser o primeiro elemento interativo quando o menu estiver aberto o fechado. Para isso, é necessário posiciona-lo acima das suas respectivas opções na estrutura HTML.
    • O foco deve respeitar a estrutura implementada: deve ser possível regressar ao botão de abrir/fechar o menu e navegar por todos os elementos interativos usando Tab, Shift+Tab e os comandos dos leitores de ecrã (VoiceOver: VO + setas ←→; NVDA: setas ↓↑).

  • issue #14 Não é possível distinguir o menu principal de outras navegações

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.2

    Quando navegamos com o leitor de ecrã, identificam‑se duas áreas de navegação: a do menu principal e a do rodapé. No entanto, não é possível distingui‑las corretamente porque não estão nomeadas de forma apropriada:

    Image

    Leitor de ecrã anuncia menu principal como "navegação"

    Image

    Leitor de ecrã anuncia opções do rodapé como "navegação"

    URL

    Sugestão de correção

    • As duas navegações nav deverão ter um nome apropriado. Para isso, recomendamos utilizar o atributo aria-label (exemplo: aria-label="Menu").

  • issue #13 Está sendo utilizado atributos inapropriados no menu

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.2

    O atributo aria-haspopup é comumente utilizado na construção de menus do tipo aplicação. O menu principal do website corresponde a um menu de navegação e não a um menu de aplicação e verifica-se que está sendo utilizado o atributo aria-haspopup no menu:

    Image

    URLs

    Sugestão de correção

    • Remover o aria-haspopup do menu desktop e mobile. A informação de que a opcão está aberta ou fechada deve ser transmitida pelo atributo aria-expanded.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #17 Correta existência de h1 nas páginas do website

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 2.1

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

    O website contem 2 cabeçalhos marcados com <h1> na página de acessibilidade.

    Evidência:

    Image

    Figura 1 - Página com 2 cabeçalhos marcados com <h1> .

    URLs a verificar:

    https://polen.fccn.pt/acessibilidade/

    Recomendações:

    • Alterar "Declaração de Acessibilidade e Usabilidade" de <h1> para <h2>.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    etiqueta: melhoriaetiqueta: chk 10 webetiqueta: R 3.2

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

    Notas Gerais

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

    URL a verificar

    Evidências:

    Após a subscrição do newsletter:

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

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

    Image

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

    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

  • issue #22 Legenda da tabela não marcada com o elemento <caption>

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 3.2

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

    As tabelas de dados devem incluir uma legenda identificada através do elemento , que descreva de forma clara o conteúdo e propósito da tabela. Sempre que aplicável, a legenda deve também indicar a fonte da informação apresentada.
    Na tabela analisada, verifica-se a ausência do elemento <caption>.

    Evidências:

    Image

    Figura 1 - Descrição da tabela sem o elemento <caption> .

    URLs a verificar:

    https://polen.fccn.pt/politica-de-cookies/

    Recomendações:

    • Alterar o texto "Tabela com nome dos cookies analíticos e a descrição da sua função" para o elemento <caption> .

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 #67 Existem textos de etiquetas que não estão visíveis no ecrã

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

    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 span com uma classe screen-reader-text.
    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 formulário de pesquisa existe um elemento span que apresenta duas informações distintas dependendo do agente: para os leitores de ecrã apresenta o texto “search” e visualmente apresenta uma lupa. O texto deste elemento span é redundante para os utilizadores de leitores de ecrã, pois já existe uma etiqueta com texto idêntico e visível para estas tecnologias.
    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 ícone do span acima referido.

    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 <span class="icon-material icon-search" data-icon="search">) devem ser considerados decorativos, através do atributo aria-hidden = “true”.

  • issue #54 Existem campos de formulário sem legenda

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

    Todos os campos devem ter uma legenda breve e clara associada, que descreva quais os tipos de dados que devem ser inseridos nesse mesmo campo.

    Verificámos que as listas suspensas “Filtrar por”, das páginas Notícias e Eventos, não têm uma legenda associada. Isto pode ser especialmente confuso para quem navega no site através de tecnologias de apoio.

    Recomendamos que estes campos sejam reformulados e que seja adicionada uma legenda. Para mais informações podem também consultar o conteúdo, dentro do cabeçalho de nível 2 “Select Menus”, da página Creating Accessible Forms da WebAIM.

    Image

    Figura 1 - Análise da lista suspensa "Filtrar por", na página Eventos, através do Google Inspector.

    Image

    Figura 2 - Análise da lista suspensa "Filtrar por", na página Notícias, através do Google Inspector.

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 #69 Identificação inacessível do campo obrigatório “Email” no formulário da Newsletter

    etiqueta: R 4.2etiqueta: melhoriaetiqueta: chk 10 web

    É 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 de subscrição da Newsletter — acessível através da hiperligação “Newsletter FCCN” presente no rodapé do site — verificámos que o símbolo “*” associado ao campo obrigatório “Email” está colocado depois do elemento , em vez de aparecer junto ao rótulo do campo. Além disso, a imagem utilizada para representar esse símbolo não possui texto alternativo.

    Recomendamos que esta imagem seja substituída pelo um símbolo textual de um asterisco (“*”), colocado depois do rótulo do campo, tal como acontece nos restantes campos obrigatórios. Esta alteração garante uma identificação clara e consistente do caráter obrigatório do campo, tanto visualmente como para tecnologias de apoio.

    Image

    Figura - Formulário Subscrever Newsletter. A imagem SVG do asterisco, colocada após o <input> do campo "Email", está destacada através de um retângulo de borda preta.

  • issue #68 Há campos obrigatórios que não estão indicados como tal

    etiqueta: R 4.2etiqueta: NOKetiqueta: chk 10 web

    É 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 dos formulários devem estar devidamente construídos e identificados como obrigatórios.

    No formulário da página Contactos, o leitor de ecrã não reconhece o campo de seleção “Tomei conhecimento da política de privacidade” como obrigatório.

    Os campos obrigatórios devem incluir o atributo required para serem identificados pelas tecnologias de apoio como obrigatórios.

    Adicionalmente, deve também ser apresentada uma indicação visual clara junto ao rótulo — neste caso, e tal como acontece nos restantes campos obrigatórios do formulário, deve ser adicionado um * em frente ao rótulo— para que todos os utilizadores consigam identificar que este também é um campo de preenchimento obrigatório.

    Image

    Figura 1 - Análise do formulário da página Contactos. Ao tentar submeter o formulário sem selecionar o campo de confirmação “Tomei conhecimento da política de privacidade”, é apresentada a mensagem de erro “Tem de aceitar os termos e condições antes de enviar a sua mensagem.”. Isto demonstra que o campo é obrigatório.

    Image

    Figura 2 - Análise do campo “Tomei conhecimento da política de privacidade”, do formulário da página Contactos, através do Google Inspector.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #70 Existem Mensagens de erro junto aos campos que estão escondidas das tecnologias de apoio

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

    As mensagens de erro apresentadas junto aos campos do formulário contactos estão escondidas das tecnologias de apoio:

    Image

    Mensagem de erro escondida das tecnologias de apoio através de aria-hidden = “true”
    As mensagens de erro devem ser apresentadas junto aos campos e, adicionalmente (é útil no caso da existência de um número elevado de campos no formulário), pode ser apresentada uma lista no topo do formulário com o sumário dos vários erros.
    Neste caso, é apresentada uma lista sumária dos erros no topo, que está visível apenas para os leitores de ecrã:

    Image

    Lista de mensagens de erro no topo visível apenas para os leitores de ecrã
    As mensagens de erro devem ser apresentadas para todos os agentes, de forma a minimizar diferenças na experiência de navegação entre os utilizadores com e sem tecnologias de apoio.

    Recomendamos que sejam apresentadas mensagens de erro junto aos campos de todos os formulários, visíveis para todos os agentes, para assim forenecerem apoio na correção dos mesmos e consequente submissão correta dos formulários.
    Adicionalmente, pode existir uma lista dos erros no topo de cada formulário que consolida os vários erros existentes, em que cada mensagem deve remeter para o respetivo campo (por exemplo, através da colocação da mensagem num link cujo href contenha o id do respetivo campo).

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #27 O gráfico não apresenta uma descrição longa associada

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 5.2

    Evidências:

    Verifica-se que o gráfico está a utilizar um texto alternativo excessivamente extenso, com uma descrição longa inserida diretamente no atributo alt. O alt deve fornecer apenas uma identificação breve e objetiva do conteúdo visual, não devendo concentrar explicações detalhadas, contexto alargado ou descrições extensas. Nesse caso a descrição longa pode estar associada via aria-describedby.

    Image

    Gráfico contém descrição longa incorretamente associada ao atributo alt (acima de 120 caracteres).

    Image

    Outro exemplo são as imagens da sessão História, apresenta a descrição longa associada ao atributo alt.

    Image

    Verifica-se que o gráfico é apresentado apenas através de imagem, sem descrição longa ou alternativa textual equivalente que permita compreender a informação visual disponibilizada. Embora a imagem possua texto alternativo, este limita-se a uma identificação breve do gráfico e não transmite os dados, a distribuição geográfica nem a relação entre as diferentes edições representadas visualmente.

    Image

    URL:
    https://polen.fccn.pt/atividades/pncadai/
    https://polen.fccn.pt/atividades/forum-gdi/

    Recomendações:

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #56 Texto normal não têm contraste suficiente em mensagens de erro dos formulários

    etiqueta: NOKetiqueta: 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

    Notas gerais

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

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

    O website apresenta problemas de contraste na página Contactos para os textos normais das mensagens de erro, pois utilizam a combinação de cores #FF0302(cor de primeiro plano) e #FFFFFF(cor de plano de fundo). (Figura 1)

    Image

    Figura 1- Mensagens de erro do formulário de Contactos com problemas de contraste

    Outro exemplo de formulário com problemas de contraste na mensagem de erro:


    Recomendações
    Recomendamos a revisão das cores das páginas as combinações de cores utilizadas em texto normal incluindo estados das mensagens de erro, para garantir os valores mínimos de contraste entre os pares cores (cor de primeiro plano e cor de plano de fundo) para assegurar visibilidade do conteúdo para todos os utilizadores.

    Outras evidências (OK)
na avaliação de contraste:

  • issue #55 Contraste insuficiente em textos dos diagramas

    etiqueta: NOKetiqueta: 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

    Na página Programa Nacional de Ciência Aberta e Dados Abertos de Investigação (PNCADAI), verifica‑se a existência de texto normal apresentado nas secções “COMO FUNCIONA” e “EIXOS DE AÇÃO” com contraste insuficiente em relação ao plano de fundo.

    O texto encontra‑se representado com a cor #FFFFFF (branco) sobre um plano de fundo com a cor #04AA0E (verde). Esta combinação apresenta uma taxa de contraste aproximada de 3,1:1, valor que não cumpre o requisito mínimo o presente requisito para texto normal. (Figura 1)


    Image

    Figura 1- Diagramas apresentam textos com taxa de contraste inferior ao recomendado

    Em alguns momentos da interação, com o conteúdo do diagrama há informações com baixa opacidade para simular estados e destacar informações em detrimento de outras no diagrama. (Figura 2)

    Image

    Figura 2- Cores do diagrama com baixa opacidade nas cores e com contraste inferior ao recomendado

    Esta implementação impacta na acessibilidade da informação e pode dificultar significativamente a leitura do conteúdo por utilizadores com baixa visão, daltonismo, ou em condições ambientais desfavoráveis, como a incidência de luz no ecrã, comprometendo a perceção dos estados e compreensão da informação transmitida pelo diagrama.

    Recomendação de melhoria
    Recomenda‑se o ajuste da combinação de cores utilizada no texto ou no plano de fundo das referidas secções da imagem, de modo a garantir uma taxa de contraste mínima de 4,5:1 para texto normal.

    • Sempre que possível, evitar texto embutido em imagens e disponibilizar a informação em formato de texto HTML, permitindo melhor adaptação a tecnologias de apoio.

Requisito 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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #57 Contraste insuficiente em títulos numéricos

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

    Na página inicial e na página POLEN DataHub - Área Geral, identificam‑se títulos numéricos com contraste insuficiente face ao respectivo plano de fundo. Os números são apresentados em cor branca (#FFFFFF) sobre um fundo verde (#1DCB27).

    Image

    Figura 1 - Taxa de contraste 2,2:1, valor que não cumpre os requisitos mínimos de contraste

    Recomendação de melhoria
    Recomenda‑se a revisão da combinação de cores utilizada nos títulos numéricos, para garantir os valores mínimos de contraste do texto grande, e assegurar uma leitura clara e acessível.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #76 Conteúdo de gestão de cookies apresentado fora da ordem lógica de leitura

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.2

    Quando se retira a CSS, a informação aparece numa ordem lógica.
    – ver requisito 8.2 na lista 10 aspetos

    Notas Gerais

    • A ordem dos conteúdos no DOM deve refletir uma sequência lógica de leitura e navegação.

    • Componentes funcionais apresentados de forma contextual ao utilizador devem ocupar uma posição coerente na estrutura da página, para que a sua localização seja previsível tanto na leitura linear como no acesso por tecnologias de apoio.

    URL a verificar

    Evidências:

    • O componente de gestão de cookies encontra-se inserido estruturalmente após o footer, no final do DOM.
    • Apesar de visualmente ser apresentado como um elemento contextual e imediato, a sua posição no código faz com que surja apenas no final da sequência de leitura linear da página.
    • Como consequência, utilizadores que navegam pela ordem estrutural do conteúdo podem encontrar este componente apenas depois de percorrer toda a página, o que prejudica a previsibilidade da localização e a compreensão da ordem lógica da informação.
    Image

    Figura 1 - Componente de gestão de cookies inserido no DOM após o footer.

    Recomendações

    • Posicionar o componente de gestão de cookies numa zona estrutural coerente com o momento em que é apresentado ao utilizador. Como por exemplo no footer ou final do main.
    • Garantir que a ordem do DOM acompanha a ordem funcional de interação
    • Evitar inserir componentes contextuais apenas no final da estrutura da página quando a sua utilização é imediata
    • Validar a sequência de leitura linear com tecnologias de apoio

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 #33 Conteúdos com elementos textuais ocultos e não expostos de forma acessível

    etiqueta: NOKetiqueta: chk 10 webetiqueta: 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 conteúdos apresentados na página devem estar estruturados de forma semanticamente coerente e acessível, garantindo que a informação disponível no DOM corresponde à informação efetivamente exposta a utilizadores e tecnologias de apoio.

    URL a verificar

    Evidências:

    Em componentes de conteúdos estruturados (ex.: cards de informação), existem elementos adicionais no DOM com conteúdo textual que se encontram ocultos através de display: none.

    Estes elementos não são acessíveis a tecnologias de apoio, não fazem parte do fluxo de leitura e, em alguns casos, apresentam conteúdo mal formatado com entidades HTML escapadas, não sendo interpretado como conteúdo legível.

    Adicionalmente, em alguns casos, o texto surge no código como conteúdo HTML escapado, sendo apresentado como texto literal em vez de estrutura HTML interpretável.

    Como consequência, existe inconsistência entre a estrutura de conteúdos presente no DOM e a informação efetivamente disponibilizada de forma acessível.

    Image

    Figura 1 - Elemento de conteúdo oculto através de display: none, não acessível a leitores de ecrã.

    Recomendações:

    • Remover elementos textuais ocultos que não façam parte da experiência acessível
    • Garantir que a informação relevante é exposta apenas através de estruturas semanticamente válidas
    • Evitar duplicação de conteúdo entre elementos visíveis e elementos ocultos
    • Corrigir situações em que conteúdo HTML é inserido como texto literal no DOM
    • Validar a leitura dos conteúdos com tecnologias de apoio

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

    etiqueta: NOKetiqueta: chk 10 webetiqueta: 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 página de notícias, cada item é apresentado como um conjunto de conteúdos relacionados (imagem, data, título, descrição e ligação para detalhe), estruturado com múltiplos elementos <div>.

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

    Image

    Figura 1 – Listagem de 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 #42 Quando a caixa de diálogo é aberta, o foco não move-se para dentro da caixa de diálogo

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 9.1

    Evidências:
    Quando a caixa de diálogo é ativada, o foco do navegador mantem-se no botão "Configuração de Cookies", em vez de ser posicionado no primeiro elemento interativo da modal — o botão “Fechar”.

    Image

    Verificou-se ainda que a modal “Detalhes”, aberta através do botão “Mostrar Detalhes”, não é acessível a leitor de ecrã, não sendo possível aceder nem navegar pelo seu conteúdo.

    Image

    URL:
    https://polen.fccn.pt/

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

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

    URL:
    https://polen.fccn.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 #44 (Melhoria) A caixa dialogo não pode ser encerrada através da tecla ESC

    etiqueta: melhoriaetiqueta: chk 10 webetiqueta: R 9.3

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

    Image Image

    URL:
    https://polen.fccn.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 #45 Quando a caixa de diálogo fecha, o foco não volta ao elemento interativo que o invocou.

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 9.4

    Evidências:
    Verificado que ao fechar a modal o foco não retorna ao elemento que a acionou. Fica posicionado de forma inconsistente na página prejudicando a navegação por tecnologias de apoio.

    Image

    URL:
    https://polen.fccn.pt/

    Recomendações:

    • Recomenda-se que ao fechar a modal, o foco seja devolvido ao elemento que a acionou. No caso da modal de cookies, deve ter o foco direcionado para o link de saltar conteúdo principal.

Checklist Conteúdo

etiqueta: NOK

Nível de conformidade:

  • Checklist Conteúdo: 47.1% (8/17)
    • Requisitos avaliados: 17 (17 aplicáveis)
    • Requisitos OK: 8
    • Requisitos NOK: 9

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:

Requisito 1.4 - A informação sobre a entidade responsável pelo conteúdo está em todas as páginas

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #51 Informação da Entidade Responsável Não Escrita por Extenso

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

    A informação sobre a entidade responsável pelo conteúdo está em todas as páginas.
    – ver requisito 1.4 na lista Conteúdo

    Evidências:

    Todas as páginas devem apresentar o nome da entidade responsável pelos conteúdos publicados no site. O nome da entidade pode ser apresentado através de um logótipo ou texto, mas deve estar por extenso.

    Apesar de existir no rodapé o logótipo da entidade e um acesso rápido aos contactos, verifica-se que o nome da entidade responsável não se encontra indicado de forma completa, sendo apenas apresentada a menção “© 2026 FCCN-FCT”, o que pode não ser suficientemente claro para todos os utilizadores.

    Os direitos da entidade responsável pelo conteúdo está presente em todas as páginas no rodapé do website do POLEN.

    Image

    Imagem do rodapé com os direitos não escritos por extenso.

    Recomendações:

    Deve ser adicionado o nome da entidade por extenso em todo o website, como é possível observar no acessibilidade.gov.pt:

    Image

    Imagem de exemplo do rodapé do acessibilidade.gov.pt

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

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

    O tipo de letra do corpo do documento é adequado e o tamanho da letra é, no mínimo, de 12 pontos.
    – ver requisito 2.1 na lista Conteúdo

    Notas Gerais

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

    Verificamos que, ao alterar a resolução para uma mais pequena mobile, iPad mini e iphone por exemplo, o corpo de texto do conteúdo ficou desformatado e com uma dimensão inferior ao recomendado, com apenas 14px. (Figura 1, 2 e 3)

    Image

    Figura 1 - Corpo de texto com dimensão inferior ao recomendado

    Image

    Figura 2 - Textos do rodapé com dimensão variável e inferior ao recomendado em versões mobile na página

    Image

    Figura 3 - Verificação do texto no menu da página notícias com texto variável e tamanho de letra 14px inferior ao recomendado

    Recomendação

    As páginas devem ser revistas e adaptadas de modo a assegurar que o conteúdo se reorganiza corretamente e permanece totalmente utilizável em diferentes resoluções, tamanhos e orientações de ecrã, sem perda de informação ou funcionalidade.

  • issue #28 Há informações no corpo de texto com um tamanho inferior a 12pt (equivalente a 16px)

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

    O tipo de letra do corpo do documento é adequado e o tamanho da letra é, no mínimo, de 12 pontos.
    – ver requisito 2.1 na lista Conteúdo

    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 a modal de cookies disponível em todas as páginas. Por exemplo na página Sobre, as informações primárias como os textos informativos e o textos das labels das checkbox apresentam tamanho de 12px inferior ao recomendado. (Figura 1)

    Image

    Figura 1 - Verificação do tamanho de texto para aceitação dos cookies

    O mesmo problema acontece nos botões “Aceitar todos” e “Recusar todos” com dimensão de apenas 14px. (Figura 2)

    Image

    Figura 2 - Verificação do tamanho de texto nos botões da modal de cookies

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

Requisito 2.2 - A informação secundária (datas, autores) utiliza, no mínimo, um tamanho de letra de 10 pontos

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

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

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

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

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

    Notas gerais

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

    Evidência 01:
    Há blocos de textos nas página Participação
    OSTrails, por exemplo na secção “Piloto Nacional OSTrails” em que o espaçamento entre linhas é de 27.84px para um tamanho de letra de 24px. (Figura 1)



    Image

    Figura 1 - Textos com espaçamento inferior ao recomendado.

    Outros exemplos de páginas com o mesmo problema:

    Recomendação

    Para a evidência 01 apresentada, o espaçamento deveria ser, no mínimo 36px. 
É necessário rever todo website para garantir o espaçamento mínimo recomendado, relativo ao tamanho da letra.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #61 Hiperligações percetíveis apenas com hover

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

    As hiperligações de texto não devem ser diferenciadas apenas com base na cor.
    – ver requisito 3.3 na lista Conteúdo

    Evidências:

    Foram identificadas diversas hiperligações que dependem exclusivamente da cor para se distinguirem do restante conteúdo. Em muitos casos, o sublinhado apenas é exibido ao passar o cursor (hover), o que dificulta a identificação imediata de elementos clicáveis, especialmente para utilizadores com limitações visuais ou dificuldades de perceção de cor.

    Os links devem apresentar uma indicação visual adicional além da cor, visível de forma persistente, sem exigir interação do utilizador. A ausência dessa distinção pode comprometer a compreensão e a navegação no conteúdo.

    Image

    Imagem do título das "Atualidades" com indicação visual apenas em hover

    Image

    Imagem da hiperligação de texto no header com indicação visual apenas em hover.

    Image

    Imagem de diversas hiperligações do rodapé com indicação visual apenas em hover.

    Recomendações:

    • Garantir que todas as hiperligações possuem um indicador visual persistente, como sublinhado, independentemente de hover.
    • Evitar depender exclusivamente da cor para diferenciar links do texto normal.
    • Assegurar contraste adequado entre links e texto circundante, conforme os requisitos de acessibilidade.
    • Validar que estilos de foco (focus) também são visíveis e consistentes para navegação por teclado.

  • issue #60 Hiperligações apresentam-se de forma diferente pelo website

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

    As hiperligações de texto não devem ser diferenciadas apenas com base na cor.
    – ver requisito 3.3 na lista Conteúdo

    Evidências:

    Atualmente, no website da POLEN, as hiperligações não seguem um padrão consistente de apresentação, o que pode comprometer tanto a experiência do utilizador como a acessibilidade. Esta inconsistência torna mais difícil para os utilizadores reconhecerem o que é clicável, especialmente para pessoas com limitações visuais ou dificuldades na perceção de cor.

    Image

    Figura 01: Imagem de um tipo de hiperligação usado no website. Disponível na página do EOSC.

    Image

    Figura 02: Imagem de outro tipo de hiperligação usado no website. Disponível na página dos contactos.

    Recomendações:

    Definir um estilo único e consistente para todas as hiperligações, garantindo que:

    • Não dependem exclusivamente da cor (ex: incluir sublinhado, negrito ou outro indicador visual)
    • São facilmente distinguíveis do restante texto
    • Garantir consistência da cor e forma entre todas as hiperligações ao longo do website e entre os diferentes browsers.
      Aplicar esse estilo de forma uniforme em todo o website

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 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 #37 Elementos interativos com dimensão inferior ao mínimo recomendado

    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

    Ponto 01
    Página: https://polen.fccn.pt/

    Os ícones interativos (setas) associados aos cards (ex.: POLEN Blueprint, POLEN Sync, POLEN DataHub) apresentam uma dimensão de 32px, inferior ao mínimo recomendado para elementos interativos.

    Ícones interativos em forma de seta associados aos cards com dimensão de 32px, inferior ao mínimo recomendado para elementos clicáveis

    Figura 01 – Ícones interativos (setas) com dimensão de 32px, inferior ao mínimo recomendado.

    Outros exemplos
    https://polen.fccn.pt/sobre/
    https://polen.fccn.pt/atividades/
    https://polen.fccn.pt/atividades/forum-gdi/
    https://polen.fccn.pt/servicos/
    https://polen.fccn.pt/participacao/
    https://polen.fccn.pt/participacao/eosc/
    https://polen.fccn.pt/atualidade/noticias/
    https://polen.fccn.pt/atualidade/eventos/

    Recomendação
    Recomenda-se que os elementos interativos tenham uma dimensão mínima de 44px , garantindo uma área de toque adequada e facilitando a interação em diferentes dispositivos, especialmente em contextos de utilização por toque.

    Ponto 02
    Página: https://polen.fccn.pt/contactos/

    No formulário de contacto, o elemento checkbox presente no formulário apresenta uma dimensão de 22px, inferior ao mínimo recomendado para elementos interativos

    Elemento checkbox no formulário de contacto com dimensão de 22px, inferior ao mínimo recomendado para elementos interativos

    Figura 02 – Checkbox no formulário de contacto com dimensão inferior ao mínimo recomendado para elementos interativos.

    Recomendação
    Devem garantir que os elementos interativos têm uma altura e largura igual ou superior a 44px de área clicável, mesmo que o ícone tenha um tamanho inferior.

    Ponto 03
    Página: https://polen.fccn.pt/atividades/pncadai/

    Os indicadores (bolinhas) do carrossel na secção “Eixos de Ação”, em dispositivos móveis, apresentam uma dimensão de 20px, inferior ao mínimo recomendado para elementos interativos.

    Indicadores do carrossel na secção Eixos de Ação em dispositivos móveis com dimensão de 20px, inferior ao mínimo recomendado para elementos interativos

    Figura 03 – Indicadores do carrossel com dimensão inferior ao recomendado.

    Reocmendação
    Aumentar a área clicável dos elementos para pelo menos 44px (altura e largura), garantindo melhor usabilidade em dispositivos de toque.

    Ponto 04
    Página: https://polen.fccn.pt/servico/polen-blueprint/

    Na página “Polen Blueprint”, os ícones interativos (setas) associados aos cards nas secções “Para quem – Áreas” e “Apoio – Documentação de Apoio” apresentam dimensões de 22x25px, inferiores ao mínimo recomendado para elementos interativos.

    Ícones interativos em forma de seta associados aos cards na secção Para quem – Áreas com dimensão aproximada de 22x25px, inferior ao mínimo recomendado

    Figura 04 – Ícones interativos com dimensão inferior ao mínimo recomendado na secção “Para quem – Áreas”.

    Ícones interativos em forma de seta associados aos cards na secção Apoio – Documentação de Apoio com dimensão aproximada de 22x25px, inferior ao mínimo recomendado

    Figura 05 – Ícones interativos com dimensão inferior ao mínimo recomendado na secção “Apoio – Documentação de Apoio”.

    Outros exemplos
    https://polen.fccn.pt/servico/polen-sync/
    https://polen.fccn.pt/servico/polen-datahub/

    Recomendação
    Aumentar a área clicável dos ícones para pelo menos 44px, garantindo melhor acessibilidade e facilidade de interação em dispositivos de toque.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #39 Elementos clicáveis sem indicação visual consistente de interação

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

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

    Ponto 01
    Página: https://polen.fccn.pt/

    Os ícones de redes sociais no rodapé não apresentam qualquer indicação visual de interatividade, nem no estado normal nem em hover, não sendo percecionáveis como elementos clicáveis.

    Ícones de redes sociais no rodapé sem indicadores visuais permanentes de interatividade no estado normal

    Figura 03 – Ícones de redes sociais no rodapé sem indicação visual permanente de interatividade.

    Outros exemplos
    https://polen.fccn.pt/fct-promove-webinar-ciencia-aberta-em-expansao-novos-modelos-avaliacao-e-dados-abertos/
    https://polen.fccn.pt/fct-recebe-a-visita-da-delegacao-brasileira-da-fundacao-oswaldo-cruz/
    https://polen.fccn.pt/fct-coorganiza-15a-conferencia-lusofona-de-ciencia-aberta/
    http://polen.fccn.pt/fct-participa-na-primeira-sessao-do-programa-internacional-de-suporte-para-iniciativas-nacionais-fair-impact/

    Recomendação
    Recomenda-se a introdução de indicadores visuais de interatividade (ex.: alteração de cor, contraste, contorno ou efeito visual) no estado normal e/ou em hover, de forma a tornar os elementos percecionáveis como clicáveis.

    Ponto 02
    Página: https://polen.fccn.pt/sobre/

    Na secção “História do POLEN” é apresentada uma componente do tipo timeline, estruturada através de cards que representam a evolução temporal do conteúdo. No entanto, esta componente apresenta inconsistências na interação e na sua interpretação.

    As bolinhas posicionadas acima dos cards sugerem uma progressão ou navegação entre etapas, mas são estáticas e não acompanham qualquer interação com o conteúdo. Adicionalmente, a utilização de cards com um estilo visual semelhante a outros elementos clicáveis presentes na mesma página contribui para a criação de expectativa de interatividade, que não se verifica neste caso.

    Secção História do POLEN apresentada em formato de etapas visuais em bolhas, com aparência interativa mas sem funcionalidade clicável

    Figura 04 – Secção “História do POLEN” com elementos visuais em etapas sem funcionalidade interativa.

    Recomendação
    Alinhar a componente com um comportamento consistente: se não houver interação, reduzir a aparência de elementos clicáveis; caso contrário, implementar interação coerente entre os indicadores (bolinhas) e os cards.

    Ponto 03
    Página: https://polen.fccn.pt/atualidade/eventos/

    Na página “Eventos”, os controlos do carrossel (setas e indicadores numéricos) não apresentam indicação visual de interatividade no estado normal ou em hover, sendo apenas alterados após clique.

    Controlos do carrossel na página Eventos sem indicação visual de interatividade no estado normal ou em hover, apenas alterando após clique

    Figura 06– Controlos do carrossel sem indicação visual de interatividade no estado normal ou em hover.

    Recomendação
    Adicionar indicadores visuais de interatividade no estado normal e/ou hover (ex.: mudança de cor, contraste, cursor pointer ou efeito visual), de forma a tornar os elementos percecionáveis como clicáveis antes da interação.

Checklist Transação

etiqueta: NOK

Nível de conformidade:

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

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 #7 Não foram encontrados formulários com mais de 2 ecrãs

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

    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 2 ecrãs de altura no Projeto POLEN. Desta forma, este requisito é avaliado como "Não aplicável".

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 #8 Não foram encontrados formulários com mais de uma página

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

    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 dentro do Projeto POLEN. Assim, este requisito fica avaliado como "Não Aplicável".

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    etiqueta: chk transaçãoetiqueta: melhoriaetiqueta: 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.

    No formulário de subscrição da Newsletter — acessível através da hiperligação “Newsletter FCCN” no rodapé do site — os campos “Nome” e “Email” apresentam uma largura excessiva, que não corresponde ao tamanho habitual da informação a inserir.

    Recomendamos que seja reajustada a largura destes campos de forma a refletir, de forma mais adequada, o conteúdo esperado.

    Image

    Figura - Formulário para subscrição da Newsletter.

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

    etiqueta: NOKetiqueta: chk transaçãoetiqueta: 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.

    No caso do formulário da página Contactos, a largura dos campos não reflete o tamanho previsível dos dados. O campo 'Nome' deve ter largura suficiente para acomodar, no limite, o nome completo do utilizador. No entanto, este campo tem sensivelmente metade da largura dos campos “Email”, “Instituição” e “Assunto”.

    Assim, recomendamos reformular este campo para ter, no mínimo, a mesma largura dos campos “Email”, “Instituição” e “Assunto”.

    Image

    Figura - Formulário da página Contactos. O campo "Nome" está destacado através de um retângulo de borda preta.

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

etiqueta: N/A

Lista de evidências recolhidas:

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

    No Projeto POLEN, 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:

  • issue #35 A legenda do campo não está visível

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

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

    Verificámos que, quando se expande o campo de pesquisa geral, através do botão “Botão de pesquisa”, o rótulo do campo não está visível na interface gráfica. Através da classe "screen-reader-text", associada ao elemento <span> dentro do label, a expressão “Pesquisar por:” está a ser passada a leitores de ecrã mas não está visível na interface gráfica.

    Recomendamos que o campo seja reformulado para que o rótulo esteja sempre visível quer visualmente na interface gráfica quer para as tecnologias de apoio.

    Image

    Figura - Análise do campo de pesquisa geral através do Google Inspector.

  • issue #34 Existem campos de formulário sem legenda

    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

    Todos os campos devem ter uma legenda breve e clara associada, que descreva quais os tipos de dados que devem ser inseridos nesse mesmo campo.

    Verificámos que as listas suspensas “Filtrar por”, das páginas Notícias e Eventos, não têm uma legenda associada. Isto pode ser especialmente confuso para quem navega no site através de tecnologias de apoio.

    Recomendamos que estes campos sejam reformulados e que seja adicionada uma legenda. Para mais informações podem também consultar o conteúdo, dentro do cabeçalho de nível 2 “Select Menus”, da página Creating Accessible Forms da WebAIM.

    Image

    Figura 1 - Análise da lista suspensa "Filtrar por", na página Eventos, através do Google Inspector.

    Image

    Figura 2 - Análise da lista suspensa "Filtrar por", na página Notícias, através do Google Inspector.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #52 Identificação inacessível do campo obrigatório “Email” no formulário da Newsletter

    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 de subscrição da Newsletter — acessível através da hiperligação “Newsletter FCCN” presente no rodapé do site — verificámos que o símbolo “*” associado ao campo obrigatório “Email” está colocado depois do elemento , em vez de aparecer junto ao rótulo do campo. Além disso, a imagem utilizada para representar esse símbolo não possui texto alternativo.

    Recomendamos que esta imagem seja substituída pelo um símbolo textual de um asterisco (“*”), colocado depois do rótulo do campo, tal como acontece nos restantes campos obrigatórios. Esta alteração garante uma identificação clara e consistente do caráter obrigatório do campo, tanto visualmente como para tecnologias de apoio.

    Image

    Figura - Formulário Subscrever Newsletter. A imagem SVG do asterisco, colocada após o <input> do campo "Email", está destacada através de um retângulo de borda preta.

  • issue #40 Há campos obrigatórios que não estão indicados como tal

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

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

    Os campos dos formulários devem estar devidamente construídos e identificados como obrigatórios.

    No formulário da página Contactos, o leitor de ecrã não reconhece o campo de seleção “Tomei conhecimento da política de privacidade” como obrigatório.

    Os campos obrigatórios devem incluir o atributo required para serem identificados pelas tecnologias de apoio como obrigatórios.

    Adicionalmente, deve também ser apresentada uma indicação visual clara junto ao rótulo — neste caso, e tal como acontece nos restantes campos obrigatórios do formulário, deve ser adicionado um * em frente ao rótulo— para que todos os utilizadores consigam identificar que este também é um campo de preenchimento obrigatório.

    Image

    Figura 1 - Análise do formulário da página Contactos. Ao tentar submeter o formulário sem selecionar o campo de confirmação “Tomei conhecimento da política de privacidade”, é apresentada a mensagem de erro “Tem de aceitar os termos e condições antes de enviar a sua mensagem.”. Isto demonstra que o campo é obrigatório.

    Image

    Figura 2 - Análise do campo “Tomei conhecimento da política de privacidade”, do formulário da página Contactos, através do Google Inspector.

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

etiqueta: N/A

Lista de evidências recolhidas:

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

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

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

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

    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 #71 Existem Mensagens de erro junto aos campos que estão escondidas das tecnologias de apoio

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

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

    As mensagens de erro apresentadas junto aos campos do formulário contactos estão escondidas das tecnologias de apoio:

    Image

    Mensagem de erro escondida das tecnologias de apoio através de aria-hidden = “true”
    As mensagens de erro devem ser apresentadas junto aos campos e, adicionalmente (é útil no caso da existência de um número elevado de campos no formulário), pode ser apresentada uma lista no topo do formulário com o sumário dos vários erros.
    Neste caso, é apresentada uma lista sumária dos erros no topo, que está visível apenas para os leitores de ecrã:

    Image

    Lista de mensagens de erro no topo visível apenas para os leitores de ecrã
    As mensagens de erro devem ser apresentadas para todos os agentes, de forma a minimizar diferenças na experiência de navegação entre os utilizadores com e sem tecnologias de apoio.

    Recomendamos que sejam apresentadas mensagens de erro junto aos campos de todos os formulários, visíveis para todos os agentes, para assim forenecerem apoio na correção dos mesmos e consequente submissão correta dos formulários.
    Adicionalmente, pode existir uma lista dos erros no topo de cada formulário que consolida os vários erros existentes, em que cada mensagem deve remeter para o respetivo campo (por exemplo, através da colocação da mensagem num link cujo href contenha o id do respetivo campo).

    Recomendamos ainda que as mensagens de erro sejam programaticamente associadas aos respetivos campos, para que os utilizadores que navegam por teclado (tab e shift+tab) e leitor de ecrã possam ouvir a mensagem de erro associada a cada campo à medida que o foco passa pelos campos. A mensagem a associar programaticamente a cada campo deve ser a que se encontra junto do mesmo.
    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" class="popupMessage themeGreen">Email não válido</div>

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

etiqueta: NOK

Lista de evidências recolhidas:

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

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

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

    A mensagem de erro “Por favor, introduza um email válido” presente no formulário contactos não ajuda no preenchimento do campo:

    Image

    _ Mensagem de erro no topo da página que não guia o utilizador na resolução do erro_
    Como observado na figura, a mensagem “Por favor, introduza um email válido” que é apresentada quando o campo foi preenchido com um formato incorreto não indica qual o formato a ser inserido, não ajudando a preencher o campo.
    Recomendamos rever todos os formulários do website para garantir que as mensagens de erro apresentadas expliquem para o utilizador como preencher os campos corretamente.

Outras violações

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

Lista de evidências recolhidas:

  • issue #66 Outras violações - Botão anunciado pelo leitor de ecrã em inglês

    etiqueta: outras violaçõesetiqueta: melhoria
    Descrição da problemática

    Na página European Open Science Cloud (EOSC) o botão “Site EOSC” é anunciado pelo leitor de ecrã com o texto em inglês data-icon="open_in_new". Quando um leitor de ecrã anuncia o valor de um data-icon (por exemplo, “open_in_new”), tal indica que o elemento não dispõe de um nome acessível adequada alternativa textual correta. (Figura 1)

    Image

    Figura 1 - Leitura da página com o leitor de ecrã NVDA

    Um data-icon é apenas um identificador técnico utilizado para associar um ícone a um elemento da interface e não possui significado semântico para as tecnologias de apoio. (Figura 2)

    Image

    Figura 2 - Verificação do ícone do botão com atributo data-icon

    Esta situação compromete a acessibilidade e a compreensão da interface, uma vez que o feedback fornecido ao utilizador é técnico, pouco descritivo e, neste caso, apresentado em inglês, enquanto o idioma principal do website é o português. Consequentemente, a navegação torna‑se mais difícil para utilizadores de leitores de ecrã.

    Recomendação de melhoria
    Garantir que todos os controlos interativos botões possuem um nome acessível claro, descritivo e no idioma do website, utilizando texto visível ou atributos ARIA apropriados (por exemplo, aria-label ou aria-labelledby).

    • Os ícones puramente decorativos devem ser ocultados das tecnologias de apoio (aria-hidden="true"), assegurando que o leitor de ecrã anuncia apenas a função do elemento (por exemplo, “Abrir site do EOSC”). Desta forma, evita‑se a exposição de identificadores técnicos e promove‑se uma experiência de navegação consistente, compreensível e alinhada com os requisitos de acessibilidade.

  • issue #65 Outras violações - Há hiperligações que redirecionam para páginas de erro

    etiqueta: outras violaçõesetiqueta: melhoria

    Descrição da problemática
    A página Participação possui uma hiperligação que aponta para um conteúdo inexistente, originando uma página de erro 404. Ao selecionar o card “Grupo de trabalho” o utilizador é redirecionado para página de erro e recebe a mensagem de “Parece que uma página que você procura ainda não existe ou não está disponível neste momento..” (Figura 1)



    Image

    Figura 1 - Página de erro para conteúdo do Grupo de trabalho

    Esta situação impede o acesso à informação e constitui uma barreira significativa na acessibilidade do conteúdo.

    Recomendação de melhoria
    Recomenda‑se atualizar todas as hiperligações para garantir que apontam para conteúdos atualizados e disponíveis no website.

  • issue #64 Outras Violações - Conteúdos multilíngue no corpo do texto

    etiqueta: outras violaçõesetiqueta: melhoria

    Descrição da problemática:

    • Existem conteúdos apresentados em inglês no website cujo idioma principal é o português, gerando inconsistência linguística e potencial dificuldade de compreensão para os utilizadores.

    Foi identificada uma inconsistência linguística no website. Na página Política de Cookies, a tabela de conteúdos encontra‑se em inglês, apesar de o restante conteúdo da página estar em português (Figura 1).

    Image

    Figura 1 - Conteúdo da secção "8.Cookies analíticos" com tabela cujos textos estão em inglês

    Situação semelhante ocorre na página POLEN DataHub, onde se verifica a mistura de conteúdos em inglês e em português no corpo do texto (Figura 2).

    Image

    Figura 2 - Informações sobre a "Versão" do sistema POLEN DataHub estão em inglês

    Esta inconsistência pode dificultar a compreensão da informação, afetar a experiência do utilizador e comprometer a acessibilidade e coerência do website.

    Recomendação de melhoria
    Deve ser assegurada a uniformização do idioma em cada página ou, em alternativa, implementados mecanismos claros de identificação e seleção de língua, garantindo que o idioma do conteúdo corresponde ao idioma principal do website ou às preferências do utilizador.

Significado das etiquetas utilizadas