Relatório Avaliação da Candidatura da BIP - Barómetro para a Qualidade da Informação

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

Lista de evidências recolhidas:

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

  etiqueta: R 1.2etiqueta: chk 10 webetiqueta: melhoria

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

  • Ver requisito 1.2 da lista 10 aspetos

  Quando se navega pelo menu principal com o teclado, não é possível passar de uma opção de primeiro nível x para outra opção de primeiro nível y sem antes passar por todas as opções de segundo nível da opção x.

  

  menu principal

  O sub-menu não deve abrir automaticamente quando se navega por teclado (tab e shift+tab), para não tornar obrigatória a sua leitura antes de ir para a próxima opção.
  Por seu turno, se for utilizada a navegação por elementos dos leitores de ecrã, as opções não são automaticamente expandidas (podem ser expandidas utilizando o enter), mas os utilizadores destas tecnologias não têm uma perceção direta de quais as opções que têm ou não subopções.

  Posto isto, as melhorias devem garantir:

  • Que as opções de 1º nível do menu fiquem colapsadas até o utilizador escolher aceder às subopções com a tecla “Enter”, quer se navegue com tab e shift+tab, quer se navegue com as ferramentas disponibilizadas pelos leitores de ecrã.

  • Que as opções de 1º nível colapsem quando o foco do teclado não está numa delas.

  • Que seja possível sair das subopções com a tecla “Escape”.
    Para garantir esse comportamento, as opções de 1º nível do menu de navegação devem ter:

  • o atributo ARIA “aria-expanded” para as tecnologias de apoio identificarem que existem subopções e quando o menu está colapsado (aria-expanded=”false”) ou expandido (aria-expanded=”true”).

  • o atributo ARIA “aria-current” para as tecnologias de apoio identificarem estruturalmente em qual das opções do menu é que o utilizador se encontra.

  Em alternativa ao atributo aria-expanded, é possível implementar, como texto alternativo das setas associadas aos links de opções com subopções, o texto “tem submenu”. Desta forma já será possível, pelo menos, perceber quais as opções com subopções.

  Para mais informação sobre boas práticas de implementação dos menus e submenus, podem consultar a Ligação Fly-out Menus da W3C.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue#24 Inexistência de imagens link no menu principal

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

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

  • Ver requisito 1.3 da lista 10 aspetos

  Não encontrámos imagens link no menu principal, pelo que este requisito é não aplicável.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#19 Página inicial não tem h1

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 2.1

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

  • Ver requisito 2.1 da lista 10 aspetos

  As páginas do website devem ter apenas um <h1> atribuído. Este elemento deve ser apenas atribuído a títulos relevantes na estrutura da página, e não a textos genéricos, botões ou outro conteúdo.
  Nas páginas interiores, o <h1> deve estar atribuído ao título do conteúdo principal dessa página. Já na homepage, o <h1> deve estar atribuído ao logótipo para, em conjunto com um texto alternativo correto, melhorar o SEO da página.
  Verificamos que na página inicial não existe qualquer cabeçalho <h1>.

  

  Página inicial sem h1

  Como se observa na figura, a hierarquia de cabeçalhos da página inicial começa com h2.
  Recomendamos a implementação de um cabeçalho de nível 1 na página inicial, no local do logotipo, de forma a que haja uma associação entre os dois, e a alteração do texto alternativo do logotipo para “BIP – Barómetro para a Qualidade da Informação”, conforme o seguinte exemplo:

  <h1>
  
  
  <!-- IMAGE_PLACEHOLDER_1 -->
  
  
  </h1>
  

  Já nas páginas interiores, o logotipo é tratado de modo diferente.
  Nas páginas interiores, o logotipo deve permanecer como está, num link para a página inicial e sem qualquer cabeçalho, mas o seu texto alternativo deve ser, por exemplo, ”Ir para a página principal do BIP – Barómetro para a Qualidade da Informação”.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#18 Existem textos que não precisam ser cabeçalhos

  etiqueta: R 2.2etiqueta: chk 10 webetiqueta: NOK

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

  Os cards existentes na secção “Conheça a Equipa BIP” possuem eleementos que não precisam ser cabeçalhos.

  

  Texto que não precisa ser cabeçalho

  O texto associado ao cargo de cada membro da equipa não precisa ser cabeçalho, mas apenas um elemento <p>.
  O mesmo acontece na página equipa.

  

  Recomendamos a restruturação da hierarqia de cabeçalhos, de forma a remover todos os cabeçalhos que não são necessários à hierarquia. No caso do problema aqui apresentado, os cabeçalhos correspondentes aos cargos podem ser transformados em elementos <p>.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#13 Existem etiquetas que desaparecem ao focar os respetivos campos ou que não estão visíveis

  etiqueta: R 4.1etiqueta: chk 10 webetiqueta: 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 etiqueta “Email” presente no formulário de subscrição de newsletters da página inicial desaparece quando o campo é focado:

  

  Etiqueta email desaparece quando o campo é focado

  O mesmo acontece no formulário Newsletter:

  A etiqueta do campo de pesquisa presente na página notícias nunca está visível.

  

  Etiqueta não visível do campo de pesquisa

  Recomendamos que as etiquetas estejam sempre visíveis nos formulários e associadas aos respetivos campos, para que os utilizadores de tecnologias de apoio possam saber a qualquer momento em que campo se encontram.

