Relatório Avaliação de Candidatura
Museu da Chapelaria

Introdução

O website https://www.museudachapelaria.pt/pt/inicio 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 aspetos22.7% (5/22)etiqueta: Não passa
Conteúdo17.6% (3/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.

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

Declaração de Acessibilidade

etiqueta: NOK

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

Lista de evidências recolhidas:

Avaliação automática

etiqueta: NOK

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

Lista de evidências recolhidas:

Avaliação manual

etiqueta: NOK

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

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

Checklist 10 aspetos

etiqueta: NOK

Nível de conformidade:

  • Checklist 10 aspetos: 22.7% (5/22)
    • Requisitos avaliados: 27 (5 N/A excluídos, 22 aplicáveis)
    • Requisitos OK: 5
    • Requisitos NOK: 17
    • Requisitos N/A: 5

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 #61 As opções do rodapé não estão estruturadas como lista

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.1

    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 #64 Não é possível aceder as subopções do menu com o leitor de ecrã e teclado

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.2

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

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

    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 no menu compacto e desktop.
    • O mesmo elemento é utilizado simultaneamente para expandir/contrair subopções e para aceder a página interna, como por exemplo “Sobre o 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". Para mais informações recomendamos consultarem a issue #25 .
    • 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 #63 As opções do menu não apresentam uma indicação visual de que contêm subopções

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.2

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

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

    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 #64 , pois trata‑se de correções a serem efetuadas no menu e que estão relacionadas também com este problema.

  • issue #62 O menu mobile não está acessível pelo teclado e leitor de ecrã

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.2

    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 #46 .

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 #65 (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:

    • #64
    • #63

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #49 Logo na homepage não está corretamente marcado como h1

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 2.1

    O elemento H1 deve ser atribuído ao logótipo do website, exclusivamente na página inicial. Verifica-se que na página inicial o h1 está sendo atribuído ao texto "Da fábrica ao Museu, a sua visita começa aqui." de forma inapropriada.

    Evidencias:

    Image

    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.

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 #56 Não foram encontradas tabelas

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

    Evidencias:

    Não foram encontradas tabelas no website, por isso o requisito 3.1 é considerado não aplicável.

    Recomendações:
    N/A

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

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #57 Não foram encontradas tabelas no website

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

    Evidencias:

    Não foram encontradas tabelas no website, por isso o requisito 3.2 é considerado não aplicável.

    Recomendações:
    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 #29 Existem campos com etiquetas pouco claras

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.1

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

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

    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 #35 Existem campos de preenchimento obrigatório sem indicação para as tecnologias de apoio

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.2

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

    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.

  • issue #34 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 #32 Existem formulários com a indicação de campo de preenchimento obrigatório duplicada

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.2

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

    Os campos obrigatórios dos formulários devem estar devidamente identificados como tal. Idealmente, devem apresentar o texto “Obrigatório” à frente da legenda do campo. 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).

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 #36 Existem formulários sem Mensagens de erro junto aos campos

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.3

    É possível localizar e ler as mensagens de erro usando apenas um leitor de ecrã.
    – ver requisito 4.3 na lista 10 aspetos

    O formulário 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
    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:

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #17 Existem imagens link com texto alternativo incorreto

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.3

    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

    Verifica-se também um exemplo onde a imagem (Acesso a homepage) não apresenta texto alternativo através do atributo alt, estando a informação acessível apenas no atributo title. Deve ser alterado, uma vez que o title não constitui um mecanismo fiável para fornecer alternativa textual a imagens, não sendo anunciado de forma consistente por leitores de ecrã:

    Image 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

    URL:

    https://www.museudachapelaria.pt/pt/programacao
    https://www.museudachapelaria.pt/pt/contactos

    Recomendações:

    • O texto alternativo deve transmitir claramente o destino ou finalidade do link. Por exemplo: alt="Museu da Chapelaria – página inicial"
    • O atributo title não deve ser utilizado como mecanismo principal para fornecer informação acessível, devendo o nome acessível ser garantido através de atributos como alt ou aria-label.

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 #71 Texto normal não tem contraste suficiente

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 6.1

    No corpo de um documento, o rácio de contraste entre a cor do texto normal (menor que 18 pontos ou menor que 14 pontos negrito) e a cor do fundo é superior a 4,5:1.
    – ver requisito 6.1 na lista 10 aspetos

    Notas gerais

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

    A avaliação com as ferramentas Colour Contrast Analyser e WAVE revelam problemas relacionados com insuficiência de contraste, afetando diretamente a legibilidade.

    A menu principal do website apresenta problemas de contraste nas opções de primeiro nível com a combinação de cores #F44800(cor de primeiro plano) e #FFFFFF(cor de plano de fundo). E também com as cores da interação de hover das opções de segundo nível com as cores #F44800(cor de primeiro plano) e #232323(cor de plano de fundo)(Figura 1)

    Image

    Figura 1- Menu com problemas de contraste em textos normais

    O mesmo acontece na interação de hover com os textos das opções “Português” e “Inglês”, que apresentam taxa de contraste inferior ao recomendado. Na combinação de cores #F44800(cor de primeiro plano) e #FFFFFF(cor de plano de fundo) (Figura 2)

    Image

    Figura 2- Página em inglês com problema de contraste nas interações com hover para textos normais

    Na página Contactos os textos do placeholder “Introduza o seu nome”, “Introduza o seu endereço de email”, “Introduza o assunto”, “Introduza o seu telefone” e “Adcione informações extra se necessário” apresentam baixo rácio de contraste para texto normal. Nas combinações de cores #FFFFFF (cor de primeiro plano) e #9EC222(cor de plano de fundo) com taxa de contraste inferior ao recomendado. (Figura 3)

    Image

    Figura 3- Textos do placeholder com 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 #72 Textos grandes não têm contraste suficiente

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 6.2

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

    Notas Gerais

    • Os textos de tamanho superior a 18 pontos, ou os textos de tamanho superior a 14 pontos mas a negrito, devem assegurar um rácio de contraste mínimo de 3:1 entre a cor do texto e a cor do fundo, para que as pessoas com baixa visão consigam ler o texto.

    Em todo website os textos grandes dos títulos apresentam problemas de contrastes nos estados de hover. Por exemplo, títulos das “Notícias” do banner principal da página, da “Agenda” e com tamanho de 28px, apresentam problemas de contraste com a combinação de cores #F44800(cor de primeiro plano) e #FFFFFF(cor de plano de fundo) (Figura 1)

    Image

    Figura 1- Texto grande de títulos não passam na avaliação de contraste”

    Ainda na página inicial, o mesmo problema acontece nas secções “A acontecer” e “Visitas virtuais” com os textos grandes 28px na combinação de cores #F44800(cor de primeiro plano) e #FDF5F1(cor de plano de fundo) não passam na avaliação de contraste. (Figura 2)

    Image

    Figura 2- Texto grande para as datas não passa na avaliação de contraste”

    O mesmo problema acontece nas páginas:

    Recomendações

    Recomendamos a revisão das cores das páginas para garantir os valores mínimos de contraste do texto grande, principalmente nos pares de cores indicados mas também em todo o website.
    Caso exista texto grande com pouco contraste, em que as cores utilizadas sejam as mesmas do logótipo da entidade, recomendamos a substituição dessas cores por outras que garantam um contraste mínimo de 3:1. Por exemplo, podem ser usados tons semelhantes ao do logotipo ou outras cores da identidade gráfica da marca.

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 #54 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 multimédia de vídeo ou áudio com controlos de reprodução, sendo apenas apresentada uma experiência interativa de visita 360, pelo que não existem elementos aplicáveis a este critério.

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 #55 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 multimédia de vídeo ou áudio, pelo que não existem elementos que requeiram legendas sincronizadas 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 #47 Ordem de leitura incorreta no formulário de newsletter

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.2

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

    Notas Gerais

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

    URL a verificar

    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_048/issues/25, por abordar um problema relacionado com o preenchimento da newsletter

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

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.2

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

    • 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

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 #76 Controlos interativos implementados com elementos não semânticos

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

    Notas Gerais

    • Os elementos interativos devem ser implementados com 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

    https://www.museudachapelaria.pt/pt/visitas-virtuais/museu-da-chapelaria
    (outras visitas virtuais)

    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

    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 #73 Selector de idioma sem estrutura semântica adequada

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

    Notas Gerais

    • 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 (“Português” e “English”), 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.
    • O separador “/” é implementado como conteúdo no DOM, podendo ser lido desnecessariamente por tecnologias de apoio.
    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")
    • Evitar o uso de elementos decorativos no DOM (como “/”), recorrendo a CSS ou aria-hidden="true"

  • 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 contém tres 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 #44 Listagem de conteúdos não estruturada semanticamente como lista

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

    Notas Gerais

    • 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.5 - A maquetização da página é feita sem recorrer ao elemento table

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #48 Não existem conteúdos com layout organizado em elementos de tabela

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

    A maquetização da página é feita sem recorrer ao elemento <table>.
    – ver requisito 8.5 na lista 10 aspetos

    Evidências:
    Não foram identificados conteúdos que estão utilizando elementos de tabela para fins de layout ou apenas para apresentação e estilização. Sendo assim, o critério está a cumprir.

    Recomendações:
    N/A

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 #28 Quando a caixa de diálogo é aberta, não move-se para um elemento dentro da caixa de diálogo

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.1

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

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.2

    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.museudachapelaria.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 #31 A caixa dialogo não pode ser encerrada através da tecla ESC ou fechar

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.3

    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

    URL:

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

    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 #33 Ao fechar a caixa de diálogo o cursor não retorna ao elemento que o acionou.

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.4

    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.museudachapelaria.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: 17.6% (3/17)
    • Requisitos avaliados: 17 (17 aplicáveis)
    • Requisitos OK: 3
    • Requisitos NOK: 14

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 #14 Falta de resumo na página inicial do website

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 1.1

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

    Evidências:

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

    Image

    Imagem da página inicial de museudachapelaria.pt sem fazer scroll.

    Recomendações:

    Não existe qualquer resumo do propósito na Homepage do Museu da Chapelaria 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: NOKetiqueta: R 1.2

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

    Evidências:

    Ao longo do website, é possível identificar a utilização de diversos termos técnicos e complexos que surgem sem qualquer definição ou explicação associada. Na ausência de um glossário ou de mecanismos que permitam esclarecer esses conceitos, os utilizadores podem ter dificuldade em compreender plenamente a informação apresentada, especialmente aqueles que não estão familiarizados com a terminologia utilizada.

    Esta limitação compromete a acessibilidade e a clareza dos conteúdos, uma vez que obriga o utilizador a procurar significados fora do contexto do site ou a interpretar incorretamente a informação.

    Image

    Imagem com o termo complexo "IPSS" na página de planear a sua visita.

    Image

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

    Image

    Imagem com o termo complexo "IPO" na página de notícias.

    Recomendações:

    Recomenda-se a criação de um glossário que permita a utilização consistente de siglas ao longo do website, evitando que o utilizador tenha de procurar repetidamente a sua definição noutros parágrafos.

    Como exemplo podem visualizar o glossario do acessibilidade.gov. https://www.acessibilidade.gov.pt/glossario/

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 1.3

    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 Serviços, Voltuntariados, Programas, Regulamentos e Acessibilidades, 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 #13 Não há referência à entidade responsável pelos conteúdos

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 1.4

    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 museudachapelaria.pt” remete ao próprio site.

    Image

    Imagem do rodapé do museudachapelaria.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 eodapé 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 #75 O conteúdo do site fica desformatado em resoluções mais pequenas

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 2.1

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

    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.

    Nas página Exposição temporária, verificou-se que, ao alterar a resolução para uma mais pequena mobile por exemplo, o corpo de texto do conteúdo da descrição da exposição ficou desformatado e com uma dimensão inferior ao recomendado.

    Image

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

    Image

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

    Recomendação
    As páginas deverão ser revistas para garantir que todo o conteúdo se adapta a diferentes resoluções de ecrã.

  • issue #74 O corpo de texto tem um tamanho inferior a 12pt (equivalente a 16px)

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 2.1

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

    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 Serviços no 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 “A acontecer” da página inicial com o botão “Veja a agenda completa”. (Figura 2)

    Image

    Figura 2 - Verificação do tamanho de texto dos botões

    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 no formulário da Newsletter. (Figura 3 e 4)

    Image

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

    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:

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:

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #6 Elementos interativos dependentes de hover para acesso

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.1

    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.museudachapelaria.pt/pt/inicio (Menu principal de todo website)

    O menu principal apresenta submenus que apenas são exibidos através de interação com rato (hover ou clique), não sendo possível aceder ou navegar para esses submenus através de navegação por teclado. Desta forma, a funcionalidade de navegação hierárquica do menu depende de interação com hover, não estando disponível de forma equivalente para utilizadores que utilizam apenas teclado.

    Menu de navegação com itens sem indicação visual consistente de elemento clicável no estado inicial

    Figura 01 – Menu de navegação com inconsistência na perceção de elementos clicáveis no estado inicial

    Recomendação
    Deve ser garantido que os submenus são acessíveis por teclado, permitindo a abertura, navegação e fecho através de interação equivalente à do rato.

    A interação não deve depender exclusivamente de hover, devendo existir suporte para navegação por foco e controlo adequado de estado do menu

    Ponto 02
    Página: https://www.museudachapelaria.pt/pt/visitas-virtuais

    Foi identificado um botão de “Visita Virtual” que apenas fica visível ou ativo através da ação de hover (passagem do rato). Este comportamento impede o acesso consistente ao elemento em dispositivos que não suportam hover, como smartphones e tablets, e pode também dificultar a navegação por teclado.

    Como resultado, a funcionalidade não está igualmente acessível a todos os utilizadores.

    Botão de visita virtual visível apenas em estado de hover

    Figura 02 – Botão de “Visita Virtual” com comportamento dependente de hover para acesso à funcionalidade

    Recomendação
    O botão e a respetiva funcionalidade de “Visita Virtual” devem estar sempre visíveis e acessíveis, independentemente da interação por hover.

    Deve ser garantido que o elemento possa ser ativado através de clique/toque e navegação por teclado, assegurando a sua utilização em todos os dispositivos e contextos de navegação.

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

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.2

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

    Ponto 01:
    Páginas:
    https://www.museudachapelaria.pt/pt/inicio
    https://www.museudachapelaria.pt/pt/contactos

    Os checkboxes presentes no formulário de contacto e no campo de subscrição apresentam uma dimensão aproximada de 16px, o que se encontra abaixo do mínimo recomendado para elementos interativos.

    Esta dimensão reduzida dificulta a interação, especialmente em dispositivos de toque, comprometendo a usabilidade do componente.

    Botão subscrever com dimensão reduzida (16px)

    Figura 01 – Botão de subscrição com dimensão inferior ao recomendado (16px)

    checkbox do formulário de contacto com com dimensão reduzida (16px)

    Figura 02 – Checkbox do formulário de contacto com dimensão inferior ao recomendado (16px)

    Recomendação
    Os elementos interativos (checkboxes) devem ter uma dimensão mínima de 44px CSS em altura e largura, garantindo maior área de interação e melhor usabilidade em diferentes dispositivos.

    Ponto 02
    Página: https://www.museudachapelaria.pt/pt/eventos-no-museu

    Os controlos do carrossel apresentam dimensões reduzidas (aprox. 32px), abaixo do mínimo recomendado de 44px para elementos interativos.

    Esta dimensão reduzida pode dificultar a interação por parte dos utilizadores, especialmente em dispositivos táteis, onde a precisão do toque é mais limitada.

    Controlo de navegação do carrossel com dimensão reduzida (32px)

    Figura 01 – Controlo do carrossel com dimensão inferior ao recomendado (32px)

    Outro exemplo:
    https://www.museudachapelaria.pt/pt/contactos

    Recomendação
    Os controlos do carrossel devem cumprir os requisitos mínimos de dimensão (44px) e apresentar contraste suficiente em todos os estados (ativo e inativo).

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:

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.4

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

    Ponto 01
    Página: https://www.museudachapelaria.pt/pt/inicio

    O menu principal apresenta inconsistência na perceção de elementos interativos. Alguns itens, como “Início”, possuem um indicador visual (sublinhado laranja) que reforça a sua natureza clicável, enquanto os restantes itens de navegação (“Sobre o Museu”, “Serviços”, “Programação”, “Visite-nos”, “Loja”) são apresentados como texto simples, sem qualquer indicação visual de interatividade no estado inicial.

    A perceção de que estes elementos são clicáveis apenas ocorre no estado de hover, quando o texto muda de cor.

    Menu de navegação com inconsistência na indicação visual de elementos clicáveis entre itens ativos e não ativos

    Figura 01 – Menu de navegação com inconsistência na affordance visual dos itens clicáveis no estado inicial

    Recomendação

    Deve ser garantida uma affordance visual consistente para todos os elementos interativos do menu, assegurando que são reconhecidos como clicáveis no estado inicial.

    Recomenda-se a aplicação de um padrão visual uniforme (ex: sublinhado, estilo de link consistente ou outro indicador visual permanente) para todos os itens de navegação, garantindo coerência e clareza na interação independentemente do estado de hover.

    Ponto 02
    Página: https://www.museudachapelaria.pt/pt/agenda/workshops-e-oficinas-criativas/festas-de-aniversario-no-museu

    O elemento “01 Janeiro a 31 Dezembro 2026” apresenta contorno e formatação semelhantes aos elementos interativos da página, como botões, embora utilize uma cor distinta (preto em vez de laranja). No entanto, este elemento não possui qualquer funcionalidade interativa.

    Esta proximidade visual com componentes clicáveis pode induzir o utilizador em erro, criando a expectativa de que o elemento seja acionável, o que compromete a clareza e previsibilidade da interface.

    Elemento com aparência de botão sem funcionalidade interativa

    Figura 1 – Elemento com aparência de botão sem funcionalidade interativa

    Outros exemplos
    https://www.museudachapelaria.pt/pt/agenda/eventos/exposicao-temporaria
    https://www.museudachapelaria.pt/pt/agenda/eventos/exposicao-temporaria-3
    https://www.museudachapelaria.pt/pt/agenda/eventos/encontros-na-moagem
    https://www.museudachapelaria.pt/pt/agenda/workshops-e-oficinas-criativas/culturando-por-ai-3

    Recomendação
    Garantir que elementos não interativos não utilizam estilos visuais semelhantes aos de componentes clicáveis, como botões. Alternativamente, caso o elemento deva ser interativo, deve ser implementada a respetiva funcionalidade e assegurada uma diferenciação clara ou consistência com os restantes elementos interativos da página.

    Ponto 03
    Página: https://www.museudachapelaria.pt/

    O botão “Aceitar todos” apresenta um contorno que o distingue dos restantes botões (“Personalizar” e “Rejeitar cookies”), no entanto, esta diferenciação visual não é suficientemente forte para garantir uma hierarquia clara entre a ação principal e as ações secundárias.

    Adicionalmente, no estado de hover, todos os botões apresentam um comportamento visual semelhante (preenchimento), o que reduz a distinção entre ação primária e secundárias.

    Esta mesma inconsistência estende-se ao ecrã de personalização de cookies, onde o botão “Guardar” também não apresenta destaque visual suficiente enquanto ação principal do fluxo, sendo igualmente apresentado com estilo pouco diferenciado (contorno), comprometendo a hierarquia de ações dentro do modal.

    Banner de cookies com fraca hierarquia visual entre ação primária e ações secundárias no estado inicial

    Figura 01 – Banner de cookies no estado inicial sem hierarquia visual clara entre ação primária e ações secundárias

    Banner de cookies onde todos os botões assumem aparência semelhante no estado de hover, reduzindo a hierarquia visual

    Figura 02 – Banner de cookies no estado de hover com redução da hierarquia visual entre ação primária e ações secundárias

    Modal de personalização de cookies onde o botão Guardar não apresenta destaque visual como ação principal

    Figura 03 – Modal de personalização de cookies com ausência de destaque visual no botão “Guardar”

    Recomendação
    Deve ser garantida uma hierarquia visual clara e consistente entre ação primária e ações secundárias em todos os componentes do fluxo de cookies (banner e modal de personalização).

    O botão “Aceitar todos” deve apresentar um destaque mais evidente (por exemplo, fundo sólido com cor de destaque da marca e maior peso visual), mantendo-se claramente identificado como ação principal em todos os estados (default e hover).

    No modal de personalização de cookies, o botão “Guardar” deve igualmente assumir o papel de ação primária do fluxo, devendo apresentar o mesmo nível de destaque visual, garantindo consistência na hierarquia de ações.

    Os botões “Personalizar” e “Rejeitar cookies” devem assumir um estilo secundário mais neutro (outline ou texto), sem competir visualmente com a ação principal e sem alterações de hover que reduzam a hierarquia entre os elementos.

    Ponto 04
    Página: https://www.museudachapelaria.pt/pt/eventos-no-museu

    Foram identificados elementos gráficos interativos (como botões/ícones de navegação) que apresentam baixo contraste em relação ao fundo, especialmente no estado inicial/inativo.

    Esta condição dificulta a perceção visual dos elementos, tornando menos evidente a sua natureza interativa e podendo afetar a sua identificação por alguns utilizadores.

    Carrossel com controlo de navegação em estado inativo com baixo contraste visual

    Figura 01 – Controlo do carrossel em estado inativo com baixo contraste visual

    Carrossel com controlo de navegação em estado ativo com contraste ligeiramente superior, mas ainda insuficiente

    Figura 02 – Controlo do carrossel em estado ativo com contraste insuficiente

    Recomendação
    Deve ser garantido um nível de contraste adequado entre os elementos interativos e o respetivo fundo em todos os estados (inicial, hover e ativo).
    Os controlos devem manter-se claramente visíveis e distinguíveis, de forma a assegurar uma melhor perceção visual e facilitar a sua identificação como elementos clicáveis.

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 #25 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 - Formulário para subscrição da newsletter no rodapé do site.

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

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

    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 por teclado (Tab e Shift + Tab) e através do leitor NVDA. Não é possível focar no link "Enviar".

    Image

    Figura 2 - Análise do link "Enviar" do formulário da página Contactos.

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 #4 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 da Chapelaria 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 #5 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 da Chapelaria. Assim, este requisito fica avaliado como "Não Aplicável (N/A)".

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

