Relatório Avaliação de Candidatura
Museu do Calçado

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #29 As opções do rodapé não estão estruturadas como lista

  etiqueta: chk 10 webetiqueta: R 1.1etiqueta: NOK

  Quando os links de navegação são estruturados dentro de uma lista, os utilizadores de leitores de ecrã conseguem compreender de forma mais clara a organização e a hierarquia do conteúdo do website. Esta abordagem permite também que o leitor de ecrã anuncie o número total de opções disponíveis.

  O rodapé do website possui links que não estão estruturadas como listas:

  

  URL a verificar

  • https://www.museu-do-calcado.pt/pt/inicio

  Sugestão de correção

  • Estruturar as opções de "Menu", "Morada" e "Contactos" como uma lista ul li no HTML.
  • O grupo de links Termos e Condições, Política de Privacidade, Política de Cookies, Acessibilidade e Livro de - Reclamações Online devem ser estruturados também como lista ul li no HTML.

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 1.2

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

  • Ver requisito 1.2 da lista 10 aspetos

  Evidencias:
  Quando navegamos pelo teclado ou leitor de ecrã, as subopções são apresentadas automaticamente quando estão com foco, sendo obrigatória a sua leitura antes de ir para a próxima opção:

  
  

  URL a verificar

  • https://www.museu-do-calcado.pt/ - menu principal

  Recomendações:

  • No código, é necessário implementar um evento que permita ao atributo aria-expanded mostrar ou esconder as subopções. Para isso, é necessário criar um evento de clique que irá abrir e fechar o sub-menu de acordo com a seleção feita pelo teclado ou leitor de ecrã.
  • Exemplo de construção : https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/examples/disclosure-navigation/

• evidência: issue #33 O menu mobile não está acessível pelo teclado e leitor de ecrã

  etiqueta: chk 10 webetiqueta: R 1.2etiqueta: NOK

  Quando se navega com o leitor de ecrã ou com o teclado, não é possível aceder ao menu apresentado nas versões mobile e tablet. Isto acontece porque o menu está estruturado como uma div no HTML, em vez de ser implementado como um elemento interativo.

  O menu é o principal recurso de navegação do website, mas os leitores de ecrã não conseguem identificá‑lo nem saltar diretamente para ele, uma vez que não está estruturado como um elemento de navegação no HTML.

  

  Menu estruturado como div e não está definido como navegação nav

  Adicionalmente, verifica-se que as opções do menu estão estruturalmente separadas do botão de abrir/fechar menu um problema crítico para navegação por tecnologias de apoio:

  

  URL

  https://www.cm-sjm.pt/pt/inicio - menu mobile e tablet

  Sugestão de correção

  • Estruturar o menu como um button no HTML.
  • O botão deve ser estruturado dentro de uma navegação nav no HTML.
  • As opções do menu devem ser posicionadas estruturalmente a seguir ao botão de menu, garantindo que a ordem de leitura com o leitor de ecrã seja igual à ordem visual. Para mais informações, recomendamos analisar esta questão em conjunto com a issue #53 .

• evidência: issue #32 Não é possível aceder as subopções do menu com o leitor de ecrã e teclado

  etiqueta: chk 10 webetiqueta: R 1.2

  Quando se navega com o teclado e leitor de ecrã utilizando as teclas TAB e SHIFT+TAB, é possível identificar os seguintes problemas:

  1. Não é possível ver as subopções do menu quando navegamos com o teclado através das teclas TAB e SHIFT+TAB. O mesmo acontece com o leitor de ecrã quando navegamos por elementos:

  

  2. Não é possível abrir as subopções do menu mobile/tablet com o leitor de ecrã ou o teclado. Por exemplo, ao selecionar "Sobre o Museu", as suas subopções não são abertas; em vez disso, a página de “Sobre o Museu” é imediatamente carregada.

  

  Ao selecionar a opção "Museu" não abre as subopções

  

  A página "Museu" é apresentada ao invés de abrir as subopções

  Isso acontece porque estão a ser atribuídas duas funções ao mesmo link a: por um lado, ele é utilizado para apresentar as subopções do menu no hover; por outro, é também o elemento responsável por aceder as páginas do website:

  

  URL

  • https://www.cm-sjm.pt/pt/inicio - menu principal desktop, mobile e tablet

  Sugestão de correção

  • É necessário verificar o menu compacto e desktop.
  • O mesmo elemento é utilizado simultaneamente para expandir/contrair subopções e para aceder a página interna, como por exemplo “Museu”, o que provoca erros de navegação. Por esse motivo, devem separar o link de navegação da página interna e do botão de abrir/fechar as subopções.
  • O elemento que abre e fecha as subopções deve ser um botão ▾. Caso optem em utilizar a sinalética ▾ para o botão, devem garantir que tenha um nome acessível apropriado, como por exemplo: "Abrir subopção de Município".
  • Devem utilizar o atributo aria-expanded apropriadamente para que os leitores de ecrã identifiquem se a opção está aberta ou fechada.
  • O acesso as páginas internas deve ser feito através de um link a.
  • Para mais informações partilhamos um exemplo de menu flyout da W3C: https://www.w3.org/WAI/tutorials/menus/flyout/#use-button-as-toggle