• evidência: issue#12 Existem etiquetas que não estão associadas aos respetivos campos

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

  Alguns campos do formulário Como avalia a qualidade da informação fornecida ao público pelas candidaturas, na campanha para as eleições autárquicas de outubro de 2025?, Como “Naturalidade” e “Idade”, não têm id, apesar de terem elementos <label> com atributo for.

  

  Campos com label a referenciarem ids que não existem

  O atributo for dos labels destes campos remete para ids inexistentes, o que faz com que as etiquetas não estejam associadas aos campos, não sendo por isso anunciadas às tecnologias de apoio ao navegar com tab e shift+tab.
  Recomendamos a associação das etiquetas de todos os formulários aos respetivos campos, ou utilizando ids nos campos e atributos for nos labels que remetam para esses ids (forma explícita), ou colocando os campos dentro das etiquetas <label> (forma implícita).

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#15 As opções dos radio buttons não estão sendo identificados como obrigatórios pelas tecnologias de apoio

  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

  No formulário Como avalia a qualidade da informação fornecida ao público pelas candidaturas, na campanha para as eleições autárquicas de outubro de 2025?, existem opções apresentadas em formato de radio buttons. A escolha de uma destas opções é obrigatória. Quando se navega com um leitor de ecrã, a indicação de que a seleção é obrigatória é anunciada apenas ao aceder ao grupo de opções pela primeira vez. Ao percorrer individualmente cada opção dentro do mesmo grupo, o leitor de ecrã não repete a indicação de obrigatoriedade (necessário):

  

  Radio buttons sem atributo required

  Para além disso, verificámos que todos os outros campos obrigatórios possuem o atributo required, pelo que convém manter a coerência também nos radio buttons.

  Assim, recomendamos reverem de forma geral o website para garantir que radio buttons estejam corretamente construídos. Para isso, cada input deverá conter o atributo required.

• evidência: issue#14 R 4.2 - 10 Aspetos – Formulários sem indicação da função do *

  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

  O formulário Como avalia a qualidade da informação fornecida ao público pelas candidaturas, na campanha para as eleições autárquicas de outubro de 2025? Não refere que o asterisco denota campos de preenchimento obrigatório.

  

  Formulário sem indicação de que o * denota campos de preenchimento obrigatório

  Recomendamos que seja fornecida indicação do que se trata o asterisco, sendo que essa indicação deve constar, preferencialmente, no topo do formulário.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#16 Existem formulários que não apresentam mensagens de erro de forma consistente

  etiqueta: chk 10 webetiqueta: R 4.3etiqueta: NOK

  É 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 Como avalia a qualidade da informação fornecida ao público pelas candidaturas, na campanha para as eleições autárquicas de outubro de 2025? Apresenta um comportamento inconsistente no que respeita à apresentação de mensagens de erro.
  Se o formulário for submetido sem qualquer campo preenchido, o foco vai para o campo “Local de Residência” em vez de ir para o grupo de radio buttons, e é apresentada uma mensagem de erro “Preencha o campo” que não aparece na árvore DOM, não sendo apresentadas mensagens de erro para todos os outros campos.

  

  Formulário sem qualquer campo preenchido

  Ao submeter o formulário tendo preenchido os campos “Local de Residência” e “Idade”, são apresentadas no DOM as mensagens de erro correspondentes ao não preenchimento de cada campo obrigatório, mas não para todos esses campos.

  

  Formulário após submissão, com dois campos preenchidos

  Recomendamos que, para todos os formulários do site, sejam apresentadas mensagens de erro por cada campo preenchido incorretamente, que essas mensagens de erro fiquem na vizinhança de cada campo para que sejam facilmente percecionadas pelos utilizadores de tecnologias de apoio.
  Para além disso, as mensagens devem ser apresentadas todas de uma vez, não podendo haver situações em que as mensagens de erro de campos incorretamente preenchidos só sejam apresentadas mediante certas condições.

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

Lista de evidências recolhidas:

• evidência: issue#20 Há imagens decorativas com texto alternativo incorreto

  etiqueta: chk 10 webetiqueta: R 5.1etiqueta: melhoria

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

  As imagens decorativas não acrescentam informação ao conteúdo da página, costumando estar acompanhadas de uma descrição textual ou servirem para tornar a página mais apelativa. Estas imagens podem conter um texto alternativo nulo (alt=””) no HTML, ou estarem apenas como background-image em CSS.

  Na página inicial, há uma imagem decorativa, ao lado do cabeçalho <h1> “Barómetro para a Qualidade da Informação”, que tem associado o texto alternativo alt = "Barómetro para a Qualidade da Informação".

  Recomendamos a revisão das imagens decorativas para que incluam um texto alternativo nulo da seguinte forma: <img…alt=””>. Em alternativa, estas podem ser colocadas em CSS como background-image.

  

  Figura – Análise da imagem com o texto alternativo “Barómetro para a Qualidade da Informação”, na página inicial ao lado do cabeçalho <h1> “Barómetro para a Qualidade da Informação”, através do leitor de ecrã NVDA. A leitura que o NVDA faz desta imagem está destacada através de um retângulo de borda preta.

