Relatório Avaliação da Candidatura da Temporada Música em São Roque

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #59 Os breadcrumbs não estão estruturados como lista de opções

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.1

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

  • Ver requisito 1.1 da lista 10 aspetos

  Evidencias:

  O elemento de breadcrumbs não está estruturado como lista (<ul><li>), mas como um <p>, que contém o link Início, a barra (/) e o texto Concerto Atlântico, que é lido de uma vez só pelo leitor de ecrã.

  

  Figura 1 - Leitor de ecrã lê o conteúdo das breadcrumbs como um só, porque está contido num <p>.

  Recomendações:

  Rever todas as breadcrumbs do site para que fiquem estruturadas como lista (<ul><li>), e dentro de um elemento <nav>.

  O atributo aria-label, por exemplo, aria-label="Breadcrumb" ou aria-label="Localização atual" deve ser adicionado ao elemento <nav> para distinguir da navegação principal do website que também utiliza o elemento <nav>. Quando existem vários elementos <nav> numa única página, todos devem ter um nome acessível único através do aria-label.

  Podem consultar a página Breadcrumbs do Design System da W3C para mais informação, ou até mesmo a construção da Escola Superior de Saúde de Alcoitão.

• evidência: issue #1 A lista de opções do menu de navegação é contabilizada incorretamente

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.1

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

  • Ver requisito 1.1 da lista 10 aspetos

  Evidências

  Os elementos do menu de navegação estão corretamente estruturados como uma lista, utilizando as tags <ul> e <li>. No entanto, verificou-se que o NVDA anuncia o conteúdo gerado via CSS, a propriedade content: "Menu" do pseudo-elemento ::before, como se fosse mais um item da lista.

  

  Figura 1 - Pseudo-elemento ::before tem a propriedade content: Menu no CSS.

  Como resultado, em vez de quatro opções reais, o leitor de ecrã anuncia cinco. Este comportamento, embora inconsistente entre browsers, representa um problema de acessibilidade, uma vez que informação sem valor semântico é exposta ao utilizador.

  

  Figura 2 - Leitor de ecrã NVDA anuncia que existem 5 opções em desktop.

  O texto "Menu" também está a ser lido pelo Talkback nos dispositivos Android, mas nessa interação já não contabiliza como opção de lista, o que significa que existe um comportamento inconsistente entre os diferentes leitores de ecrãs e browsers.

  Recomendações

  Recomenda-se remover a propriedade content: "Menu" do pseudo-elemento ::before no CSS e substituí-la por um elemento de cabeçalho explícito no HTML, como <h2>. Esta abordagem garante que o texto "Menu" é tratado como conteúdo semântico real, e não como conteúdo decorativo gerado via CSS, eliminando assim a inconsistência de anúncio entre diferentes leitores de ecrã e browsers.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #3 Existem imagens-link no menu com um equivalente alternativo em texto que não é compreensível

  etiqueta: R 1.3etiqueta: chk 10 webetiqueta: NOK

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

  • Ver requisito 1.3 da lista 10 aspetos

  Evidências

  Quando navegamos pelas opções do menu, o leitor de ecrã lê os atributos aria-label associado aos botões, não sendo perceptíveis para quem não compreende inglês, chavões técnicos. Além disso, os botões de abrir são iguais aos botões de fechar.

  Os botões são:

  • Alternar tema claro/escuro
  • Toggle Search (botão de abrir e fechar a pesquisa)
  • Toggle Menu (botão de abrir e fechar a pesquisa)

  

  Figura 1 - Leitor de ecrã lê os botões do menu do tema, pesquisa e search de acordo com os atributos aria-label.

  

  Figura 2 - O botão de "Fechar pesquisa" tem um aria-label igual ao botão que abre a pesquisa.

  Recomendações

  Alterar os atributos aria-label associados aos botões:

  • "Alternar tema claro/escuro" deve passar a ser aria-label="Mudar para tema escuro" no botão da lua, e aria-label="Mudar para tema claro" no botão do sol, para comunicar ao utilizador de leitor ecrã para qual tema irá mudar quando ativar o botão.
  • "Toggle Search" deve passar a ser aria-label="Pesquisar". O botão de fechar deve ser "Fechar pesquisa".
  • "Toggle Menu" deve passar a ser "aria-label="Menu". O botão de fechar deve ser "Fechar menu".

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #4 O título <h1> não atribuído ao conteúdo correto

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 2.1

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

  • Ver requisito 2.1 da lista 10 aspetos

  Evidências

  O elemento <h1> da página inicial está atualmente associado ao texto “37ª Temporada”, o que não é suficientemente descritivo nem permite identificar claramente o propósito da página. Para utilizadores de leitores de ecrã, que frequentemente navegam diretamente até ao primeiro cabeçalho para compreenderem em que página se encontram, esta abordagem dificulta a orientação.

  

  Figura 1 - INCORRETO: Na página inicial, o <h1> está atribuído a um texto genérico "37ª Temporada".

  Nas páginas secundárias, o <h1> está corretamente atribuído.

  

  Figura 2 - CORRETO: Nas páginas interiores da TMSR, o <h1> está a atribuído ao título do conteúdo principal da página.

  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. Neste caso, o <h1> da página inicial deve estar atribuído ao logótipo "Santa Casa e ESSAalcoitão - Escola Superior de Saúde", que tem o alt="Temporada Música em São Roque Logo. Devem remover a palavra "logo" do alt porque não acrescenta informação ao título.
  • O texto "37ª Temporada" deve ser estruturado como <h2>.
  • Nas páginas interiores, o <h1> deve estar atribuído ao título do conteúdo principal dessa página.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #5 Os títulos não seguem uma hierarquia lógica de conteúdo

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 2.2

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

  Evidências

  As página da secção "Programa", como Concerto Atlântico ou Ensemble CEO, apresentam uma estrutura de hierarquia de subtítulos que não contextualizam devidamente o utilizador e não apresentam uma hierarquia com lógica.

  

  Figura 1 - Acordeão Biografia contém dois elementos h3 que não estão devidamente contextualizados como sendo da secção Biografia.

  Além disso, a modal dos cookies tem um título estrutura como <h3>, comunicando que está inserida como subsecção de alguma secção com título <h2>, o que não faria sentido em termos de estrutura.

  

  Figura 2 - O título da modal dos Cookies está estruturado como <h3>.

  Recomendações

  • Em todas as páginas específicas dos eventos (ex: Coro ECCE), alterar os títulos das secções “Programa”, “Notas de Programa” e “Biografia” para elementos <h2> em todas as páginas de eventos com esta estrutura. Desta forma, os conteúdos dentro dos acordeões, que utilizam <h3>, passam a estar corretamente organizados numa hierarquia de títulos,

  • Alterar o título da janela modal de cookies para um elemento <h2>. Isto permite enquadrar corretamente esta secção dentro da estrutura da página, cujo título principal é <h1>, garantindo uma hierarquia de títulos consistente.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #8 A etiqueta está visualmente escondida e não está associada ao campo de input

  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

  Evidências

  Na barra de pesquisa do site, exibida após o utilizador clicar no botão da lupa no topo do site, verifica-se que o elemento <input> está inserido dentro da <label>, o que estabelece uma associação implícita entre ambos. No entanto, o texto da label encontra-se dentro de um <span> com a classe screen-reader-text, sendo assim ocultado visualmente e não sendo possível clicar na etiqueta com o rato.

  O texto “Pesquisar” visível no campo não corresponde a uma label, mas sim ao atributo placeholder. Embora o placeholder="Pesquisar..." cumpra uma função visual semelhante, não deve ser utilizado como substituto de uma label porque o placeholder desaparece assim que o utilizador começa a escrever, o que pode levar à perda de contexto, especialmente para pessoas com dificuldades de memória.

  Além disso, alguns leitores de ecrã anunciam tanto o aria-label como o placeholder, criando redundância (por exemplo: “Pesquisar… Pesquisar…”), como acontece neste site.

  

  Figura 1 - Barra de pesquisa no topo da página, onde o leitor de ecrã lê termo "Pesquisar", que deriva do placeholder e aria-label, porque a label está escondida através do CSS.

  O mesmo problema repete-se no campo de pesquisa que aparece nos resultados da pesquisa.

  

  Figura 2 - Campo de pesquisa que aparece nos resultados da pesquisa também apresenta os mesmos problemas.

  Recomendações

  • A etiqueta do campo deve estar visível em cima do campo e ser definida como elemento <label>, com o atributo for igual ao id do <input> correspondente, estabelecendo uma associação explícita entre ambos. Além do HTML ficar mais robusto, também é possível clicar com o rato na etiqueta e o cursor surge no campo de edição.
  • O atributo aria-label deve ser removido, uma vez que a label associada já cumpre essa função para leitores de ecrã, evitando assim anúncios duplicados.
  • O placeholder não deve substituir a label, dado que desaparece durante a introdução de texto e deve antes ser usado para fornecer uma dica sobre o conteúdo esperado.

  Para mais informações, recomendamos consultar a página sobre boas práticas nos formulários da WebAIM.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #9 Não existem campos que exigem preenchimento obrigatório

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

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

  Evidências:

  Atualmente, foram encontrados apenas dois campos de formulário no site: o campo de pesquisa localizado no topo do site, bem como o campo equivalente na página de resultados de pesquisa.

  É não aplicável, porque o campo não é de preenchimento obrigatório.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #61 Imagens decorativas com alt preenchido que causam redundância com leitores de ecrã

  etiqueta: melhoriaetiqueta: R 5.1etiqueta: chk 10 web

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

  Recomendações

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