etiqueta: NOK

Lista de evidências recolhidas:

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

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

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

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

    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. Campo "Telefone" é demasiado largo para os dados a inserir e o campo "Nome" demasiado estreito para um nome completo.

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

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #9 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 da Chapelaria, 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 #10 Existem campos do formulário cuja legenda não é clara

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

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

    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 - Formulário da página Contactos.

    Image

    Figura 2 - Análise do rótulo do formulário para subscrição da newsletter através do Google Inspector.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #21 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 - Campos obrigatórios, no formulário da página Contactos, têm à frente dos seus rótulos a indicação "Obrigatório *".

    Image

    Figura 2 - Campo para inserção do email, no formulário da newsletter, tem à frente do rótulo a indicação "Obrigatório *".

  • issue #15 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 do campo para inserção do email, no formulário para subscrever a newsletter, através do Google Inspector.

    Image

    Figura 2 - Análise do campo "Nome", no formulário da página Contactos, através do Google Inspector.

  • issue #12 Não é possível identificar campos obrigatórios

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

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

    Os campos 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, o leitor de ecrã não reconhece o campo “Sim, 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 formulário para subscrição da newsletter, localizado no rodapé do site, através do leitor de ecrã NVDA.

    Image

    Figura 2 - Análise do formulário para subscrição da newsletter 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 #22 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 #23 Confirmação de sucesso invisível para tecnologias de apoio.

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

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

    Notas Gerais

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

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #37 Existem formulários sem Mensagens de erro junto aos campos

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

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

    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
    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: NOKetiqueta: R 4.4

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

    A mensagem de erro “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 3 melhorias que se recomenda efetuar)