• evidência: issue#11 As imagens decorativas dos cards contêm texto alternativo que repete a informação do card

  etiqueta: chk 10 webetiqueta: R 5.1etiqueta: melhoria

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

  No caso das imagens dos cards que sejam acompanhadas de texto, devem ser consideradas como decorativas e não funcionais. Sendo assim, o seu texto alternativo deve ser nulo ou devem ser adicionadas como background-image em CSS.

  Na página inicial, num dos cards que aparecem abaixo do cabeçalho <h2> “Notícias mais Recentes”, o texto alternativo da imagem decorativa é igual ao texto do cabeçalho <h3> desse mesmo card — “A interação com a informação através de information avoidance”.

  Para evitar que o leitor de ecrã repita várias vezes a mesma informação, as imagens dos cards devem ser consideradas como decorativas e colocado o texto alternativo nulo da seguinte forma: (alt=””). Outra forma é adicionar as imagens via CSS.

  Para esta situação, deve-se também utilizar a técnica do link esticado, garantindo assim que o leitor de ecrã lê a informação relevante apenas uma vez.

  

  Figura - Análise do texto alternativo da imagem presente no card abaixo do cabeçalho <h2> “Notícias mais Recentes”, realizada através do Google Inspector. O texto alternativo atribuído à imagem é idêntico ao cabeçalho <h3> do próprio card — “A interação com a informação através de information avoidance”. O atributo alt da imagem está destacado através de um retângulo de borda preta.