• evidência: issue #11 As imagens informativas/funcionais não têm um texto alternativo correto

  etiqueta: R 5.1etiqueta: chk 10 webetiqueta: NOK

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

  Evidências:

  As imagens informativas não têm um texto alternativo que sirva de síntese do seu conteúdo e que seja lido pelo leitor de ecrã- Quando o leitor de ecrã percorre a secção "Apoios", ignora as imagens da RTP 2 e da Antena 2 devido ao texto alternativo vazio.

  

  Figura 1 - As imagens dos Apoios têm um texto alternativo vazio (alt="").

  Recomendações:

  Imagens informativas e funcionais, ou seja, aquelas que desempenham uma função essencial, devem incluir um texto alternativo que sintetize claramente o seu conteúdo, permitindo que seja corretamente interpretado por leitores de ecrã.

  • Rever as imagens informativas para que incluam um texto alternativo, através do elemento alt=”exemplo de texto alternativo” que reflita corretamente o que está na imagem. Se o texto alternativo ficar vazio (alt=""), o leitor de ecrã ignora o conteúdo.

  • Garantir que o texto alternativo está na língua do site, em português.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #12 Não existem gráficos no site

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

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

  Evidências:

  O sítio não contém gráficos baseados em dados; este requisito não se aplica.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #13 As imagens-link não têm um equivalente alternativo correto

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.3

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

  Evidências:

  As imagens informativas do menu têm um texto alternativo, mas está em inglês: Toggle Search, Toggle Menu. O mesmo acontece com o botão do fundo da página, que tem o texto alternativo Go to Top.
  ~

  

  Figura 1 - O texto alternativo do botão com a seta é "Go to Top".

  É igualmente necessário considerar imagens que possuem texto alternativo, mas que estão inseridas dentro de um elemento de ligação (<a>) que inclui um atributo aria-label,. Como consequência, os leitores de ecrã anunciam apenas o conteúdo definido no aria-label (por exemplo, aria-label="logo_LRE_preto_positivo"), ignorando o texto alternativo da imagem, porque o aria-label sobrepõe-se ao alt.

  

  Figura 2 - A imagem do Livro de Reclamações está inserida numa ligação que tem o atributo aria-label que se sobrepõe ao alt.

  Recomendações:

  • As imagens-link devem incluir um texto alternativo (alt) que indique claramente qual o destino do link e que seja lido pelo leitor de ecrã.

  • Evitar adicionararia-labelem imagens-link, se as imagens já tiverem um alt atribuído, para que o alt seja lido adequadamente.

  • Garantir que o texto alternativo está na língua do site, em português.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #14 O rácio de contraste entre a cor do texto normal do corpo do documento e o fundo é inferior a 4,5:1

  etiqueta: R 6.1etiqueta: chk 10 webetiqueta: NOK

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

  Evidências:

  No tema escuro do site, na página inicial , o acordeão "Mais informações", tem o texto do corpo do documento ilegível face ao fundo preto.

  

  Figura 1 - Acordeão "Mais Informações" contém texto ilegível, sem contraste

  

  Figura 2 - O contraste entre o texto do acordeão "Mais informações" e o fundo é de 1.09:1.

  Recomendações:

  ara assegurar a legibilidade do texto para as pessoas, é importante garantir um bom contraste visual. Este contraste pode ser alcançado através da seleção adequada de cores (contraste mínimo de 4,5:1 para texto normal).

  Devem garantir que o contraste é suficiente no tema escuro e claro do site.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #16 Não é possível avaliar o módulo dos players que existe porque não estão disponíveis no site

  etiqueta: R 7.1etiqueta: chk 10 webetiqueta: NOK

  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

  Evidências:

  A equipa da TMSR menciona:
  Neste momento não existem vídeos neste site, mas já existe um módulo preparado para essa necessidade. Serão colocados vídeos durante o evento. Todos os vídeos serão colocados através do YouTube. Nenhum vídeo irá iniciar automaticamente.

  Será possível partilharem connosco esse módulo para verificarmos como esses vídeos serão implementados?

  Como neste momento não conseguimos avaliar, colocamos como NOK.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #17 Os vídeos não contêm legendas

  etiqueta: R 7.2etiqueta: chk 10 webetiqueta: NOK

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

  Evidências:

  A equipa da TMSR menciona:

  Os vídeos são de concertos de música clássica, sem necessidade de legendas fechadas sincronizadas ou transcrição textual.

  Será possível verificarmos como esses vídeos vão ser implementados?

  Recomendações

  Mesmo esses vídeos de concerto de música clássica devem ser legendados com a letra da música, como acontece no site do Metropolitan Opera. E por vezes, esses vídeos de concertos contêm fala ou diálogo, que também devem ser legendados.

  Todos os vídeos devem incluir a informação do título da música, compositor, intérpretes e data do concerto.

  De preferência, devem adicionar as legendas através do Player do Youtube. A possibilidade de gerar legendas automaticamente no player do Youtube não é válida para cumprir este requisito.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #21 As imagens das entidades da secção Apoios desaparecem quando se retira o CSS

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.4

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

  Evidências:

  Quando se retira o CSS da página do site, devem manter-se todos os elementos visíveis da página na sua estrutura. Apenas devem ser colocados em CSS elementos decorativos, tais como imagens de fundo ou decorativas.

  As imagens da RTP 2 e Antena 2 da secção Apoios desaparecem, porque são imagens SVG sem dimensões definidas. Quando o CSS é removido, perdem o tamanho e "desaparecem" (ficam com 0×0 píxeis), porque dependem do CSS para ter dimensões.

  

  _Figura 1 - Na secção Apoios, aparece um espaço vazio, e não é possível ver as imagens. _

  Recomendações

  Adicionar width e height diretamente no HTML, no das imagens da RTP2 e Antena 2.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #23 A modal dos cookies está posicionada no fundo da página

  etiqueta: R 9.1etiqueta: chk 10 webetiqueta: NOK

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

  Evidências:

  Colocaram como Não aplicável, mas devem considerar como três modals: a modal de cookies, da pesquisa e do menu de navegação.

  Na modal do menu, o curso move-se para o botão "X" dentro da caixa de diálogo, estando correto.

  

  Figura 1 - Modal do Menu de Navegação.

  Mas o mesmo não acontece com a modal da Pesquisa.

  No caso da modal dos cookies, é possível navegar no resto do site mesmo quando a pop-up dos cookies está aberta, pelo que também deve ser possível navegar da mesma forma com o teclado. No entanto, a modal dos cookies, no código, está posicionada no fundo da página, pelo que os utilizadores apenas chegam à modal após percorrem todo o site.

  

  Figura 2 - Modal dos Cookies

  Recomendações

  Modal da pesquisa
  Deve garantir que o foco vá para o botão de "X" da modal da pesquisa, da mesma forma que acontece na modal do menu de navegação.

  Modal de cookies
  Recomendamos que a modal dos cookies esteja posicionada no topo da página no HTML, para que os utilizadores de leitor de ecrã percebem o destaque a da informação da mesma forma que pessoas com visão percepcionam. Ou seja, ao navegarem com o leitor de ecrã no topo da página, poderão encontrar a modal dos cookies após o link de Skip to Content, por exemplo.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #24 Quando a modal está aberta, a navegação com teclado não fica circunscrita aos elementos que compõem a modal

  etiqueta: R 9.2etiqueta: chk 10 webetiqueta: NOK

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

  Evidências:

  Quando se entram na modal do Menu e e da Pesquisa, a navegação com teclado continua pelos elementos atrás da modal:

  

  Figura 1 - Foco do teclado encontra-se atrás da modal do menu de navegação, no link Coro ECCE.

  

  Figura 2 - Foco do teclado encontra-se atrás da modal do menu de Pesquisa.

  Recomendações:

  Quando uma modal é aberta, o foco do teclado deve ser automaticamente direcionado para dentro dela. Isto garante que os utilizadores que navegam com o teclado, incluindo aqueles que recorrem a tecnologias de apoio, possam interagir facilmente com o conteúdo apresentado e percebam que uma nova interação está disponível.

  • Devem rever as modais para garantir que estão estruturadas com role="dialog" e que possuem o atributo aria-modal="true", de forma a isolar o foco dentro da modal e impedir a interação com o conteúdo subjacente.

  • Devem garantir que .focus() é chamado quando a modal é aberta.

  • O foco deve ir para o primeiro elemento da modal (ex: botão "X" que fecha a modal)

  Para mais informação, podem consultar o exemplo Modal Dialog da WCAG .

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #27 Não é possível extrair todo o conteúdo textual do PDF para formato TXT

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 10.1

  Nos ficheiros PDF é possível, no mínimo, extrair o conteúdo textual para formato TXT.

  – ver requisito 10.1 na lista 10 aspetos

  Evidências

  Foram encontrados ficheiros em formato PDF em que não é possível extrair os conteúdos.

  Por exemplo:

  • Página Coro ECCE, no ficheiro Folha de Sala.
  • Página Ensemble SEO, no ficheiro Folha de Sala.
  • Página Concerto Atlântico, no ficheiro Folha de Sala.
    ... e restantes ficheiros Folha de Sala dos eventos.

  Todos os ficheiros PDF são semelhantes e têm a mesma estrutura e não é possível extrair conteúdo nos mesmos locais: título do concerto, local, data.

  

  Figura 1 - Botão "Folha de Sala" abre um ficheiro PDF

  

  Figura 2 - Conteúdo do PDF da Folha de Sala que não é possível extrair.

  Recomendações

  Devem garantir que os ficheiros PDF são otimizados para que seja possível extrair a informação para um processador de texto. Desta forma, garante-se que o texto pode ser lido por leitores de ecrã na ordem correta. No caso de documentos que são fotocópias, contendo apenas imagens, é possível converter os documentos para texto através do Reconhecimento Óptico de Caracteres (OCR) da Adobe.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #28 Existe uma descrição do propósito do site, mas não está imediatamente visível quando se entra na página inicial

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

  Verificou-se que existe uma descrição do propósito do site, mas não está imediatamente visível quando se entra na página inicial, sendo necessário fazer scroll down. A informação "37ª Temporada" não é suficiente para descrever o propósito do site.

  

  Figura 1 - Descrição do site explica o que é a Temporada Música em São Roque, mas só é visível após scroll down.

  Recomendações:

  Na Homepage deve existir uma breve descrição do propósito do website que demonstre que tarefas é possível realizar no mesmo. Esse propósito deve ser imediatamente visível na página, sem ser necessário fazer scroll, avançar no carrossel, entre outros, como se verifica no exemplo do site acessibilidade.gov.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #29 Não foram encontrados termos complexos

  etiqueta: N/Aetiqueta: chk conteúdoetiqueta: R 1.2

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

  Evidências:

  Não foram encontrados termos complexos no site.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #30 Os blocos de conteúdo não contém data de atualização

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

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

  Evidências:

  As páginas da Política de Cookies da TMSR e restantes páginas de Eventos, como Coro ECCE, Arte Minima, não apresentam a data de atualização.

  

  Figura - Página do evento Coro ECCE não contém data de atualização.

  Recomendações:

  Para assegurar que o utilizador esteja devidamente informado sobre a atualidade dos conteúdos, devem ser incluídas datas de atualização nas diversas páginas e blocos de conteúdo identificados. Esta prática deve abranger também as publicações dos eventos, que já dispõem de data de publicação.

  Podem também consultar a Política de Cookies e a Declaração de Acessibilidade da ESSALCOITÃO que contém a indicação "Atualizado em: [data]" no fundo da página.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #32 O tamanho da letra do corpo do documento é inferior a 12 pontos

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

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

  Evidências:

  Na página inicial, verificou-se que o tamanho de letra do corpo do documento é de 14px.

  

  Figura 1 - Texto da descrição da TMSR é de 14px.

  

  Figura 2 - Texto da descrição de Bilhetes é de 14px.

  Recomendações:

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #33 O tamanho da letra da informação secundária é inferior a 10pt

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

  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

  Evidências:

  A informação secundária tem um tamanho de letra inferior a 10pt.

  

  Figura 1 - INCORRETO - Texto com tamanho 12px.

  Recomendações:

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

  

  Figura 2 - CORRETO - Texto com tamanho 13 px.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #39 Os documentos longos têm um índice no topo com hiperligações internas para o mesmo.

  etiqueta: N/Aetiqueta: R 4.1etiqueta: chk conteúdo

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

  Evidências:

  Como referido na checklist pela entidade:

  O site é one page e o menu cobre essa necessidade.

  Além disso, não existem documentos longos, pelo que consideramos Não Aplicável.