• evidência: issue #31 As opções do menu não apresentam uma indicação visual de que contêm subopções

  etiqueta: chk 10 webetiqueta: R 1.2

  As opções do menu devem apresentar uma indicação visual para informar que contêm subopções. Isso permite que as pessoas que navegam com tecnologias de apoio (teclado e leitor de ecrã), com visão ou ambas, identifiquem de forma clara as subopções disponíveis.

  Não é possível identificar que as opções ‘Sobre o Museu’, ‘Serviços’, ‘Programação’ e ‘Visite‑nos’ contêm subopções, uma vez que não é apresentada qualquer sinalética visual que indique essa informação:

  

  URL

  • https://www.museudachapelaria.pt/pt/inicio

  Sugestão de correção

  • Deve ser apresentado uma sinalética visual, como por exemplo ▾, para indicar quais opções do menu contém subopções.
  • Devem analisar a issue #32 , pois trata‑se de correções a serem efetuadas no menu e que estão relacionadas também com este problema.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #34 O menu possui imagens cujo texto alternativo não está apropriado

  etiqueta: chk 10 webetiqueta: R 1.3etiqueta: NOK

  Verifica‑se que não estão a ser utilizadas imagens‑link no menu. Contudo, face aos problemas identificados no menu principal, é aconselhável utilizar uma sinalética visual no elemento de abrir/fechar o menu. Por esse motivo, recomendamos que analisem as seguintes issues:

  • #31
  • #32

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #55 Cabeçalhos vazios

  etiqueta: chk 10 webetiqueta: R 2.2etiqueta: NOK

  Algumas páginas têm cabeçalhos vazios que devem ser removidos.

  Evidencias:

  

  Figura 1 - Cabeçalho vazio(https://www.museu-do-calcado.pt/pt/voluntariado) .

  

  Figura 2 - Cabeçalho vazio(https://www.museu-do-calcado.pt/pt/exposicoes-em-itinerancia) .

  

  Figura 3 - Cabeçalho vazio(https://www.museu-do-calcado.pt/pt/oficinas-residentes) .

  URLs a verificar:
  https://www.museu-do-calcado.pt/pt/voluntariado
  https://www.museu-do-calcado.pt/pt/exposicoes-em-itinerancia
  https://www.museu-do-calcado.pt/pt/oficinas-residentes

  Recomendações:

  • Remover os cabeçalhos vazios dos URLs listados.

etiqueta: N/A

Lista de evidências recolhidas:

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

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

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

  Não foram encontradas tabelas no website, tornando este aspeto N/A.

etiqueta: N/A

Lista de evidências recolhidas:

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

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

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

  Não foram encontradas tabelas no website, tornando este aspeto N/A.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #49 Existem campos com etiquetas pouco claras

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

  O campo “Subscrever newsletter” do formulário de subscrição de newsletter tem um texto que não é claro relativamente à função desse campo:

  

  Texto da etiqueta de campo não clara relativamente à função desse campo
  Devemos salientar que o texto da etiqueta referida deve fornecer a informação correta da função do campo, o que apenas está a ser transmitido pelo texto do atributo placeholder.
  Recomendamos a alteração do texto da etiqueta do campo “Subscrever newsletter” para “Email”.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #48 Existem formulários com a indicação de campo de preenchimento obrigatório duplicada

  etiqueta: chk 10 webetiqueta: R 4.2

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

  Os campos obrigatórios dos formulários devem estar devidamente identificados como tal. Idealmente, devem apresentar o texto “Obrigatório” à frente da legenda do campo. Em alternativa, pode-se colocar um * no campo obrigatório, desde que o significado do * seja mencionado no início do formulário.
  À frente dos rótulos dos campos do formulário de subscrição de newsletter é usado “Obrigatório *”, o que configura uma duplicação da indicação de campo de preenchimento obrigatório.

  

  Campo email do formulário de subscrição de newsletter com a indicação “Obrigatório *”
  O mesmo problema ocorre nos campos de preenchimento obrigatório do formulário Contactos
  Recomendamos que seja usado apenas “(obrigatório)” ou “(campo obrigatório)” à frente dos rótulos dos campos, ou em alternativa o uso do * (desde que a indicação do seu significado conste no topo do formulário).

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

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 4.2

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

  Verificámos que no formulário de subscrição de newsletter os campos não estão identificados programaticamente como obrigatórios.
  Recomendamos que os campos obrigatórios incluam o atributo required para serem identificados pelas tecnologias de apoio como obrigatórios.

  

  Análise do campo "Email", no formulário de subscrição de newsletter através do Google Inspector
  O mesmo problema ocorre nos campos de preenchimento obrigatório do formulário Contactos.

• evidência: issue #44 Existem campos de preenchimento obrigatório sem indicação para as tecnologias de apoio

  etiqueta: chk 10 webetiqueta: R 4.2

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

  O campo de concordância com os termos e condições e política de privacidade do formulário de subscrição de newsletter não tem uma indicação de preenchimento obrigatório que possa ser anunciada pelas tecnologias de apoio.

  

  Campo de preenchimento obrigatório sem essa indicação
  O mesmo problema ocorre no campo de de concordância com os termos e condições e política de privacidade do formulário Contactos
  Recomendamos que seja usado “(obrigatório)” ou “(campo obrigatório)” à frente dos rótulos dos campos, ou em alternativa o uso do * (desde que a indicação do seu significado conste no topo do formulário). Se já existirem campos com a indicação de preenchimento obrigatório, deve ser mantida a coerência na introdução das novas indicações.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #41 Existem formulários sem Mensagens de erro junto aos campos

  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 de subscrição de newsletter não apresenta mensagens de erro junto aos campos:

  

  Campo email do formulário de contactos sem mensagem de erro associada
  A única mensagens de erro apresentada ocorre no topo da página, e é apresentada durante um período de tempo:

  

  Mensagem de erro no topo da página
  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, a localização da mensagem “Erro: insira um email válido” no topo da página associada ao seu curto tempo de permanência no ecrã torna muito difícil a descoberta da mesma por parte dos utilizadores de leitores de ecrã.
  A mesma situação ocorre no formulário contactos, com uma variante: a mensagem de erro é apresentada apenas no topo do formulário.

  

  mensagem de erro no topo do formulário contactos
  Em situações que não conseguimos reproduzir de modo determinístico, a mensagem de erro supra é substituída pela seguinte: “Erro! Erro de validação contra robôs, tente novamente”, que em nosso entender está fora do contexto, pois descreve um erro que o utilizador não vê.

  Recomendamos que sejam apresentadas mensagens de erro junto aos campos de todos os formulários, 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).
  Todas as mensagens de erro devem permanecer no ecrã até que o utilizador atualize a página, de modo a serem lidas o número de vezes que o utilizador pretender.

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

Lista de evidências recolhidas:

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

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 5.1

  Evidências:
  Verifica-se que, em vários componentes do website, as imagens funcionam apenas como apoio visual, encontrando-se a informação relevante já disponibilizada através de título, descrição e links acessíveis em texto. Nestes casos, as imagens podem ser tratadas como decorativas, devendo possuir alt="".

  Um exemplo são os cards da secção Agenda não acrescentam informação relevante ou adicional ao conteúdo textual já disponibilizado (título e descrição do evento). No entanto, estas imagens estão a ser expostas aos leitores de ecrã através de texto alternativo preenchido.

  

  URL:
  https://www.museu-do-calcado.pt/pt/programacao
  https://www.museu-do-calcado.pt/pt/agenda
  https://www.museu-do-calcado.pt/pt/noticias
  https://www.museu-do-calcado.pt/pt/projeto-sapatos-que-pensam
  https://www.museu-do-calcado.pt/pt/conceito-e-vocacao-do-museu
  https://www.museu-do-calcado.pt/pt/voluntariado
  https://www.museu-do-calcado.pt/pt/visitar
  https://www.museu-do-calcado.pt/pt/planear-a-sua-visita
  https://www.museu-do-calcado.pt/pt/publicacoes
  museu-do-calcado.pt/pt/visitas-virtuais/marloes-ten-bhmer-o-ato-de-caminhar
  https://www.museu-do-calcado.pt/pt/noticias

  Recomendações:

  • Recomenda-se que as imagens decorativas tenham alt="".

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #10 Imagem/gráfico não é acompanhada de uma descrição longa

  etiqueta: chk 10 webetiqueta: R 5.2etiqueta: NOK

  Evidências:
  Verifica-se que o texto associado não contempla integralmente a informação presente no banner. Sempre que o banner contenha texto informativo essencial, como datas, horários, programa, contactos ou instruções de inscrição, essa informação deve ser disponibilizada em formato textual acessível no próprio conteúdo da página ou através de uma descrição equivalente associada à imagem.

  

  URL:

  https://www.museu-do-calcado.pt/pt/exposicoes-temporarias
  https://www.museu-do-calcado.pt/pt/noticias/maio-dia-internacional-dos-museus

  Recomendações:

  • A descrição longa pode ser apresentada diretamente no conteúdo da página juntamente com o texto existente.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #9 Existem imagens link com texto alternativo incorreto

  etiqueta: chk 10 webetiqueta: R 5.3etiqueta: NOK

  Evidências:

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

  

  A imagem-link não apresenta um nome acessível adequado, uma vez que o atributo alt descreve apenas o conteúdo visual e não o propósito do link. O link também abre numa nova janela (target="_blank") sem informar explicitamente o utilizador, o que pode causar desorientação, especialmente para utilizadores de tecnologias de apoio. Exemplo de descrição: alt="Aceder ao mapa Morada do museu (abre numa nova janela)".

  

  .

  Verificado também que os componentes de paginação possuem links, mas não possuem texto alternativo que identifique claramente a ação do link.

  

  URL:
  https://www.museu-do-calcado.pt/pt/contactos
  https://www.museu-do-calcado.pt/pt/noticias

  Recomendações:
  O texto alternativo deve transmitir claramente o destino ou finalidade do link. Por exemplo: alt="Museu do Calçado – página inicial"

etiqueta: N/A

Lista de evidências recolhidas:

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

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

  Deve ser possível ativar os botões de controlo do leitor quer com o rato quer com o teclado.
  – ver requisito 7.1 na lista 10 aspetos

  O critério não é aplicável

  O website não disponibiliza conteúdos de vídeo ou áudio com controlos de reprodução, apresentando apenas uma experiência interativa de visita 360º, pelo que este critério não se aplica.

etiqueta: N/A

Lista de evidências recolhidas:

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

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

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

  O Critério é não aplicável

  O website não disponibiliza conteúdos de vídeo ou áudio, pelo que não são necessárias legendas ou transcrição textual.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #53 Ordem lógica do conteúdo comprometida no menu mobile

  etiqueta: 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 do conteúdo no HTML deve refletir uma sequência lógica de leitura, independentemente da apresentação visual. Quando os elementos são posicionados visualmente através de CSS (por exemplo, menus que aparecem no topo), mas estão colocados noutra posição no código, isso pode comprometer a compreensão quando os estilos são desativados ou quando o conteúdo é interpretado por tecnologias de apoio.

  URL a verificar

  • https://www.museu-do-calcado.pt/pt/inicio (em todo o website)

  Evidências:

  As opções do menu mobile encontram-se estruturadas no final do código HTML da página.

  Visualmente, o menu surge no topo da interface, mas ao desativar o CSS ou ao navegar linearmente pelo conteúdo, os itens do menu apenas aparecem depois de todo o restante conteúdo da página.

  Isto compromete a ordem lógica de leitura, uma vez que a navegação principal deveria estar disponível no início da página.

  

  Figura 1 – Opções do menu mobile posicionadas no final do código, surgindo apenas após o restante conteúdo quando o CSS é desativado

  Recomendações:

  • Posicionar o menu de navegação principal no início do HTML, antes do conteúdo principal
  • Evitar depender exclusivamente de CSS para alterar a ordem visual dos elementos
  • Garantir que a ordem no código corresponde à ordem lógica de leitura e navegação

• evidência: issue #52 Ordem de leitura incorreta no formulário de newsletter

  etiqueta: 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 elementos no HTML deve refletir a sequência lógica de interação do utilizador. Quando essa ordem não é respeitada, especialmente em formulários, pode gerar confusão, dificultar a navegação por teclado e comprometer a compreensão do fluxo de preenchimento.
  • Elementos dependentes entre si (como aceitação de termos e ativação de campos) devem surgir numa ordem coerente, garantindo que o utilizador percebe claramente os passos necessários para completar a ação.

  URL a verificar

  • https://www.museu-do-calcado.pt/pt/inicio (em todo o website, footer – newsletter)

  Evidências:

  No formulário de subscrição da newsletter, a ordem dos elementos no DOM não corresponde à sequência lógica de interação:

  O campo de email e o botão de submissão surgem antes da opção de aceitação dos termos
  No entanto, o campo de email encontra-se desativado até que o utilizador selecione a opção “Sim, li e aceito os Termos e Condições”
  Ou seja, a interação obrigatória (aceitação dos termos) aparece apenas após os elementos que dela dependem

  Esta estrutura provoca uma ordem de leitura inconsistente, sobretudo em navegação linear (sem CSS ou com tecnologias de apoio), onde o utilizador encontra primeiro elementos que não pode utilizar.

  

  Figura 1 - Formulário de newsletter com ordem de leitura inconsistente (aceitação de termos após campo dependente)

  Recomendações:

  • Colocar a aceitação dos termos antes do campo de email, garantindo uma sequência lógica de interação
  • Garantir que a ordem no DOM reflete o fluxo real de utilização
  • Em alternativa, caso se pretenda manter a ordem atual, posicionar o botão de submissão apenas após o campo de email e a checkbox de aceitação
  • Analisar também a issue https://github.com/a11y-PT/report_049/issues/42, por abordar um problema relacionado com o preenchimento da newsletter

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

Lista de evidências recolhidas:

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

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

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

  URL a verificar

  • https://www.museu-do-calcado.pt/pt/
  • https://www.museu-do-calcado.pt/pt/conceito-e-vocacao-do-museu
  • https://www.museu-do-calcado.pt/pt/o-edificio-oliva
  • https://www.museu-do-calcado.pt/pt/noticias/visita-as-reservas-do-calado
  • (entre outras páginas com a mesma secção "Veja também")

  Evidências

  

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

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

  Um link no título (<h4> <a>)
  Um botão visual (<a class="main-button">)

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

  ---

  Outro exemplo pode ser verificado na homepage, onde os cards apresentam três links que direcionam para o mesmo conteúdo (a imagem, o título e o botão ‘Sobre este evento’), além de terem nomes diferentes:

  

  Figura 2 – Card que contém três links que direcionam para o mesmo conteúdo

  Recomendações

  • Remover a duplicação de links com o mesmo destino dentro do mesmo bloco
  • Manter apenas um elemento clicável por item (idealmente o botão ou o título, mas não ambos)
  • Em alternativa, remover o link do título e manter o botão como elemento principal de navegação
  • Garantir uma estrutura de navegação mais limpa e consistente para utilizadores e tecnologias de apoio
  • Os cards devem ter apenas um único link que direcione para o conteúdo, e a sua área clicável deve estender‑se por toda a área do card. Para mais informações partilhamos um exemplo de Streched link do Bootstrap: https://getbootstrap.com/docs/5.0/helpers/stretched-link/

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #37 Conteúdo não acessível ou percetível sem CSS (slider bloqueia restante página)

  etiqueta: chk 10 webetiqueta: R 8.4etiqueta: NOK

  Quando se retira o CSS, a informação relevante permanece visível.
  – ver requisito 8.4 na lista 10 aspetos

  Notas Gerais

  • A estrutura do conteúdo deve garantir que toda a informação e funcionalidades permanecem acessíveis mesmo quando os estilos CSS não estão disponíveis. A dependência excessiva de CSS para controlo de visibilidade ou navegação pode impedir o acesso a conteúdos essenciais, comprometendo a robustez e a previsibilidade da interface.

  URL a verificar

  • https://www.museu-do-calcado.pt/

  Evidências:

  Na página inicial, o conteúdo principal é apresentado através de um slider (com várias <li class="swiper-slide">). Este componente controla a visibilidade dos conteúdos através de CSS.

  Ao desativar o CSS:

  • Apenas parte do conteúdo do slider fica visível
  • Os restantes slides não são apresentados de forma clara
  • O conteúdo abaixo do slider (incluindo o footer) não é apresentado
  • A navegação fica comprometida

  

  Figura 1 – Conteúdo da página não visível após desativação de CSS devido ao slider

  Recomendações:

  • Garantir que todos os conteúdos ficam visíveis sem CSS
  • Não ocultar conteúdo essencial com CSS
  • Apresentar os slides de forma sequencial (sem depender de slider)
  • Garantir que o resto da página (incluindo footer) é sempre acessível

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #8 Ausência de índice com hiperligações internas em páginas com conteúdo extenso

  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

  Ponto 01
  Página: https://www.museu-do-calcado.pt/pt/publicacoes

  A página de catálogos de exposições reúne um conjunto extenso de conteúdos organizados por diferentes exposições temporárias, apresentados em sequência vertical.

  Apesar da divisão clara por temas, não existe um sistema de navegação interna que permita aceder diretamente a cada exposição a partir do início da página.

  Como resultado, o utilizador é obrigado a percorrer toda a lista de conteúdos para encontrar a informação pretendida, o que torna a navegação menos eficiente e mais demorada, sobretudo em páginas com grande volume de informação estruturada por secções.

  

  Figura 01 – Página de catálogos de exposições com conteúdos organizados em sequência e sem índice de navegação interno, dificultando o acesso direto às secções

  Outro exemplo
  https://www.museu-do-calcado.pt/pt/planear-a-sua-visita
  https://www.museu-do-calcado.pt/pt/grupos
  https://www.museu-do-calcado.pt/pt/visitas-tematicas
  https://www.museu-do-calcado.pt/pt/agenda/workshops-e-oficinas-criativas/culturando-por-ai-ferias-de-natal

  Recomendação
  Deve ser adicionado um índice de navegação no início da página com links internos para cada exposição, permitindo acesso direto às diferentes secções e melhorando a eficiência da navegação em conteúdos extensos.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #7 Falhas de adaptação responsiva em conteúdos principais em dispositivos móveis

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

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

  Ponto 01
  Páginas:
  https://www.museu-do-calcado.pt/pt/inicio
  https://www.museu-do-calcado.pt/pt/noticias

  Na página inicial do Museu do Calçado, ao aceder através de dispositivos móveis, o banner principal não se ajusta corretamente a diferentes dimensões de ecrã, resultando em elementos visuais cortados e perda de conteúdo relevante em algumas resoluções.

  Situação semelhante foi identificada na página de notícias, onde o carrossel de conteúdos não apresenta uma adaptação consistente em determinados dispositivos móveis, como no Galaxy Z, levando igualmente ao corte parcial dos elementos apresentados.

  

  Figura 01 – Banner inicial da página principal em dispositivo móvel com corte de conteúdo, evidenciando falha na adaptação responsiva

  

  Figura 02 – Carrossel de notícias em dispositivo móvel com corte parcial de conteúdo, evidenciando falha na adaptação responsiva em determinados ecrãs

  Recomendação
  Deve ser assegurada uma implementação responsiva consistente em todos os componentes do website, garantindo que banners e carrosséis se ajustam corretamente a diferentes resoluções e dispositivos móveis, sem cortes de conteúdo ou perda de informação visual.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #5 Não existem elementos interativos acionados apenas com a passagem do rato

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

  Não existem elementos interativos acionados apenas com a passagem do rato.
  – ver requisito 5.1 na lista Conteúdo

  Ponto 01
  Página: https://www.museu-do-calcado.pt/pt/inicio

  Os submenus do menu principal só são acessíveis através de hover ou clique com rato, não estando disponíveis para navegação por teclado, o que limita a navegação hierárquica para utilizadores que dependem exclusivamente do teclado.

  

  Figura 01 – Menu principal com submenus dependentes de interação por hover/clique, sem acessibilidade equivalente via navegação por teclado

  Recomendação
  Deve ser garantido que os submenus do menu principal são totalmente acessíveis por teclado, permitindo navegação por tabulação e ativação por tecla, assegurando equivalência funcional entre utilizadores de rato e de teclado.

  Ponto 02
  Página: https://www.museu-do-calcado.pt/pt/visitas-virtuais

  Na secção de visitas virtuais, a ação “Abrir vista virtual” apenas se torna visível através de interação por hover, não estando disponível ou identificável no estado inicial da interface.

  Esta abordagem faz com que uma funcionalidade principal não seja imediatamente percecionada pelo utilizador, ficando dependente de exploração prévia para ser descoberta.

  Adicionalmente, como a ação depende exclusivamente de interação por hover, não se encontra disponível em dispositivos de toque. Em contexto mobile, o botão “Abrir vista virtual” não é apresentado, tornando a funcionalidade inacessível para estes utilizadores.

  

  Figura 01 – Ação “Abrir vista virtual” apenas visível no estado hover, não sendo imediatamente percecionável no estado inicial da secção

  

  Figura 02 – Vista em contexto mobile da secção de visitas virtuais, sem apresentação do botão “Abrir vista virtual”, tornando a funcionalidade inacessível em dispositivos de toque

  Recomendação
  A ação “Abrir vista virtual” deve estar visível no estado inicial da interface, garantindo a descoberta imediata da funcionalidade sem necessidade de interação prévia. Recomenda-se a apresentação consistente do botão com indicação clara de interatividade, assegurando que funcionalidades principais não dependem exclusivamente de hover para serem percecionadas ou acedidas.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #4 Os elementos interativos têm uma dimensão mínima de 44px CSS (44 pontos)

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

  Ponto 01
  Páginas:
  https://www.museu-do-calcado.pt/
  https://www.museu-do-calcado.pt/pt/contactos

  Foi identificado que alguns elementos interativos apresentam dimensões reduzidas, comprometendo a sua facilidade de utilização e a área de interação disponível.

  Nomeadamente:

  • O checkbox associado à opção de subscrição apresenta dimensão reduzida de 16px
  • O ícone de envio (representado por uma “cartinha”) no formulário de subscrição apresenta dimensão aproximada de 20px
  • O botão presente no formulário de contacto apresenta dimensão reduzida (16px)

  Estas dimensões são reduzidas para garantir uma área de interação adequada, especialmente em dispositivos móveis ou para utilizadores com limitações motoras, podendo dificultar a sua ativação.

  

  Figura 01 – Checkbox associado à opção “Subscrever” com dimensão reduzida (≈16px), abaixo das boas práticas de acessibilidade para alvos interativos

  

  Figura 02 – Ícone de envio no formulário de subscrição com dimensão reduzida (~20px), limitando a área de interação e dificultando a sua utilização

  

  Figura 03 – Botão de submissão no formulário de contacto com dimensão reduzida (≈16px), abaixo das boas práticas de acessibilidade para alvos interativos

  Recomendação
  Deve ser garantida uma área de interação adequada para os elementos clicáveis, preferencialmente com dimensão mínima de 44px, assegurando também o reforço da área clicável através de padding e o espaçamento adequado entre elementos para evitar erros de interação.

  Ponto 02
  Página: https://www.museu-do-calcado.pt/pt/inicio

  Foi identificado que, em versão mobile, o menu principal é convertido num ícone de navegação do tipo “menu hambúrguer”, responsável por abrir e fechar a navegação do site.

  Este elemento apresenta dimensão aproximada de 20px, o que resulta numa área de interação reduzida, podendo dificultar a sua ativação em dispositivos móveis ou para utilizadores com limitações motoras.

  

  Figura 03 – Ícone de menu hambúrguer em versão mobile com dimensão reduzida (~20px), limitando a área de interação e dificultando a ativação do controlo de navegação

  Recomendação
  Garantir que o botão de navegação mobile (menu hambúrguer) possui uma área mínima de interação adequada 44px de altura e largura, assegurando maior facilidade de ativação em dispositivos móveis e em conformidade com boas práticas de acessibilidade para elementos interativos.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #6 Há botões principais que não têm destaque suficiente

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

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

  Ponto 01
  Páginas:
  https://www.museu-do-calcado.pt/pt/agenda
  https://www.museu-do-calcado.pt/pt/contactos

  O website apresenta um padrão visual uniforme para botões em diferentes páginas e componentes, não existindo uma distinção clara entre os botões de ações principais e ações secundárias.

  Na página Agenda do Museu do Calçado, os elementos interativos disponíveis são considerados botões de ação secundária.

  No entanto, apresentam um tratamento visual e um estilo muito semelhante ao botão de acção principal da página Contactos, o que pode dificultar na navegação a perceção dos botões de ação principal. 


  Esta abordagem reduz a clareza da hierarquia de ações e pode dificultar a identificação da ação principal em diferentes contextos de utilização.

  

  Figura 01 – Página de agenda com uniformidade visual nos elementos interativos, dificultando a identificação de ações prioritárias

  

  Figura 02 – Página de contactos com botão de submissão sem destaque visual suficiente, comprometendo a hierarquia da ação principal

  Outros exemplos
  https://www.museu-do-calcado.pt/pt/inicio
  https://www.museu-do-calcado.pt/pt/noticias
  https://www.museu-do-calcado.pt/pt/publicacoes
  https://www.museu-do-calcado.pt/pt/planear-a-sua-visita

  Recomendação
  Deve ser implementada uma hierarquia visual consistente para ações interativas, garantindo que ações principais se destacam claramente através de estilo, contraste ou tratamento visual diferenciado face às ações secundárias.

  Ponto 02
  Página: https://www.museu-do-calcado.pt/pt/inicio

  No modal de personalização de cookies, o botão “Guardar” não apresenta destaque visual no estado inicial, sendo exibido apenas com estilo de contorno, sem preenchimento ou diferenciação clara enquanto ação principal.

  Esta ausência de destaque compromete a perceção da hierarquia de ações, dificultando a identificação imediata da ação prioritária por parte do utilizador.

  

  Figura 01 – Modal de personalização de cookies em estado de hover, onde os botões apresentam comportamento visual semelhante, reduzindo a distinção entre ação principal e ações secundárias

  Recomendação
  Recomenda-se que o botão “Guardar” seja visualmente reforçado enquanto ação principal, através da utilização de preenchimento sólido e maior contraste em relação às restantes ações secundárias. Adicionalmente, deve ser garantida uma diferenciação consistente entre estados (normal, hover e ativo), de forma a reforçar a hierarquia de ações e melhorar a perceção de interatividade.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #3 Inconsistência na perceção de elementos clicáveis no estado inicial

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

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

  Ponto 01
  Página: https://www.museu-do-calcado.pt/

  No banner de cookies, os elementos interativos “Personalizar” e “Rejeitar todos” não apresentam características visuais suficientemente claras que permitam ao utilizador identificá-los como botões clicáveis.

  Estes elementos são apresentados com estilo semelhante a texto ou links pouco destacados, sem indicadores visuais fortes como preenchimento, contraste, sombra ou volume que reforcem a sua natureza interativa.

  Adicionalmente, apenas no estado de hover é aplicado um preenchimento visual, o que faz com que, antes da interação, não seja evidente que estes elementos são acionáveis.

  

  Figura 02 – Banner de cookies com ausência de affordance visual nos botões “Personalizar” e “Rejeitar todos” no estado inicial

  

  Figura 04 – Botão “Guardar” no ecrã de personalização de cookies sem affordance visual suficiente para ser percecionado como elemento clicável

  Recomendação

  • Aplicar estilos visuais claros de botão (preenchimento, contraste, volume ou sombra)
  • Garantir que todos os elementos interativos são identificáveis como tal no estado inicial
  • Evitar depender exclusivamente do hover para comunicar interatividade

  Ponto 02
  Página: https://www.museu-do-calcado.pt/pt/noticias/2

  Na página de notícias, no carrossel de conteúdos, foi identificado que o botão de navegação (seta para a esquerda) apresenta níveis de contraste reduzidos entre os estados ativo e inativo.

  No estado inativo, o elemento apresenta um rácio de contraste de 1.68:1, valor insuficiente para garantir boa perceção visual.

  No estado ativo, o contraste melhora para 2.65:1, contudo continua abaixo dos níveis recomendados para garantir acessibilidade e clara distinção entre estados.

  

  Figura 01 – Secção de visitas virtuais no estado inativo, onde o botão “Abrir vista virtual” apresenta um rácio de contraste de 1.68:1, valor insuficiente para garantir boa perceção visual

  

  Figura 03 – Secção de visitas virtuais no estado ativo, onde o contraste do botão “Abrir vista virtual” melhora para 2.65:1, mas permanece abaixo dos níveis recomendados para garantir acessibilidade e clara distinção entre estados

  Ponto 03
  Página: https://www.museu-do-calcado.pt/pt/inicio

  No menu principal do website, todos os itens de navegação (“Início”, “Museu”, “Visitar”, “Exposições”, “Programação”, “Contactos”) são interativos, no entanto não apresentam indicadores visuais consistentes que permitam ao utilizador identificar imediatamente a sua natureza clicável.

  Com exceção do item ativo, os restantes elementos são apresentados como texto simples no estado inicial, sem affordance visual clara que sugira interatividade. A perceção de que são elementos clicáveis ocorre apenas após interação (hover), através de alterações visuais como mudança de cor.

  Esta abordagem cria inconsistência na leitura do menu e reduz a clareza da navegação logo no primeiro contacto com a interface.

  

  Figura 01 – Menu principal com ausência de affordance visual nos itens de navegação no estado inicial, dificultando a perceção de interatividade

  Recomendação
  Deve ser assegurada uma indicação visual consistente de interatividade nos itens do menu no estado inicial, garantindo que todos os elementos aparentam ser clicáveis através de affordance clara, sem depender apenas do hover.

  Ponto 04
  Página: https://www.museu-do-calcado.pt/pt/agenda/eventos/metamorfoses-dos-plasticos-a-realidade-e-as-multiplas-abordagens-1

  Na página da exposição “Metamorfoses dos Plásticos: A realidade e as múltiplas abordagens”, o intervalo de datas (“07 Novembro a 26 Abril 2026”) é apresentado com um estilo visual semelhante ao de elementos interativos do website.

  Apesar de apresentar um contorno branco, este elemento não possui qualquer funcionalidade associada, contrastando com outros componentes clicáveis da interface que utilizam preenchimento para indicar interatividade.

  Esta proximidade visual com o padrão de botões pode levar o utilizador a interpretar incorretamente o elemento como acionável, afetando a clareza da interface.

  

  Figura 01 – Elemento de data com estilo visual semelhante a botão, sem funcionalidade interativa associada, podendo induzir o utilizador em erro

  Outros Exemplos
  https://www.museu-do-calcado.pt/pt/agenda/eventos/metamorfoses-dos-plasticos-a-realidade-e-as-multiplas-abordagens-1
  https://www.museu-do-calcado.pt/pt/agenda/eventos/sapacarros-shoeing-em-s-joao-da-madeira
  https://www.museu-do-calcado.pt/pt/agenda/workshops-e-oficinas-criativas/jogar-com-os-plasticos
  https://www.museu-do-calcado.pt/pt/agenda/eventos/segredos-do-museu

  Recomendação
  Deve ser evitada a utilização de estilos visuais semelhantes a botões em elementos não interativos, assegurando que apenas componentes com funcionalidade acionável apresentam affordance de clique. Elementos informativos, como datas, devem ter um tratamento visual distinto dos controlos interativos para evitar confusão na perceção do utilizador.

  Ponto 05
  Página: https://www.museu-do-calcado.pt/

  Na página inicial, o botão “Sobre o evento” encontra-se sobreposto a uma imagem de fundo com variação de cores e contraste, o que compromete a sua legibilidade e perceção enquanto elemento interativo.

  O mesmo acontece com o botão "Sobre o Museu".

  A ausência de contraste suficiente entre o botão e a imagem dificulta a sua identificação imediata, podendo levar a que a ação passe despercebida ao utilizador.

  

  Figura 01 – Botão “Sobre o evento” com contraste insuficiente face à imagem de fundo, comprometendo a sua visibilidade e perceção como elemento interativo

  Outro exemplo
  https://www.museu-do-calcado.pt/pt/contactos

  Recomendação
  Deve ser assegurado contraste adequado entre o botão e o fundo onde está inserido, garantindo a sua visibilidade e perceção enquanto elemento interativo.

  Recomenda-se a aplicação de um overlay na imagem de fundo ou o ajuste das cores do botão (ex.: fundo sólido ou maior contraste), de forma a destacar claramente a ação face ao conteúdo visual envolvente.

  Ponto 06
  Página: https://www.museu-do-calcado.pt/pt/inicio

  Os controlos do carrossel apresentam contraste insuficiente (≈1:1) face a determinadas imagens de fundo, tornando-se pouco visíveis ou praticamente impercetíveis em alguns contextos.

  Adicionalmente, estes elementos não possuem indicadores visuais claros de interatividade, não sendo facilmente reconhecidos como clicáveis no estado inicial.

  Foi também identificado que os ícones de redes sociais (ex.: Facebook e Instagram), apesar de serem elementos interativos, apresentam contraste reduzido em fundos claros, podendo tornar-se impercetíveis em determinadas imagens.

  Adicionalmente, estes elementos não apresentam indicadores de interatividade ao passar o cursor (hover), como alterações de cor, sublinhado ou feedback visual equivalente, o que dificulta a perceção de que se tratam de elementos clicáveis.

  Por fim, existe um elemento gráfico adjacente com aparência semelhante aos controlos do carrossel, mas sem funcionalidade interativa associada, o que pode induzir o utilizador em erro.

  A combinação de baixo contraste, ausência de affordance visual e elementos visualmente ambíguos compromete a identificação e utilização dos componentes interativos.

  

  Figura 01 – Controlos do carrossel com baixo contraste face ao fundo, comprometendo a visibilidade dos botões de navegação

  

  Figura 02 – Controlos do carrossel sem indicadores visuais claros de interatividade, dificultando o reconhecimento como elementos clicáveis

  

  Figura 03 – Ícones de redes sociais com contraste reduzido e elemento gráfico adjacente sem funcionalidade interativa, podendo gerar ambiguidade na perceção

  Recomendação
  Deve ser garantido contraste adequado entre todos os elementos interativos e o fundo, assegurando a sua visibilidade em diferentes contextos visuais.

  Os controlos clicáveis devem apresentar indicadores claros de interatividade, através de estilos consistentes (ex.: preenchimento, contraste ou forma definida), evitando dependência do contexto visual.

  Adicionalmente, elementos não interativos não devem utilizar estilos semelhantes aos componentes clicáveis, prevenindo interpretações incorretas por parte do utilizador.

  Recomenda-se ainda assegurar que ícones de redes sociais mantêm visibilidade consistente independentemente da imagem de fundo, por exemplo através da utilização de fundos sólidos ou overlays.

  Ponto 07
  Página: https://www.museu-do-calcado.pt/pt/inicio

  O estado de hover dos elementos interativos apresenta redução significativa de contraste face ao fundo do site, afetando de forma transversal os botões e controlos presentes em todo o website.
  Este comportamento compromete a legibilidade e a perceção dos elementos durante a interação.

  

  Figura 04 – Elemento gráfico com aparência semelhante a controlos de navegação, sem funcionalidade interativa associada, podendo gerar confusão na perceção do utilizador

  Recomendação
  Garantir que todos os componentes interativos do website mantêm contraste adequado em todos os estados (hover, focus e active), assegurando consistência visual e acessibilidade em todo o sistema, de acordo com os requisitos mínimos de contraste.

  Ponto 08
  Página: https://www.museu-do-calcado.pt/pt/noticias/exposicao-sobre-os-50-anos-do-25-de-abril-termina-este-domingo

  Foi identificado que o menu de navegação permanece fixo durante o scroll em todo o website, em versões mobile e desktop, com fundo semitransparente, sobrepondo o conteúdo da página. Este comportamento pode comprometer a legibilidade e a perceção visual dos elementos do conteúdo durante a navegação contínua, especialmente quando existem elementos informativos ou interativos sob a área do menu.

  

  Figura 04 – Menu de navegação fixo com fundo semitransparente sobrepondo o conteúdo da página durante o scroll, comprometendo a perceção visual dos elementos em mobile e desktop

  Recomendação
  Avaliar o comportamento do menu fixo em versões mobile e desktop, garantindo que não interfere na perceção visual do conteúdo durante o scroll. Recomenda-se ajustar a opacidade e o contraste do fundo do menu, de forma a evitar sobreposição que comprometa a legibilidade e a clareza dos elementos subjacentes.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #46 Não foram encontrados formulários com mais de 2 ecrãs no website

  etiqueta: chk transaçãoetiqueta: N/Aetiqueta: 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 no site do Museu do Calçado com mais de dois ecrãs. Assim, este critério é considerado "Não aplicável (N/A)".

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #47 Não foram encontrados 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 foram encontrados formulários com mais de uma página dentro do site do Museu do Calçado. Assim, este requisito fica avaliado como "Não Aplicável".

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #50 O tamanho dos campos não reflete o tamanho previsível dos dados

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

  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 'Telefone' tem a mesma largura que os campos 'Nome', 'Email' e 'Assunto', apesar de, no contexto português, um número de telefone ter no máximo cerca de 14 caracteres (por exemplo, 00351212345678). Tendo isto em conta, este campo deveria ser mais curto do que os restantes.

  Por outro lado, o campo 'Nome' deve ter largura suficiente para acomodar, no limite, o nome completo do utilizador. Assim, recomendamos reformular este campo para ser maior.

  

  Figura - Formulário da página Contactos.

etiqueta: N/A

Lista de evidências recolhidas:

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

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

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

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

etiqueta: NOK

Lista de evidências recolhidas:

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

  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

  Verificámos que, à frente dos rótulos do campo de email no formulário da newsletter e dos campos obrigatórios (“Nome”, “Email”, “Assunto” e “Telefone”) na página Contactos, é apresentada a indicação “Obrigatório *”.

  No entanto, não é fornecida uma legenda clara sobre o significado do asterisco no formulário. Posto isto, recomendamos que seja usado apenas a indicação “Obrigatório” à frente dos rótulos dos campos.

  

  Figura 1 - Formulário da página Contactos. Não está disponível qualquer informação sobre o significado do asterisco no formulário.

  

  Figura 2 - Formulário para subscrever a newsletter. Não está disponível qualquer informação sobre o significado do asterisco no formulário.

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

  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

  Verificámos que, nos formulários para subscrição da newsletter e da página Contactos, existem campos que apresentam a indicação visual “Obrigatório” junto ao respetivo rótulo, mas que não estão programaticamente definidos como obrigatórios.

  No caso do formulário de subscrição da newsletter, o campo relativo ao email não tem associado o atributo required ou aria-required. Na página Contactos, os campos “Nome”, “Email”, “Assunto” e “Telefone” também não possuem qualquer um destes atributos.

  Recomendamos que, para além do texto “Obrigatório” em frente ao rótulo do campo, seja também adicionado o atributo required nos campos de input de forma a reforçar aos utilizadores de tecnologias de apoio que o campo em questão é um campo de preenchimento obrigatório.

  

  Figura 1 - Análise dos campos do formulário da página Contactos através do Google Inspector.

  

  Figura 2 - Análise do formulário para subscrever a newsletter através do Google Inspector.

• evidência: issue #66 Não é possível identificar campos obrigatórios

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

  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 para subscrição da Newsletter (localizado no rodapé do site) e no formulário da página Contactos, o leitor de ecrã não reconhece o campo de seleção “Sim, eu li e aceito os Termos e Condições e a 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 — por exemplo, “(Campo obrigatório)” ou “(Obrigatório)”— para que todos os utilizadores consigam identificar facilmente os campos que têm obrigatoriamente de preencher.

  

  Figura 1 - Análise do campo de seleção “Sim, eu li e aceito os Termos e Condições e a Política de Privacidade.”, do formulário para subscrição da newsletter, através do Google Inspector.

  

  Figura 2 - Análise do campo de seleção “Sim, eu li e aceito os Termos e Condições e a Política de Privacidade.”, do formulário da página Contactos, através do Google Inspector.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #13 Inexistência de 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

  Na análise realizada, não foram identificadas ações longas que exijam comunicação de estado ao utilizador.

  Desta forma, considera-se que o critério é não é aplicável.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #14 Confirmação de sucesso invisível para tecnologias de apoio.

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

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

  Notas Gerais

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

  URL a verificar

  • https://www.museu-do-calcado.pt/pt/inicio (subscrição newsletter)
  • https://www.museu-do-calcado.pt/pt/contactos

  Evidências:

  Nos formulários de contacto e subscrição de newsletter, após a submissão dos dados, a mensagem de sucesso não é apresentada de forma imediata ou percetível ao utilizador.

  Adicionalmente, não é possível aceder a essa mensagem através de navegação por teclado (Tab e Shift+Tab), o que indica que a mesma não se encontra no fluxo de foco da página.

  Como consequência, os utilizadores podem não perceber que a ação foi concluída com sucesso.

  

  Figura 1 – Mensagem de sucesso após subscrição da newsletter não acessível via teclado

  

  Figura 2 – Mensagem de sucesso após envio do formulário de contacto não acessível através de navegação por teclado

  Recomendações:

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

etiqueta: N/A

Lista de evidências recolhidas:

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

  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 identificámos formulários que permitem o utilizador fazer ações destrutivas e por esse motivo, consideramos esse critério como "Não aplicável".

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #39 Existem formulários sem Mensagens de erro junto aos 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

  O formulário de subscrição de newsletter não apresenta mensagens de erro junto aos campos:

  

  Campo email do formulário de contactos sem mensagem de erro associada
  A única mensagens de erro apresentada ocorre no topo da página, e é apresentada durante um período de tempo:

  

  Mensagem de erro no topo da página
  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, a localização da mensagem “Erro: insira um email válido” no topo da página associada ao seu curto tempo de permanência no ecrã torna muito difícil a descoberta da mesma por parte dos utilizadores de leitores de ecrã.
  A mesma situação ocorre no formulário contactos, com uma variante: a mensagem de erro é apresentada apenas no topo do formulário.

  

  mensagem de erro no topo do formulário contactos
  Em situações que não conseguimos reproduzir de modo determinístico, a mensagem de erro supra é substituída pela seguinte: “Erro! Erro de validação contra robôs, tente novamente”, que em nosso entender está fora do contexto, pois descreve um erro que o utilizador não vê.

  Recomendamos que sejam apresentadas mensagens de erro junto aos campos de todos os formulários, 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).
  Todas as mensagens de erro devem permanecer no ecrã até que o utilizador atualize a página, de modo a serem lidas o número de vezes que o utilizador pretender.
  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>
  

etiqueta: NOK

Lista de evidências recolhidas:

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

  A mensagem de erro “Erro: insira um email válido” presente no formulário de subscrição de newsletter não ajuda no preenchimento do campo:

  

  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 “Erro: insira 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.
  O mesmo problema ocorre no formulário contactos.
  Recomendamos rever todos os formulários do website para garantir que as mensagens de erro apresentadas expliquem para o utilizador como preencher os campos corretamente.

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

Lista de evidências recolhidas:

• evidência: issue #78 Outras violações - Uso inadequado de overlays de acessibilidade

  etiqueta: outras violaçõesetiqueta: melhoria

  Os overlays de acessibilidade são frequentemente utilizados como soluções rápidas, mas não corrigem os problemas reais do website. Estas ferramentas funcionam como camadas sobrepostas ao código existente, sem resolver falhas estruturais como erros de semântica, foco, landmarks ou navegação por teclado.

  Em todo website, é disponibilizado um “menu de acessibilidade” que em alguns casos, podem interferir com tecnologias de apoio (ex.: NVDA), criando comportamentos inesperados, atalhos redundantes ou problemas de apresentação, como textos muito pequenos que afetam a legibilidade e problemas de contraste. Além disso, transmitem uma falsa perceção de conformidade, mantendo problemas de acessibilidade para utilizadores reais.

  Recomendamos que a acessibilidade seja assegurada prioritariamente através de boas práticas nativas: uso correto de HTML semântico, navegação por teclado funcional, contraste adequado e compatibilidade com tecnologias de apoio. Os overlays não devem substituir a correção estrutural do site, pois a melhoria da acessibilidade deve começar na base do código e não depender exclusivamente de ferramentas externas. Sendo assim, devem ser removidos do website.

  

  Figura - Utilização de overlays de acessibilidade no site.

• evidência: issue #76 Outras violações - Há conteúdo em inglês na versão portuguesa do site

  etiqueta: outras violaçõesetiqueta: melhoria

  Verificámos que, na versão portuguesa do site, a página A minha família vai ao museu... e a tua?, o bloco de texto abaixo do cabeçalho de nível 3 "Dos 0 aos 100", está em inglês.

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

  Recomendamos que este bloco de texto seja traduzido para português por forma a garantir uma experiência mais acessível.

  

  Figura - Página A minha família vai ao museu... e a tua? com blocos de texto em inglês na versão portuguesa do site. O texto em inglês está destacado através de um retângulo de borda preta.

• evidência: issue #74 Outras violações - Há hiperligações que redirecionam para páginas de erro

  etiqueta: outras violaçõesetiqueta: melhoria

  Verificámos que as hiperligações “Sobre o museu” e “Exposições & Agenda”, ambas localizadas no rodapé da página, estão a redirecionar para páginas de erro (“Página não encontrada (Erro 404)”).

  Esta situação dificulta o acesso à informação e representa uma barreira significativa à acessibilidade do conteúdo.

  Recomendamos atualizar todas as hiperligações do site para garantir que apontam para conteúdos atualizados e disponíveis no website.

  

  Figura - Página de erro que é mostrada quando se seleciona a hiperligação “Sobre o museu” no rodapé da página.

• evidência: issue #72 Outras violações - Foco não está visível quando se navega por teclado (Tab/Shift+Tab)

  etiqueta: outras violaçõesetiqueta: melhoria

  Verificámos que, quando se navega pelo site através do teclado (Tab/Shift+Tab), o foco não está visível. Para quem depende da navegação por teclado, isto torna se extremamente confuso, porque o utilizador deixa de saber onde está na página e perde a noção do elemento que está prestes a acionar.

  Recomendamos que o indicador de foco do teclado seja revisto para garantir que todos os elementos interativos do site apresentam um foco claramente visível, consistente e contrastante (o contraste mínimo com o fundo deve ser de 3:1) sempre que recebem foco através da navegação por teclado.

  

  Figura - Navegação por teclado (Tab e Shift+Tab) na página inicial no site do Museu da Chapelaria. O foco não está visível.

• evidência: issue #71 Outras violações - O link “Saltar para o conteúdo principal da página” está estruturado incorretamente

  etiqueta: outras violaçõesetiqueta: melhoria

  O link “Saltar para o conteúdo principal da página” é um link que aparece no topo da página quando se navega pelo site por teclado e que permite aos utilizadores saltar menus e elementos repetidos na página. É uma ferramenta bastante útil para quem usa tecnologias de apoio como, por exemplo, leitores de ecrã, que permite aos utilizadores saltar diretamente para o conteúdo principal da página.

  Verificámos que, no site do Museu do Calçado, o link “Saltar para os conteúdos” reencaminha o utilizador para a <div> “navtopinner” (<div id="navtopinner">)que contém o logótipo do site, o menu e o seletor de idioma.

  Recomendamos que este link seja renomeado para “Saltar para o conteúdo principal da página” e que, quando selecionado, reencaminhe o utilizador diretamente para o início do conteúdo principal, posicionando o foco imediatamente após o cabeçalho.

  

  Figura 1 - Análise da hiperligação no topo da página "Saltar para os conteúdos" com o CSS da página desativado e através do Google Inspector.

  

  Figura 2 - Análise da <div> "navtopinner" (<div id="navtopinner">), no cabeçalho da página, através do Google Inspector.