• evidência: issue#1 Há imagens informativas que possuem um texto alternativo incorreto

  etiqueta: chk 10 webetiqueta: R 5.1etiqueta: melhoria

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

  O texto alternativo deve ser curto, objetivo e descrever de forma sintética o conteúdo da imagem.

  No rodapé do site, verificámos que os logótipos dos patrocinadores têm textos alternativos que começam com a palavra “Logo” — por exemplo, “Logo Compete 2020” ou “Logo Portugal 2020”.

  Para imagens que representam logótipos, não é necessário incluir termos como “logo” ou “logótipo”. Nestes casos, recomendamos que seja atribuído ao texto alternativo da imagem o nome por extenso da entidade que representa – por exemplo “Compete 2020” ou “Fundação para a Ciência e a Tecnologia”.

  

  Figura - Análise do texto alternativo dos logótipos dos patrocinadores no rodapé do site usando o Google Inspector. O atributo alt destas imagens está destacado através de retângulos de borda preta.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue#35 Não foram encontrados gráficos complexos

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

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

  Não foram encontrados gráficos complexos dentro do domínio do site Barómetro para a Qualidade de Informação.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#3 As imagens-link possuem um texto alternativo incorreto

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.3

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

  As imagens-link são links cujo conteúdo é composto por uma imagem e devem ser corretamente legendadas para serem interpretadas como texto quando são lidas pelas tecnologias de apoio. O texto alternativo deve ser curto, claro e servir de síntese do seu conteúdo.

  Verificámos que, no cabeçalho do site, o texto alternativo das imagens link que representam os ícones das redes sociais Instagram, Facebook e LinkedIn está incorreto. Tomando como exemplo o primeiro caso — o ícone do Instagram — o texto alternativo atualmente associado é alt="Seguir o BIP no Instagram". Este texto é inadequado por três razões principais:

  1. Ao selecionar esta imagem link, o utilizador não passa a “seguir” o BIP no Instagram – é simplesmente encaminhado para uma página externa.
  2. Embora o texto alternativo mencione o “BIP”, a hiperligação associada conduz, na realidade, para a página do Centro de Estudos de Comunicação e Sociedade da Universidade do Minho (href="https://www.instagram.com/cecs_uminho/"). Esta discrepância pode induzir o utilizador em erro e tornar se particularmente confusa para pessoas que utilizam leitores de ecrã.
  3. A sigla “BIP” pode não ser reconhecida pelo utilizador, que pode não saber ao que se refere.

  Recomendamos que os textos alternativos destas imagens link sejam reestruturados. O texto alternativo deve indicar claramente a ação desencadeada pela interação e identificar, por extenso, o nome da entidade a que a hiperligação remete. Por exemplo, “Ir para a página oficial do Barómetro para a Qualidade da Informação no Instagram”.

  Além disso, o valor do atributo href deve ser corrigido para garantir que a hiperligação corresponde exatamente à entidade mencionada no texto alternativo.

  Por fim, no caso de imagens link que direcionam para páginas externas — como acontece com estes logótipos presentes no cabeçalho — recomenda-se a inclusão do atributo title na hiperligação, de forma a informar o utilizador de que está a sair do site. Por exemplo, <a href="..." title="Ir para página externa">.

  

  Figura 1 - Análise dos ícones das redes sociais, presentes no cabeçalho do site, através do Google Inspector. Os atributos aria-label associados a estes elementos estão destacados através de um retângulo de borda preta.

  

  Figura 2 - Análise dos ícones das redes sociais, presentes no cabeçalho do site, através do leitor de ecrã NVDA. O valor dos atributos aria-label associado a estes elementos, e que é lido pelo leitor de ecrã, está destacado através de retângulos de borda preta.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#7 O texto normal não tem contraste suficiente

  etiqueta: R 6.1etiqueta: chk 10 webetiqueta: NOK

  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

  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.

  Verificámos que, na página Perguntas Frequentes, o texto que se encontra imediatamente abaixo do cabeçalho <h1> “Perguntas Frequentes”, tem um contraste com o fundo abaixo do recomendado. O texto cinzento-claro (#9F9F9F) tem com o fundo cinzento muito claro (#F5F5F5) um rácio de contraste de 2,4:1.

  Recomendamos a revisão das cores para garantir os valores mínimos de contraste do texto normal. Neste caso, uma possível solução seria utilizar um tom de cinzento mais escuro para a cor do texto, de forma a cumprir o nível mínimo de contraste de 4,5:1.

  

  Figura - Análise do contraste entre o texto abaixo do cabeçalho <h1> "Perguntas Frequentes" e o fundo, na página Perguntas Frequentes, através da ferramenta Colour Contrast Analyser.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#36 Existem áudios sem legenda ou transcrição

  etiqueta: chk 10 webetiqueta: R 7.2etiqueta: NOK

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

  O EPISÓDIO 04 - A ferrovia na região do Minho do podcast “Estados do Tempo” não tem legenda ou transcrição.

  

  Áudio sem legenda ou transcrição

  Recomendamos que procedam à disponibilização da transcrição deste áudio e transcrições de áudios futuros, tal como fizeram nos três primeiros episódios.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#74 Itens não estruturados numa lista ul li

  etiqueta: chk 10 webetiqueta: R 8.3etiqueta: melhoria

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

  Os itens de cada painel de acordeão da página Bibliografia não estão estruturados em listas ul li.

  

  itens da página bibliografia não estruturados como lista ul li

  Se para alguém que não tem uma deficiência conhecida consegue facilmente navegar, através da visão, entre os vários itens da bibliografia, quanto mais não seja por intermédio de cada autor que está em negrito, isso não é tão simples de realizar por alguém com deficiência visual.
  Se cada item da bibliografia for o item de uma lista, os utilizadores de leitores de ecrã conseguirão navegar de item para item, e portanto perceber mais facilmente onde começa cada um deles, ao invés de terem de navegar por todo o texto a perceber a estrutura de cada item para entenderem onde inicia cada um.
  Recomendamos a implementação de uma lista ul li em cada painel de acordeão, estruturando cada grupo de elementos em cada lista.

• evidência: issue#22 Existem carrosséis estruturados de forma incorreta

  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

  Os elementos do carrossel da secção “Conheça a Equipa BIP” na página inicial são todos apresentados às tecnologias de apoio, em vez de serem apresentados em grupos de cinco.

  

  Carrossel mostra todos os elementos às tecnologias de apoio

  Neste caso, o recuo ou avanço através dos botões do carrossel não tem qualquer impacto nas tecnologias de apoio, pois as mesmas veem sempre todos os elementos.
  Tal situação modifica a experiência de navegação dos utilizadores destas tecnologias, que se distancia daquela obtida por quem não as utiliza.
  Recomendamos a restruturação deste carrossel e de outros nas mesmas condições, de modo a que a visualização dos itens seja a mesma para qualquer utilizador, e a funcionalidade de avanço e de recuo deve-se refletir na visualização para todos.
  Para além disso, sendo os links dos cards apresentados de forma consecutiva, esses links devem ser estruturados numa lista um li.

  Para mais informações é possível consultar os artigos Carousel Structure e Carousel (Slide Show or Image Rotator) Pattern do W3C.

• evidência: issue#21 Existem acordeões estruturados incorretamente

  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

  A página bibliografia contém acordeões estruturados incorretamente.

  

  Acordeões existentes na página bibliografia

  Verificámos que Os painéis com os conteúdos dos acordeões estão todos visíveis para as tecnologias de apoio, mesmo quando os acordeões estão recolhidos.
  Tal situação impacta negativamente na experiência de navegação para os utilizadores destas tecnologias, que visualizam sempre todo o conteúdo, desvirtuando a funcionalidade oferecida pelos acordeões.
  Recomendamos que seja utilizado um mecanismo que oculte o conteúdo dos acordeões para todos os agentes, por exemplo, o uso de display: none para ocultar e display: block para mostrar.
  Para além disso, os controlos de expansão com cada letra do alfabeto foram implementados recorrendo a elementos <span>, que não possuem mecanismos nativos de acessibilidade que permitam que sejam identificados quais os controlos destes elementos, nem são focáveis por teclado. A única informação que os leitores de ecrã transmitem sobre estes elementos, através da navegação por elementos, é que se tratam de elementos clicáveis, sem anunciarem se os acordeões correspondentes estão recolhidos ou expandidos.
  Assim, recomendamos a restruturação de todos os acordeões, da seguinte forma:

  • Os elementos <span> devem ser substituídos por elementos <button> nativos do html, que já trazem todos os mecanismos de acessibilidade. A única coisa que é necessário acrescentar aos botões para transmitir a indicação de expansão ou recolhimento de cada acordeão passa pela introdução de um atributo aria-expanded em cada botão, que deve assumir o valor false caso o acordeão esteja recolhido, e true caso esteja expandido;
  • Deve ser adicionado um atributo aria-controls a cada botão, com o valor "ID-painel", que referencia o id do painel do acordeon que o botão controla;
  • Os textos descritivos dos botões (letras do alfabeto) são considerados títulos de secção, pelo que os botões devem ser colocados em elementos cabeçalho, neste caso <h2>.

  Para obtenção de informação mais detalhada acerca da construção correta de acordeões, recomendamos a consulta de um exemplo de acordeon na página do W3C.

• evidência: issue#17 Existem campos de formulário estruturados incorretamente

  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

  O campo associado à etiqueta “Nível de escolaridade” presente no formulário Como avalia a qualidade da informação fornecida ao público pelas candidaturas, na campanha para as eleições autárquicas de outubro de 2025? Foi estruturado incorretamente.

  

  Campo estruturado incorretamente

  Este campo foi personalizado com controlos não nativos de formulário, nomeadamente uma lista ul li que contém as várias opções, sem qualquer enriquecimento de acessibilidade que permita que seja anunciado o tipo de controlo às tecnologias de apoio, e que permita que os utilizadores de teclado consigam navegar pelo controlo (tab e shift+tab e setas). De facto, o controlo em si pode ser focado, mas isso não acontece com as várias opções aí existentes.
  O mesmo problema acontece no campo de ordenação existente na página barómetro

  Recomendamos que estes controlos personalizados sejam estruturados com elementos combobox nativos, ou que procedam ao enriquecimento dos controlos personalizados com todas as propriedades de acessibilidade que façam equivaler estes controlos a comboboxes nativas.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue#25 Inexistência de modais

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

  Quando a caixa de diálogo é aberta, o foco (cursor do Browser) move-se para um elemento dentro da caixa de diálogo
  – ver requisito 9.1 na lista 10 aspetos

  Não encontrámos modais no site, pelo que este requisito é não aplicável.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue#26 Inexistência de modais

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

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

  Não encontrámos modais no site, pelo que este requisito é não aplicável.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue#27 Inexistência de modais

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

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

  Não encontrámos modais no site, pelo que este requisito é não aplicável.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue#28 Inexistência de modais

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

  Quando a caixa de diálogo fecha, o foco (cursor do Browser) deve voltar ao elemento interativo que a invocou
  – ver requisito 9.4 na lista 10 aspetos

  Não encontrámos modais no site, pelo que este requisito é não aplicável.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#30 Não existe um resumo do propósito do site na homepage

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 1.1

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

  O website BIP – Barómetro para a Qualidade da Informação não apresenta um resumo do propósito na página inicial, pelo que deve ser adicionado:

  

  Página inicial não possui uma frase que explique o propósito do website

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

  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:

  

  Exemplo de uma frase de propósito do website acessibilidade.gov

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#34 Existem abreviações / siglas sem definição

  etiqueta: R 1.2etiqueta: chk conteúdoetiqueta: NOK

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

  Não foi identificado qualquer glossário no website, apesar de serem utilizados, em várias páginas, termos, siglas e abreviaturas cujo significado não é explícito:

  

  Siglas CECS e ICS aparecem em outros locais no website

  

  Não existe um glossário para explicar o significado do termo sondagem e barômetro

  Recomenda-se a criação de uma página com um glossário que agregue os termos complexos e a sua definição. Pode ser utilizado como referência o glossário do site da Acessibilidade: https://www.acessibilidade.gov.pt/glossario/

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: 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

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

  Verificámos que nas páginas Podcast, Objetivos, Política de Privacidade, página inicial e no rodapé do site existem conteúdos cujo tamanho de letra está abaixo do recomendado, pelo que deverá ser corrigido para um tamanho igual ou superior ao requerido.

  

  Figura 1 - Análise do texto nos cards abaixo do cabeçalho de nível 2 'Notícias mais Recentes', na página inicial, através do Google Inspector. Texto analisado tem o tamanho de 13px. Tamanho do texto está destacado através de um retângulo de borda preta.

  

  Figura 2 - Análise do texto nos cards abaixo do cabeçalho de nível 2 'Objetivos do BIP', na página Objetivos, através do Google Inspector. Texto analisado tem o tamanho de 14px. Tamanho do texto está destacado através de um retângulo de borda preta.

  

  Figura 3 - Análise do texto abaixo do cabeçalho de nível 3 'A ferrovia na região do Minho', na página Podcast, através do Google Inspector. Texto analisado tem o tamanho de 14px. Tamanho do texto está destacado através de um retângulo de borda preta.

  

  Figura 4 - Análise do conteúdo dentro da tabela "Tabela de Cookies", na página Política de Privacidade, através do Google Inspector. O texto que incorpora as células de dados da tabela tem 10px.

  

  Figura 5 - Análise do item de navegação "Sondagem" presente no rodapé do site. Texto analisado tem o tamanho de 12px. Tamanho do texto está destacado através de um retângulo de borda preta

  

  Figura 6 - Análise do tamanho do texto de aviso no elemento <small>, localizado abaixo do <h3> “Fique a par das novidades ao assinar a nossa Newsletter”, no rodapé do site através do Google Inspector. O tamanho deste texto é de 11px. O tamanho do texto está destacado através de um retângulo de borda preta.

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: R 2.2etiqueta: chk conteúdoetiqueta: NOK

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

  Para garantir a legibilidade da informação secundária, esta deve ter um tamanho de letra igual ou superior a 13px (10pt).

  Verificámos que o tamanho do texto utilizado nas breadcrumbs do site (10px) e no texto de Copyright do rodapé (11px) está abaixo do tamanho recomendado, pelo que deverá ser ajustado para um tamanho igual ou superior a 10pt (13px).

  

  Figura 1 - Análise do tamanho do texto das breadcrumbs através do Google Inspector. Tamanho do texto está destacado através de um retângulo de bordas pretas.

  

  Figura 2 - Análise do tamanho do texto do Copyright através do Google Inspector. Tamanho do texto está destacado através de um retângulo de bordas pretas.

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 2.3

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

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

  Verificámos que, por exemplo, no texto dentro do acordeão “Il barometro dell’odio” da página Projetos Análogos, há blocos de texto com mais de 100 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) para garantir que não é ultrapassado o número máximo de caracteres por linha.

  

  Figura - Análise da quarta linha do texto dentro do acordeão “Il barometro dell’odio” da página Projetos Análogos. Esta linha tem 117 caracteres (sem espaços) e 140 caracteres (com espaços).

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#64 O índice está a ser substituído por acordeões que não estão estruturados corretamente

  etiqueta: R 4.1etiqueta: chk conteúdoetiqueta: NOK

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

  Na página bibliografia é possível verificar que o conteúdo apresentado ultrapassa a altura de três ecrãs. Para contornar esta situação, foi implementado um mecanismo de acordeões, que não estão a funcionar corretamente.

  

  Aceitamos que sejam utilizados acordeões em vez de um índice no topo, mas os mesmos têm de ser bem implementados.
  Recomendamos rever os acordeões do website para garantir que sejam estruturados corretamente. Para isso, recomendamos consultarem as notas partilhadas no critério 8.3 da checklist dos 10 aspectos sobre como corrigir o acordeão.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#5 Há elementos interativos com área clicável que não cumprem a dimensão mínima exigida

  etiqueta: R 5.2etiqueta: chk conteúdoetiqueta: NOK

  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

  Para garantir que os utilizadores interagem devidamente com um elemento interativo (botões, imagens-link...), a área clicável desse elemento deve ser, no mínimo, 44px de largura e 44px de altura.

  Verificámos que os seguintes elementos não cumprem a dimensão mínima exigida:

  • Os botões “Aumentar fonte” e “Diminuir fonte”, presentes no cabeçalho e no rodapé, com 27 px de largura por 27px de altura.
  • A imagem link “Ir para o conteúdo principal”, no cabeçalho da página, com 27 px de largura por 27px de altura.
  • A imagem link “Voltar à Página Inicial”, no início das breadcrumbs, com 26 px de largura por 26px de altura.
  • Os botões das redes sociais no cabeçalho, cada um com18px de largura por 27px de altura.

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

  

  Figura 1 - Análise do botão "Aumentar fonte", presente no cabeçalho do site, através do Google Inspector. Tamanho do elemento está destacado através de retângulo de borda preta.

  

  Figura 2 - Análise do botão "Aumentar fonte", presente no rodapé do site, através do Google Inspector. Tamanho do elemento está destacado através de retângulo de borda preta.

  

  Figura 3 - Análise da imagem-link "Ir para o conteúdo principal", presente no cabeçalho do site, através do Google Inspector. Tamanho do elemento está destacado através de retângulo de borda preta.

  

  Figura 4 - Análise da imagem-link "Voltar à Página Inicial", presente no início das beadcrumbs, através do Google Inspector. Tamanho do elemento está destacado através de retângulo de borda preta.

  

  Figura 5 - Análise do botão "Seguir o BIP no Facebook", presente no cabeçalho do site, através do Google Inspector. Tamanho do elemento está destacado através de retângulo de borda preta.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue#65 Inexistência de formulários com mais de dois ecrãs de altura

  etiqueta: R 1.2etiqueta: chk transaçãoetiqueta: 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 existem formulários com mais de dois ecrãs de altura, pelo que o requisito não se aplica.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue#73 Inexistência de formulários com mais de uma página

  etiqueta: chk transaçãoetiqueta: N/Aetiqueta: 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 existem formulários com mais de uma página, pelo que o requisito não se aplica.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue#56 Inexistência de revelação progressiva

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

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

  Não existem situações em que seja necessária a aplicação de revelação progressiva, pelo que o requisito não se aplica.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#58 Existem etiquetas que não estão associadas aos respetivos campos

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

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

  Alguns campos do formulário Como avalia a qualidade da informação fornecida ao público pelas candidaturas, na campanha para as eleições autárquicas de outubro de 2025?, Como “Naturalidade” e “Idade”, não têm id, apesar de terem elementos <label> com atributo for.

  

  Campos com label a referenciarem ids que não existem

  O atributo for dos labels destes campos remete para ids inexistentes, o que faz com que as etiquetas não estejam associadas aos campos, não sendo por isso anunciadas às tecnologias de apoio ao navegar com tab e shift+tab.
  Recomendamos a associação das etiquetas de todos os formulários aos respetivos campos, ou utilizando ids nos campos e atributos for nos labels que remetam para esses ids (forma explícita), ou colocando os campos dentro das etiquetas <label> (forma implícita).