Lista de evidências recolhidas:

  • issue #68 Outras violações - Barreiras de acessibilidade na visita virtual

    etiqueta: melhoriaetiqueta: outras violações

    Na visita virtual disponível na página do Museu da Chapelaria, identificámos alguns problemas que comprometem a acessibilidade dos utilizadores. Atualmente, não é possível aceder ou interagir com os diferentes planos da visita virtual através do teclado ou de leitores de ecrã. Além disso, sendo uma experiência fortemente baseada em elementos visuais, é essencial incluir descrições textuais que expliquem o espaço representado.

    Algumas melhorias que podem ser implementadas para tornar esta visita virtual mais acessível incluem:

    • Navegação por teclado e compatibilidade com leitores de ecrã: Garantir que todos os elementos da visita virtual podem ser acedidos e controlados através do teclado. É importante desenvolver funcionalidades que permitam aos utilizadores percorrer os diferentes pontos da visita utilizando atalhos de teclado e que estes sejam corretamente anunciados por tecnologias de apoio.

    • Descrições textuais do espaço: Como se trata de um recurso altamente dependente de imagética, é fundamental disponibilizar transcrições ou descrições textuais detalhadas dos espaços e artefactos apresentados. Estas descrições permitem que pessoas cegas ou com baixa visão compreendam o conteúdo da visita.

    • Legendas para conteúdos áudio: Caso exista informação transmitida por áudio durante a visita virtual, devem ser fornecidas legendas fechadas que reproduzam integralmente o conteúdo verbal. Esta medida beneficia tanto utilizadores com deficiência auditiva como aqueles que preferem ler a informação.

    Image

    Figura - Navegação pelo conteúdo da visita virtual através do leitor de ecrã NVDA.

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

    etiqueta: melhoriaetiqueta: outras violações

    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 da Chapelaria, 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.

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

    etiqueta: melhoriaetiqueta: outras violações

    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.

Significado das etiquetas utilizadas