etiqueta: NOK

Lista de evidências recolhidas:

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

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

  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

  Evidências:

  Os elementos interativos devem ter uma altura e largura igual ou superior a 44px de área clicável, mesmo que o ícone/imagem tenha um tamanho inferior.

  Existem botões que têm largura superior a 44px, mas a altura é inferior a 44px.

  

  Figura 1 - INCORRRETO: Botão da "Pesquisa tem dimensão 50x18px

  

  Figura 2 - INCORRETO: Botão do Menu tem dimensão 62x27.6

  Recomendações

  Devem garantir que as dimensões vertical e horizontal dos botões são 44 x 44 px.

  

  Figura 3 - CORRETO: Botão do "Tema" tem dimensão 51 x 46px.

  

  Figura 4 - CORRETO. Acordeões têm dimensão 1050 x 58.2

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #45 Não é possível focar no botão "X" e resultados do campo da pesquisa

  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

  Evidências:

  Na checklist de Transação, a equipa da TMSR menciona que o site não tem formulários.

  

  Figura 1 - Evidência da checklist de Transação da TMSR, requisito 1.1.

  No entanto, existe um campo de pesquisa no topo do site que é considerado um campo de formulário.

  

  Figura 2 - Campo de pesquisa do topo da página com input escrito, botão "X" e opções de resultados

  Ao navegar utilizando a tecla TAB, não é possível focar no botão “X” para limpar o conteúdo do campo, nem selecionar as opções de resultado apresentadas. O foco é deslocado diretamente do campo de pesquisa para o conteúdo subjacente à modal, ignorando os elementos interativos da própria pesquisa.

  Recomendações:

  • Na evidência da checklist, alterar a frase que diz "O site não tem formulários" para o contexto correto mencionado neste issue.
  • Restringir o foco à modal, para que ao navegar com a tecla TAB e leitor de ecrã, apenas seja possível sair da modal ao pressionar o botão "X" ao lado do botão do Menu. Para mais informações, consultar a construção Modal Dialog Example da WCAG.
  • Atribuir um aria-label ao botão "X" de sair da pesquisa diferente doaria-labeldo botão "X" para apagar o conteúdo do campo. Por exemplo, aria-label="Sair da pesquisa" e aria-label="Limpar campo".

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #46 Os formulários com mais de 2 ecrãs de altura devem ser distribuídos por várias páginas

  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

  Evidências:

  Não existem formulários com mais de 2 ecrãs de altura.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #47 Os formulários com mais de uma página têm a sequência de passos ilustrada

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

  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

  Evidências:

  Não existem formulários com mais de uma página.