• evidência: issue#57 Existem etiquetas que desaparecem ao focar os respetivos campos ou que não estão visíveis

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

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

  A etiqueta “Email” presente no formulário de subscrição de newsletters da página inicial desaparece quando o campo é focado:

  

  Etiqueta email desaparece quando o campo é focado

  O mesmo acontece no formulário Newsletter:

  A etiqueta do campo de pesquisa presente na página notícias nunca está visível.

  

  Etiqueta não visível do campo de pesquisa

  Recomendamos que as etiquetas estejam sempre visíveis nos formulários e associadas aos respetivos campos, para que os utilizadores de tecnologias de apoio possam saber a qualquer momento em que campo se encontram.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#60 Formulários sem indicação da função do *

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

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

  O formulário Como avalia a qualidade da informação fornecida ao público pelas candidaturas, na campanha para as eleições autárquicas de outubro de 2025? Não refere que o asterisco denota campos de preenchimento obrigatório.

  

  Formulário sem indicação de que o * denota campos de preenchimento obrigatório

  Recomendamos que seja fornecida indicação do que se trata o asterisco, sendo que essa indicação deve constar, preferencialmente, no topo do formulário.

• evidência: issue#59 As opções dos radio buttons não estão sendo identificados como obrigatórios pelas tecnologias de apoio

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

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

  No formulário Como avalia a qualidade da informação fornecida ao público pelas candidaturas, na campanha para as eleições autárquicas de outubro de 2025?, existem opções apresentadas em formato de radio buttons. A escolha de uma destas opções é obrigatória. Quando se navega com um leitor de ecrã, a indicação de que a seleção é obrigatória é anunciada apenas ao aceder ao grupo de opções pela primeira vez. Ao percorrer individualmente cada opção dentro do mesmo grupo, o leitor de ecrã não repete a indicação de obrigatoriedade (necessário):

  

  Radio buttons sem atributo required

  Para além disso, verificámos que todos os outros campos obrigatórios possuem o atributo required, pelo que convém manter a coerência também nos radio buttons.

  Assim, recomendamos reverem de forma geral o website para garantir que radio buttons estejam corretamente construídos. Para isso, cada input deverá conter o atributo required.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue#61 Inexistência de formulários que requeiram ações longas

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

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

  Não existem formulários que requeiram ações longas, pelo que o requisito não se aplica.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#70 Não é informado aos leitores de ecrã sobre o sucesso/erro do envio de informações automaticamente

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

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

  Idealmente as mensagens de status devem ser informadas automaticamente para as tecnologias de apoio assim que tiver mudanças na página. As mensagens podem ser determinadas programaticamente de modo que possam ser apresentadas para o utilizador.
  Quando submetemos o formulário de Como avalia a qualidade da informação veiculada através dos anúncios publicitários exibidos na TV nacional, neste Natal? é apresentada uma mensagem de confirmação. No entanto, o foco do leitor de ecrã retorna para o início da página e a mensagem de confirmação não é informada automaticamente.

  

  Mensagem de sucesso de submissão não comunicada automaticamente aos leitores de ecrã

  A mensagem, mesmo não comunicada automaticamente, poderia estar a seguir a um elemento de navegação com forte probabilidade de ser atingido (por exemplo, um cabeçalho), mas isso também não acontece. Assim, os utilizadores de leitor de ecrã podem ter dificuldade em encontrá-la através da navegação pela página.

  Recomendamos rever os formulários para garantir que as mensagens de sucesso/confirmação/problema sejam automaticamente informadas para o leitor de ecrã.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue#66 Não existem formulários que permitam a realização de ações destrutivas

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

  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 encontrámos formulários que permitam a realização de ações destrutivas, pelo que o requisito não se aplica.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#69 Existem mensagens de erro não associadas programaticamente aos respetivos campos

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

  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 referente ao campo de concordância com a política de privacidade, presente no formulário Como avalia a qualidade da informação veiculada através dos anúncios publicitários exibidos na TV nacional, neste Natal? não está associada programaticamente ao mesmo.
  Tal situação dificulta a descoberta desta mensagem de erro por parte dos utilizadores de leitores de ecrã, que precisam de navegar por toda a página para a percecionarem.

  

  Mensagem de erro não associada programaticamente ao campo de concordância com a política de privacidade

  Tal acontece com todos as mensagens de erro deste formulário.

  Recomendamos a revisão dos formulários para garantirem que as mensagens de erro estejam associadas programaticamente a cada campo.
  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>
  

