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

Introdução

O website https://www.museu-do-calcado.pt/ etiqueta: não passa nos requisitos mínimos do Selo de Usabilidade e Acessibilidade.

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

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

Níveis de conformidade das avaliações manuais
ChecklistConformidade alcançadaResultado
10 aspetos21.7% (5/23)etiqueta: Não passa
Conteúdo11.8% (2/17)etiqueta: Não passa
Transação12.5% (1/8)etiqueta: Não passa

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

Avaliação automática

etiqueta: NOK

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

Lista de evidências recolhidas:

Avaliação manual

etiqueta: NOK

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

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

Checklist 10 aspetos

etiqueta: NOK

Nível de conformidade:

  • Checklist 10 aspetos: 21.7% (5/23)
    • Requisitos avaliados: 27 (4 N/A excluídos, 23 aplicáveis)
    • Requisitos OK: 5
    • Requisitos NOK: 18
    • Requisitos N/A: 4

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    Image

    URL a verificar

    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.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    Image

    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:

    Image

    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 .

  • 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.2etiqueta: NOK

    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:
    Image
    1. 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.
    Image

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

    Image

    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:

    Image

    URL

    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

  • 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.2etiqueta: NOK

    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:

    Image

    URL

    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.

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

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

Lista de evidências recolhidas:

  • issue #34 (melhoria) Não está sendo utilizado imagens-link no menu principal

    etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 1.3

    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

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #56 Existem páginas que não têm h1 atribuído

    etiqueta: chk 10 webetiqueta: R 2.1etiqueta: NOK

    Nas homepage não existe um cabeçalho h1 marcado na página. Cada página deve conter um cabeçalho de nível um (h1) para dar aos utilizadores de leitores de ecrã um ponto de referência fiável que lhes permita saltar diretamente para o conteúdo principal. Além disso, 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.

    Evidencias:

    Image

    Figura 1 - Extensão Web Developer (https://www.museu-do-calcado.pt/) .

    URL a verificar:

    Recomendações:

    • 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.
    • Nas páginas internas o h1 deve estar atribuído ao título principal da página.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: N/A

Lista de evidências recolhidas:

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

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

etiqueta: N/A

Lista de evidências recolhidas:

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

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #49 Existem campos com etiquetas pouco claras

    etiqueta: chk 10 webetiqueta: R 4.1etiqueta: NOK

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

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

    Image

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

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    etiqueta: chk 10 webetiqueta: R 4.2etiqueta: NOK

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

    Image

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

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

    Image

    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.

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

    etiqueta: chk 10 webetiqueta: R 4.2etiqueta: NOK

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

    Image

    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.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    Image

    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:

    Image

    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.

    Image

    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.

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

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

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    Image

    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.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    Image

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

    Image

    .

    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.

    Image

    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 da Chapelaria – página inicial"

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #40 Texto normal não tem contraste suficiente

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

    Notas gerais

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

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

    O website apresenta problemas de contraste nas interação de hover(passagem do rato sobre o elemento) em textos normais, como nas hiperligações do rodapé que utilizam a combinação de cores #916734(cor de primeiro plano) e #160f08(cor de plano de fundo). (Figura 1)

    Image

    Figura 1- Hiperligações no estado de hover com problemas de contraste

    Outro exemplo de problema de contraste em hiperligações:
- https://www.museu-do-calcado.pt/pt/contactos

    Há problemas de contrastes em mensagens das páginas de erro Sobre o museu, sendo assim o texto não é visível. Na combinação de cores ##1D1E22(cor de primeiro plano) e #160F08(cor de plano de fundo) (Figura 2)

    Image

    Figura 2- Página de erro com taxa de contraste inferior ao recomendado

    Recomendações
    Recomendamos a revisão das cores das páginas as combinações de cores utilizadas em texto normal incluindo estados de foco e hover para garantir os valores mínimos de contraste.

Requisito 6.2 - O rácio de contraste entre a cor do texto de tamanho grande (maior ou igual que 18 pontos ou maior ou igual que 14 pontos negrito) e a cor do fundo é superior a 3:1

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #43 Há texto sob imagens que não cumpre o rácio de contraste

    etiqueta: chk 10 webetiqueta: R 6.2etiqueta: NOK

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

    Notas Gerais

    • O contraste no texto grande (superior a 18 pontos ou superior a 14 pontos negrito) das páginas deve ser, no mínimo 3:1, para que as pessoas com baixa visão consigam ler o texto. É necessário também garantir que os textos por cima de imagens possuem contraste, principalmente quando a imagem é alterada ao longo do tempo, mas o estilo do texto mantém-se.

    Na página inicial o texto grande “BEM-VINDO AO MUSEU DO CALÇADO” o uso de texto claro sobre zonas igualmente claras da imagem compromete a legibilidade, dificultando a leitura e a perceção da informação.(Figura 1)



    Image

    Figura 1- Texto grande do título "Bem-vindo ao Museu do Calçado" não passa na avaliação de contraste

    Esta situação não cumpre as boas práticas de acessibilidade, podendo impactar negativamente a experiência do utilizador, especialmente para pessoas com limitações visuais.

    Recomendações
    Recomenda-se a aplicação de soluções como sobreposição de cor (overlay), ajuste de tonalidade da imagem ou reforço do contraste do texto. Sendo assim, sugerimos que escureçam a imagem do banner, colocando um filtro, para que textos e botões fiquem mais legíveis.

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

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

etiqueta: N/A

Lista de evidências recolhidas:

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

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

etiqueta: N/A

Lista de evidências recolhidas:

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

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #53 Ordem lógica do conteúdo comprometida no menu mobile

    etiqueta: chk 10 webetiqueta: R 8.2etiqueta: NOK

    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

    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.

    Image

    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

  • issue #52 Ordem de leitura incorreta no formulário de newsletter

    etiqueta: chk 10 webetiqueta: R 8.2etiqueta: NOK

    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

    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.

    Image

    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

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #75 Selector de idioma sem estrutura semântica adequada

    etiqueta: chk 10 webetiqueta: R 8.3etiqueta: NOK

    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

    • Elementos que representam conjuntos de opções relacionadas, como seletores de idioma, devem ser estruturados com marcação semântica adequada que permita identificar programaticamente a relação entre os itens. A utilização de elementos genéricos sem essa estrutura pode dificultar a interpretação por tecnologias de apoio e comprometer a compreensão da organização do conteúdo quando os estilos visuais não estão presentes.

    URL a verificar

    Evidências:

    O seletor de idioma é apresentado como um conjunto de opções (“pt” e “en”), mas está estruturado apenas com elementos genéricos (<div> e <span>), sem recurso a uma lista semântica.

    Adicionalmente:

    • O estado selecionado é indicado apenas visualmente através de classes CSS (“selected”), não sendo programaticamente identificável.
    Image

    Figura 1 – Selector de idioma estruturado com <div> e <span> sem semântica de lista

    Recomendações:

    • Estruturar o conjunto de idiomas como uma lista semântica (<ul> / <li>)
    • Garantir que cada opção é um elemento interativo claro (<a>)
    • Indicar programaticamente o idioma ativo (ex.: aria-current="true" ou aria-current="language")
    • Utilizar nomes acessíveis mais descritivos, como “Português” e “English”, em vez de “pt” e “en”

  • issue #73 Slider com estrutura semântica e conteúdo inadequado

    etiqueta: chk 10 webetiqueta: R 8.3etiqueta: NOK

    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

    • A estrutura do conteúdo deve garantir que a informação é compreensível e semanticamente correta quando interpretada de forma linear. Elementos com conteúdo vazio, textos irrelevantes ou uso incorreto de atributos comprometem a clareza e dificultam a interpretação por tecnologias de apoio.

    URL a verificar

    Evidências:

    No slider principal da página, observam-se vários problemas estruturais:

    • Imagens com atributo alt vazio ou com espaços (alt=" "), sem alternativa textual significativa
    • Elementos

      utilizados como títulos ou conteúdos principais, em vez de headings semânticos (<h1>–<h6>)

    • Presença de conteúdo vazio ou irrelevante (ex: <p id="-1"> </p>)
    • Estrutura inconsistente entre slides (alguns com texto, outros praticamente vazios)

    Estes problemas dificultam a compreensão do conteúdo quando lido de forma linear e comprometem a sua semântica.

    Image

    Figura 1 – Slider com conteúdo vazio, textos sem significado e uso incorreto de elementos semânticos

    Recomendações:

    • Garantir textos alternativos significativos nas imagens
    • Remover elementos vazios ou sem conteúdo relevante
    • Uniformizar a estrutura dos slides

  • issue #68 Controlos interativos implementados com elementos não semânticos

    etiqueta: chk 10 webetiqueta: R 8.3etiqueta: NOK

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

    Notas Gerais

    • Os elementos interativos devem ser implementados com recurso a elementos HTML semânticos adequados, de forma a garantir que o seu papel, estado e comportamento são corretamente interpretados por tecnologias de apoio. A utilização de elementos genéricos (como <div> ou <span>) para simular botões compromete a semântica da interface e pode afetar a navegação e a interação, sobretudo quando os estilos ou scripts não estão disponíveis.

    URL a verificar

    Evidências:

    No componente de navegação do slider, os controlos de avançar e recuar são implementados com elementos <div>. Estes elementos:

    • Não são semanticamente reconhecidos como botões
    • Não possuem um nome acessível claro (apenas símbolos “←” e “→”)
    • Utilizam atributos como tabindex e aria-disabled para simular comportamento interativo

    Quando os estilos CSS ou scripts não estão disponíveis, estes elementos deixam de ser identificáveis como controlos interativos, comprometendo a compreensão e navegação.

    Image

    Figura 1 – Controlos de navegação implementados com <div> em vez de elementos semânticos

    Outro exemplo que pode ser verificado em todas as páginas, onde elementos interativos são implementados com <div>, sem utilização de elementos semânticos apropriados.

    Image

    Figura 2 – Botão de cookies implementado com <div> em vez de elemento interativo semântico

    Neste caso, o botão de abertura das definições de cookies é implementado com um elemento <div>, sendo posteriormente estilizado e utilizado como elemento clicável.

    Esta abordagem não garante que o elemento seja corretamente identificado como interativo por tecnologias de apoio, nem assegura comportamentos esperados de acessibilidade (como navegação por teclado ou anúncio correto do papel do elemento).

    Recomendações:

    • Utilizar elementos semânticos apropriados para ações, como <button>
    • Garantir que cada botão possui um nome acessível claro (ex.: aria-label="Slide anterior" e aria-label="Slide seguinte")
    • Utilizar o atributo nativo disabled em vez de aria-disabled, sempre que aplicável
    • Evitar o uso de elementos genéricos para funcionalidades interativas, reduzindo a dependência de ARIA para definir comportamentos básicos
    • Validar o comportamento com navegação por teclado e tecnologias de apoio

  • 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

    Evidências

    Image

    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:

    Image

    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/

  • issue #63 Listagem de conteúdos não estruturada semanticamente como lista

    etiqueta: chk 10 webetiqueta: R 8.3etiqueta: NOK

    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

    • Quando se retira o CSS, deve ser possível reconhecer a semântica dos diversos elementos.
    • Conteúdos que representam conjuntos de itens relacionados devem ser estruturados com elementos HTML semânticos apropriados, como listas (<ul> / <ol> e <li>), de forma a garantir que as tecnologias de apoio conseguem identificar corretamente o agrupamento e o número de elementos.
    • A ausência desta estrutura compromete a perceção da relação entre os conteúdos apresentados, especialmente em contextos de leitura linear ou navegação com tecnologias de apoio.

    URL a verificar

    Evidências
    Nas página da figura, existe um conjunto de conteúdos apresentados com estrutura semelhante (Espaços e serviços disponíveis). Estes elementos representam um conjunto de opções/serviços relacionados, mas estão implementados com elementos <div>, sem qualquer estrutura semântica que os identifique como uma lista.
    Quando os estilos CSS são desativados, estes conteúdos deixam de ser percebidos como um conjunto organizado, dificultando a compreensão da relação entre os elementos.
    Este padrão impede que tecnologias de apoio anunciem corretamente o número de itens e a sua relação.

    Image

    Figura 1 – Conteúdos relacionados estruturados com <div> em vez de lista semântica

    Recomendações:

    • Estruturar conjuntos de conteúdos relacionados utilizando listas semânticas (<ul> ou <ol>)
    • Representar cada item com <li>, mantendo a estrutura interna (ex: <article>) se necessário
    • Garantir que a relação entre os itens é programaticamente determinável e percetível sem CSS

Requisito 8.4 - Quando se retira a CSS, a informação relevante permanece visível

etiqueta: NOK

Lista de evidências recolhidas:

  • 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

    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
    Image

    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

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    etiqueta: chk 10 webetiqueta: R 9.1etiqueta: NOK

    Evidências:
    Quando a caixa de diálogo é ativada, o foco do navegador permanece no conteúdo de fundo da página (links ou campos de texto do site) em vez de ser transferido automaticamente para o primeiro elemento interativo da modal (ex: botão "Aceitar todos").

    Image

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

    Recomendações:

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

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #60 Foco não fica limitado a caixa de diálogo

    etiqueta: chk 10 webetiqueta: R 9.2etiqueta: NOK

    Evidências:

    A navegação por teclado e leitores de ecrã não fica limitada aos elementos da caixa de diálogo. Durante a navegação, é possível interagir com elementos subjacentes à caixa de diálogo, fora do seu contexto.

    Image

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

    Recomendações:

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

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #61 A caixa dialogo não pode ser encerrada através da tecla ESC ou fechar

    etiqueta: chk 10 webetiqueta: R 9.3etiqueta: NOK

    Evidências:

    Verifica‑se que a caixa de diálogo não pode ser encerrada através da tecla ESC e também não possui um botão dedicado para fechar. Atualmente, para sair da modal é necessário acionar um dos botões “Aceitar todos”, “Rejeitar todos” ou “Guardar”, o que não é explícito tal como um botão de "Fechar".

    Image

    Recomendações:

    • Idealmente podem implementar um mecanismo que permita o encerramento das janelas modais através da tecla ESC.
    • Devem incluir um botão de fechar claramente identificado na caixa de diálogo, permitindo ao utilizador encerrar o componente de forma simples e independente.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #62 Ao fechar a caixa de diálogo o cursor não retorna ao elemento que o acionou

    etiqueta: chk 10 webetiqueta: R 9.4etiqueta: NOK

    Evidências:
    Ao fechar a caixa de diálogo, o foco não é devolvido ao elemento que a acionou. Em vez disso, o foco é reposicionado em outro elemento da página prejudicando a navegação.

    Image

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

    Recomendações:

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

Checklist Conteúdo

etiqueta: NOK

Nível de conformidade:

  • Checklist Conteúdo: 11.8% (2/17)
    • Requisitos avaliados: 17 (17 aplicáveis)
    • Requisitos OK: 2
    • Requisitos NOK: 15

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

etiqueta: NOK

Lista de evidências recolhidas:

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

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

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

    Evidências:

    Na página inicial do website do Museu do Calçado, não aparece presente um resumo breve do próposito do site.

    Image

    Imagem da página inicial de museu-do-calcado.pt sem fazer scroll.

    Recomendações:

    Não existe qualquer resumo do propósito na Homepage do Museu do Calçado pelo que deve ser adicionado.

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

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

    Image

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

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #19 Falta de glossário para termos complexos

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

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

    Evidências:

    Foram identificados diversos termos complexos na página de Planear a sua visita sem qualquer definição associada. Além disso, não foi encontrado um glossário no website do Museu do Calçado.

    Image

    Imagem de vários termos complexos na página de planear a sua visita.

    Recomendações:

    Recomenda-se a criação de um glossário para apoiar a introdução de novos conteúdos, embora não seja obrigatório. No entanto, é necessário corrigir a página de Planear a sua visita, garantindo que todos os termos complexos apresentam uma definição associada.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #17 Falta de datas de atualização em blocos de conteúdo

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

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

    Evidências:

    Não foi possível identificar qualquer data de atualização nos blocos de conteúdo analisados, excetuando-se apenas as secções de notícias ou outros conteúdos que, por natureza, apresentam uma data de publicação associada. Esta ausência de informação temporal estende-se também à área de contactos, onde igualmente não foram encontradas indicações sobre a última atualização.

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

    Image

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

    Importa salientar que a ausência de datas de atualização não se limita apenas à página de contactos. Na realidade, verifica-se de forma transversal em praticamente todas as páginas com conteúdo informativo do site, o que agrava a perceção de desatualização e fragiliza a confiança do utilizador.

    Qualquer página que disponibilize informação relevante deveria apresentar, de forma clara, a data da última atualização, permitindo ao utilizador avaliar a sua atualidade e fiabilidade. Esta prática é especialmente importante em secções como Voltuntariados, Programas, Exposições e Visitas, entre outras, onde a informação pode sofrer alterações frequentes e ter impacto direto nas decisões dos utilizadores.

    Algumas páginas que evidenciam a necessidade de inclusão de uma data de atualização incluem, por exemplo:

    Recomendações:

    • Incluir a data de publicação e/ou última atualização em todos os conteúdos relevantes;

    • Garantir que essa informação está semanticamente estruturada;

    • Assegurar consistência na apresentação das datas em todo o site.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #16 Não há referência à entidade responsável pelos conteúdos

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

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

    Evidências:

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

    Apesar de existir no rodapé o logotipo da entidade e acesso rápido aos contactos. Observamos que o nome da entidade responsável não está disponível por extenso, o texto ”Todos os direitos reservados a museu-do-calcado.pt” remete ao próprio site.

    Image

    Imagem do rodapé do museu-do-calcado.pt

    Recomendações:

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

    Image

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

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #24 O conteúdo do site fica desformatado em resoluções mais pequenas

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

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

    Notas Gerais

    • Todos os conteúdos do site devem ser responsivos para garantir a sua legibilidade na maioria das resoluções e quando são escalados para tamanhos superiores.
    • Para garantir a legibilidade do corpo de texto, este deve ter um tamanho igual ou superior a 12pt, que equivale a 16px.

    Na página Exposição Intinerária, verificou-se que, ao alterar a resolução para uma mais pequena mobile por exemplo, o corpo de texto relativo à descrição da exposição apresenta problemas de formatação e é exibido com uma dimensão de letra inferior à recomendada, comprometendo a legibilidade e dificultando o acesso ao conteúdo por parte de utilizadores com necessidades de leitura ampliada. (Figura 1 e 2)

    Image

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

    Image

    Figura 2 - Corpo de texto com dimensão variável e inferior ao recomendado em versões mobile

    Recomendação

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

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

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

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

    Notas Gerais

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

    O website possui informações primárias com tamanho inferior a 12pontos(16px). Por exemplo, na página inicial com os textos do menu principal, as opções de primeiro nível e segundo nível estão abaixo do valor mínimo recomendado. (Figura 1)

    Image

    Figura 1 - Verificação do tamanho do texto nas opções de segundo nível do menu com apenas 14px

    Há botões de ação principal, com tamanho inferior ao recomendado. Por exemplo na secção “Agenda” da página inicial com o botão “Veja a agenda completa”. (Figura 2)

    Image

    Figura 2 - Verificação do tamanho de texto em botões no website

    Outras páginas com o mesmo problema, em botões:

    Além disso, na página inicial há componentes com informações primárias por exemplo textos informativos e botões dos cookies com dimensão inferior ao recomendado. (Figura 3)

    Image

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

    No rodapé, o formulário da Newsletter possui a frase “Sim, eu leio e aceito os Termos de Condições e Política de Privacidade” estas são consideradas informações primárias com tamanho 14px, inferior ao recomendado. (Figura 4)

    Image

    Figura 4 - Textos com informações primárias do formulário da Newsletter no rodapé com dimensão inferior ao recomendado

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

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #26 Informações secundárias com o tamanho mínimo recomendado

    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

    Notas Gerais

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

    Durante a análise foram identificadas informações secundárias apresentadas com um tamanho de letra inferior ao mínimo recomendado. Por exemplo, na página Contactos, os textos dos campos “Obrigatório” possuem valor de 11px, não cumpre o presente critério. Esta dimensão reduzida compromete a legibilidade e cria barreiras para utilizadores com baixa visão ou que necessitem de ampliar o conteúdo. (Figura 1)

    Image

    Figura 1 - Verificação do tamanho para informações secundárias com valor inferior ao recomendado



    O mesmo problema acontece no rodapé, com o formulário da Newsletter:


    Recomendação de melhoria


    Recomendamos revisar todo website, e aumentar o tamanho de letra das informações secundárias para, no mínimo 10 pontos(13px). Garantindo simultaneamente que a fonte permanece escalável, permitindo ampliação por tecnologias assistivas ou pelo zoom do navegador;

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #22 Hiperligações sem indicação visual complementar

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

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

    Evidências:

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

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

    Image

    Títulos das notícias e agendas são hiperligações com sublinhado apenas em hover

    Image

    Todos os títulos das opções de ver mais conteúdo são hiperligações com sublinhado apenas em hover: Disponível em: https://www.museu-do-calcado.pt/pt/planear-a-sua-visita

    Todos os subníveis destes seguintes menus de navegação incluem uma secção “Veja Também”, onde são apresentados os títulos de cada navegação, porém sem qualquer indicação visual que os destaque ou diferencie como hiperligação:

    Recomendações:

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

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    Banner inicial da página principal em dispositivo móvel com conteúdo parcialmente cortado devido à má adaptação responsiva

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

    Carrossel de notícias em dispositivo móvel com elementos parcialmente cortados devido à falta de 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.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #5 Elementos interativos dependentes de hover para acesso

    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.

    Menu principal com submenus de navegação que dependem de interação por hover/clique e não são acessíveis por 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.

    Secção de visitas virtuais com botão “Abrir vista virtual” apenas visível no estado hover, não estando disponível no estado inicial

    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

    Vista em dispositivo móvel da secção de visitas virtuais, onde não é apresentado o botão “Abrir vista virtual” devido à dependência de interação por hover

    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.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #4 Elementos interativos com dimensão inferior ao mínimo recomendado

    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.

    Formulário com opção de subscrição contendo checkbox de dimensão reduzida associado ao botão “Subscrever”

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

    Ícone de envio (cartinha) no formulário de subscrição com dimensão reduzida, comprometendo a área de interação e a usabilidade do elemento

    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

    Formulário de contacto com botão de submissão de dimensão reduzida, comprometendo a área de interaçã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.

    Ícone de menu hambúrguer em versão mobile com dimensão reduzida (~20px), comprometendo a área de interação e a usabilidade do controlo de navegação

    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.

Requisito 5.3 - Há apenas um botão de ação principal por página e o mesmo encontra-se destacado

etiqueta: NOK

Lista de evidências recolhidas:

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

    Página de agenda com vários elementos interativos apresentados com estilo visual uniforme, sem distinção clara de ações principais e secundárias

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

    Página de contactos com botão de submissão do formulário com destaque visual insuficiente face aos restantes elementos interativos

    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.

    Modal de personalização de cookies com destaque no estado hover, onde os botões apresentam comportamento visual semelhante, reduzindo a distinção entre ações

    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.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    Banner de cookies com botões “Personalizar” e “Rejeitar todos” sem indicação visual clara de interatividade no estado inicial

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

    Ecrã de personalização de cookies com botão “Guardar” sem indicação visual clara de interatividade, apresentado apenas com contorno

    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.

    Secção de visitas virtuais no estado inativo, onde o botão “Abrir vista virtual” apresenta baixo contraste visual em relação ao fundo

    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

    Secção de visitas virtuais no estado ativo, com destaque para o botão “Abrir vista virtual” em hover, apresentando contraste melhorado mas ainda insuficiente

    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.

    Menu principal do website com itens de navegação apresentados como texto simples sem indicação visual clara de interatividade no estado inicial

    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.

    Elemento de data apresentado com estilo visual semelhante a botão, incluindo contorno, sem funcionalidade interativa associada

    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.

    Botão “Sobre o evento” sobreposto a imagem de fundo com baixo contraste, dificultando a sua perceção

    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.

    Controlos do carrossel com baixo contraste em relação à imagem de fundo, dificultando a perceção dos botões de navegação

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

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

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

    Ícones de redes sociais com contraste reduzido em fundo claro e elemento gráfico adjacente com aparência semelhante a controlos de carrossel, sem função interativa associada

    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.

    Elemento gráfico adjacente a controlos de navegação com aparência semelhante a botões do carrossel, sem funcionalidade interativa associada, podendo induzir o utilizador em erro

    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.

    Menu de navegação fixo com fundo semitransparente sobrepondo o conteúdo da página durante o scroll, afetando a perceção visual dos elementos subjacentes em versões mobile e desktop

    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.

Checklist Transação

etiqueta: NOK

Nível de conformidade:

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

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #42 Campo de email dependente da aceitação dos Termos e Condições

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

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

    No formulário de subscrição da newsletter, localizado no rodapé do site, verificámos que o campo de email está desativado por defeito. O campo só fica ativo depois de o utilizador selecionar a caixa de verificação “Sim, eu li e aceito os Termos e Condições e a Política de Privacidade”, que se encontra abaixo do campo de email.

    Esta configuração cria um problema de ordem de foco e navegação: o campo de email aparece antes da caixa de verificação — tanto visualmente como na ordem de leitura das tecnologias de apoio — mas só pode ser utilizado depois de essa caixa ser selecionada. Além disso, não é intuitivo para o utilizador que o campo apenas ficará ativo após aceitar os termos e condições.

    Recomendamos que o campo de email esteja ativo por defeito e que a sua utilização não dependa da seleção prévia da caixa de verificação.

    Image

    Figura - Análise do formulário para subscrição da newsletter, localizado no rodapé do site, através do Google Inspector.

  • issue #30 O link para submissão do formulário é ignorado quando se navega por teclado (Tab e Shift + Tab)

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

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

    Ao navegar pelo formulário com o teclado usando a tecla Tab, a sequência de tabulação deve seguir a ordem de preenchimento, passando por todos os campos disponíveis.

    Verificámos que, na página Contactos, ao navegar por teclado (Tab e Shift+Tab), não é possível focar no link “Enviar” - cuja função é a de submeter a informação recolhida no formulário.

    Recomendamos que a <div> dentro da qual se encontra este elemento (<div class="btn-input-submit">) seja substituída pelo elemento HTML nativo semântico <button>.

    Image

    Figura 1 - Navegação na página Contactos através de Tab e Shift+Tab e pelo leitor de ecrã NVDA. Não é possível focar no link "Enviar" do formulário.

    Image

    Figura 2 - Análise do link Enviar, na página Contactos, através do Google Inspector.

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

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #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)".

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

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #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".

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    Image

    Figura - Formulário da página Contactos.

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

etiqueta: N/A

Lista de evidências recolhidas:

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

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #54 Existem campos do formulário cuja legenda não é clara

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

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

    As legendas dos campos devem ser claras, curtas e concisas, para que sejam rapidamente entendidas pelo utilizador.

    Verificámos que nos campos “Informação Extra”(do formulário da página Contactos) e “Subscrever Newsletter” (do formulário localizado no rodapé do site para subscrição da newsletter) a legenda não corresponde ao tipo de conteúdo que o utilizador deve inserir.

    Estas legendas devem ser ajustadas para indicar de forma clara e precisa que informação é esperada. Neste caso, uma possível solução seria alterar as legendas para “Mensagem” e “Email”, respetivamente.

    Image

    Figura 1 - Análise do rótulo do campo de inserção de email no formulário de subscrição da newsletter, localizado no rodapé do site, através do Google Inspector.

    Image

    Figura 2 - Formulário da página Contactos.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    Image

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

    Image

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

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

    Image

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

    Image

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

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

    Image

    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.

    Image

    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.

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

etiqueta: N/A

Lista de evidências recolhidas:

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

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

etiqueta: NOK

Lista de evidências recolhidas:

  • 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

    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.

    Image

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

    Image

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

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

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #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".

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    Image

    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:

    Image

    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.

    Image

    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>

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    Image

    Mensagem de erro no topo da página que não guia o utilizador na resolução do erro
    Como observado na figura, a mensagem “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.

Outras violações

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

Lista de evidências recolhidas:

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

    Image

    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.

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

    Image

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

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

    Image

    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.

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

    Image

    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.

    Image

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

Significado das etiquetas utilizadas