etiqueta: N/A

Lista de evidências recolhidas:

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

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

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

  Evidências:

  Embora exista um campo de pesquisa, não existem campos com tamanho previsível de dados.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #49 É usada revelação progressiva em vez de campos inativos

  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

  Evidências:

  Não existem formulários que necessitem de revelação progressiva.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #51 Campos obrigatórios devem ser claramente indicados como tal

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

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

  Evidências:

  Embora exista o campo de pesquisa, não existem campos de preenchimento obrigatório.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #52 O sistema indica o que está a acontecer através do loader, mas não é lido pelo leitor de ecrã

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

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

  Evidências:

  O sistema deve indicar o que está a acontecer quando determinadas ações são desencadeadas, principalmente quando o resultado não é imediato ou demora mais tempo do que é suposto.

  Na pesquisa, é possível observar que a ação de loading demora mais tempo do que é suposto a ser concluída e não existe indicação do que está a acontecer para o leitor de ecrã.

  

  Figura 1 - Loader não é lido pelo leitor de ecrã

  Recomendações:

  Devem garantir que esse loader tem:

  • um role="status"
  • aria-live="polite" que anuncia a mensagem assim que o utilizador terminar o que está a fazer.
  • aria-label ou texto interno que fornece a mensagem que será lida. (ex: aria-label="Aguarde...").

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #55 As ações destrutivas nunca devem ser permanentes, deve ser sempre possível desfazer a operação

  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

  Evidências:

  O site não tem formulários com ações destrutivas, apenas o campo de pesquisa.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #62 Melhoria - O link "Saltar para o conteúdo principal está em inglês

  etiqueta: outras violaçõesetiqueta: NOK

  Uma recomendação importante é traduzir o link “Skip to main content” para português, por exemplo “Saltar para o conteúdo principal”, garantindo consistência com o idioma do restante site.

  Este tipo de link é essencial para a acessibilidade, pois permite que utilizadores de leitores de ecrã ou navegação por teclado acedam rapidamente ao conteúdo principal.

  Manter o idioma correto melhora a compreensão, cumpre boas práticas de acessibilidade (como as orientações da WCAG 3.1.1 Language of Page) e proporciona uma experiência mais inclusiva e coerente para todos os utilizadores.

  

  Figura 1 - Link "Skip to content" em inglês