• evidência: issue#68 Existem formulários que não apresentam mensagens de erro de forma consistente

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

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

  O formulário Como avalia a qualidade da informação veiculada através dos anúncios publicitários exibidos na TV nacional, neste Natal? Apresenta um comportamento inconsistente no que respeita à apresentação de mensagens de erro.
  Se o formulário for submetido sem qualquer campo preenchido, o foco vai para o campo “Local de Residência” em vez de ir para o grupo de radio buttons, e é apresentada uma mensagem de erro “Preencha o campo” que não aparece na árvore DOM, não sendo apresentadas mensagens de erro para todos os outros campos.

  

  Formulário sem qualquer campo preenchido

  Ao submeter o formulário tendo preenchido os campos “Local de Residência” e “Idade”, são apresentadas no DOM as mensagens de erro correspondentes ao não preenchimento de cada campo obrigatório, mas não para todos esses campos.

  

  Formulário após submissão, com dois campos preenchidos

  Recomendamos que, para todos os formulários do site, sejam apresentadas mensagens de erro por cada campo preenchido incorretamente, que essas mensagens de erro fiquem na vizinhança de cada campo para que sejam facilmente percecionadas pelos utilizadores de tecnologias de apoio.
  Para além disso, as mensagens devem ser apresentadas todas de uma vez, não podendo haver situações em que as mensagens de erro de campos incorretamente preenchidos só sejam apresentadas mediante certas condições.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#71 Existem mensagens de erro que não ajudam na resolução do problema

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

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

  As mensagens de erro presentes no formulário de subscrição de newsletters Apenas ajudam parcialmente no preenchimento do campo email.

  

  Mensagem de erro que ajuda parcialmente no preenchimento do campo email

  Como observado na figura, a mensagem não indica qual o formato a ser inserido, ajudando apenas de forma parcial a preencher o campo.
  Recomendamos rever todos os formulários do website para garantir que a mensagem de erro apresentada explique para o utilizador como preencher os campos corretamente.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#72 Outras violações - Existem estruturas de navegação com o mesmo nome

  etiqueta: outras violaçõesetiqueta: melhoria

  As navs que contêm as listas dos menus secundários têm o mesmo nome.

  

  As duas navs correspondentes aos menus secundários

  Como se pode observar na figura, as navs que contêm os menus secundários têm ambas o nome “Menu secundário”. Caso o utilizador de leitor de ecrã pretenda listar as várias secções da página, ser-lhe-ão anunciadas duas secções exatamente com o mesmo nome, o que em nada favorece a sua experiência de navegação, pois não é comunicado a que menu secundário é que cada secção diz respeito.

  Recomendamos a alteração dos nomes das navs que contêm os menus secundários de modo a estarem de acordo com o tipo de agregação que a entidade pretendeu ao desenvolver os dois menus. O nome de cada uma pode ser, por exemplo, a concatenação do texto “Menu secundário” com a designação da agregação.

• evidência: issue#10 Outras Violações de Acessibilidade - Há elementos interativos que não têm contraste suficiente

  etiqueta: outras violações

  Elementos interativos devem ter um contraste mínimo de 3:1 para que pessoas com baixa visão os consigam distinguir facilmente.

  Verificámos que na imagem-link “Ir para o conteúdo principal”, presente cabeçalho do site, o contraste entre o ícone e o fundo da imagem-link no estado hover está abaixo do recomendado. Quando o cursor passa sobre este elemento, o ícone que é cinzento muito escuro (#231F20) passa a ter como fundo um cinzento-escuro (#404040), o que resulta num rácio de contraste de apenas 1,6:1, abaixo do mínimo recomendado pelas normas de acessibilidade (3:1).

  Recomendamos ajustar as cores para garantir o contraste mínimo exigido. Uma possível solução é utilizar um fundo mais claro no estado hover ou adicionar uma borda em cinzento-escuro que torne mais evidente que o cursor está sob este elemento.

  

  Figura - Análise do contraste da imagem-link "Ir para o conteúdo principal", no estado hover, através do Colour Contrast Analyser. Elemento está destacado através de um retângulo de bordas roxas.