Relatório Avaliação da Candidatura da Cinema São Jorge

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #36 Não é possível identificar quando uma opção contém subopções

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.2

  Quando se navega com o leitor de ecrã no menu não é possível identificar quais opções contém subopções de forma apropriada nem se a opção foi aberta ou não. Por exemplo, ao selecionar a opção "O cinema" o leitor de ecrã informa que é um pop up de menu, essa informação está sendo transmitida pelo atributo aria-haspopup que está sendo utilizado de forma inapropriada. O atributo aria-haspopup é utilizado em conjunto com o atributo role="menuitem" na construção de menus de aplicação. O menu principal do website não é um menu de aplicação mas sim, um menu de navegação que não devem utilizar esse atributo:

  Quando se navega com o com leitor de ecrã no menu principal, não é possível identificar de forma adequada quais as opções que possuem subopções, nem perceber se uma determinada opção se encontra expandida ou recolhida.

  Por exemplo, ao selecionar a opção "O cinema", o leitor de ecrã anuncia a existência de um "pop-up de menu". Esta informação está a ser transmitida através do atributo aria-haspopup, que, neste contexto, está a ser utilizado de forma inadequada.

  O atributo aria-haspopup deve ser utilizado em conjunto com role="menuitem" na construção de menus do tipo aplicação. No entanto, o menu principal do website corresponde a um menu de navegação e não a um menu de aplicação, pelo que não deve recorrer a este atributo:

  

  Leitor de ecrã não informa que a opção está fechada

  

  Leitor de ecrã não informa que a opção está aberta

  URL a verificar

  • https://cinemasaojorge.pt/ - menu principal

  Sugestão de correção

  • Remover o atributo aria-haspopup do menu. A identificação de itens com submenus e o seu estado (expandido/recolhido), deve ser feita pelo uso apropriado do aria-expanded em conjunto com o Javascript.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #41 Incorreta marcação hierarquizada de títulos e subtítulos

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 2.2

  Os artigos na secção "PROGRAMAÇÃO" têm uma incorreta hierarquização de títulos e subtítulos.

  Evidencias:

  

  Figura 1 - Título "La vita da grandi" está corretamente marcado como h1, mas "Sessões" está marcado como h3, sem a existência de um h2.

  

  Figura 2 - Document outline da extensão Web developer demonstra a falta de h2.

  

  Figura 3 - Os sub-títulos nos artigos estão marcados com a tag p.

  

  Figura 4 - Modal sem cabeçalho

  URLs a verificar:

  https://cinemasaojorge.pt/evento/european-outdoor-film-tour-25/
  https://cinemasaojorge.pt/evento/international-ocean-film-tour-volume-12/
  https://cinemasaojorge.pt/programacao/ - Todas as páginas dos eventos que estão dentro de "Programação"
  https://cinemasaojorge.pt/project/afim-de-filmes-projeto-educativo/ - Todos os projetos que são apresentados nessa página

  Recomendações:

  • Nos artigos de programação, corrigir a estrutura dos títulos, trocando os h3 para h2. Trocar também os sub-títulos para uma header tag (h2).
  • Inserir um cabeçalho h2 na modal para indicar que se trata de uma modal de pesquisa. Recomendamos reverem também a issue #71 para garantir que o nome da modal também seja informado.

etiqueta: N/A

Lista de evidências recolhidas:

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

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

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

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

etiqueta: N/A

Lista de evidências recolhidas:

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

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

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

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

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

Lista de evidências recolhidas:

• evidência: issue #47 Indicação visual em falta para campo obrigatório

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

  No formulário para subscrever a newsletter, no rodapé do site, o campo para inserir o email é de preenchimento obrigatório. Apesar de esta informação estar a ser passada para os leitores de ecrã, visualmente este campo não aparece marcado como obrigatório.

  Recomendamos que seja adicionada uma indicação visual de obrigatoriedade, como “(Campo obrigatório)”, “(Obrigatório)” ou um asterisco * junto ao rótulo do campo. Neste último caso, deve também ser incluída no início do formulário, uma legenda que explique claramente o significado do símbolo * utilizado.

  

  Figura - Análise do campo para inserção do email, no formulário para subscrição de newletter no rodapé do site, através do Google Inspector.

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

Lista de evidências recolhidas:

• evidência: issue #44 Existem formulários sem mensagens de erro junto de cada campo

  etiqueta: melhoriaetiqueta: chk 10 webetiqueta: 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 contactos não apresenta mensagens de erro junto de cada campo.

  

  Como observado na figura, as mensagens de erro são transmitidas pelo browser, e apenas uma de cada vez.
  Se num formulário pequeno como o referido tal situação tem um impacto muito reduzido, o mesmo não se pode dizer no caso de formulários com muitos campos, em que o utilizador não pretenderá submeter o formulário após cada correção. Para identificar os demais erros ainda existentes após cada submissão.
  Para além disso, note-se que os utilizadores de leitores de ecrã só têm acesso às mensagens de erro quando as mesmas são anunciadas, tendo de proceder a nova submissão para lhes serem anunciadas novamente. Isto deve-se ao facto de estas mensagens não se encontrarem no DOM, e de não existir uma forma fácil de lhes aceder via navegação por elementos dos leitores de ecrã.
  O ponto positivo que atenua este problema é que o foco é direcionado para o campo onde ocorre o erro, e cada mensagem é sempre anunciada. No entanto, os utilizadores de leitores de ecrã podem querer rever essa mensagem, e isso não é possível.
  O mesmo problema ocorre no formulário de subscrição de newsletters, presente em todas as páginas do site.

  

  Recomendamos a inserção de mensagens de erro na vizinhança de cada campo de todos os formulários, de forma a que as mensagens sejam apresentadas todas de uma só vez e possam ser acedidas pelos leitores de ecrã quantas vezes for necessário.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #35 Imagens não decorativas sem texto alternativo

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 5.1

  As imagens apresentadas representam salas disponíveis para locação, contendo informação relevante para o utilizador. No entanto, não possuem descrição no atributo alt, o que impede a sua interpretação por tecnologias de apoio.

  

  Fifura 1 - Imagem não decorativa sem texto alternativo

  URL a verificar

  https://cinemasaojorge.pt/cedencia-de-espacos/
  https://cinemasaojorge.pt/noticias/leffest/

  Sugestão de correção

  • Recomenda-se a inclusão da descrição no atributo <alt> que identifique claramente cada espaço, indicando o tipo de sala. Por exemplo: alt="Sala de espetáculos com capacidade para 800 pessoas, vista da plateia"

• evidência: issue #29 (Melhoria) Imagem decorativa com texto alternativo

  etiqueta: melhoriaetiqueta: chk 10 webetiqueta: R 5.1

  Verificado que as imagens decorativas possuem texto alternativo no atributo <alt>:

  

  Figura 1 - Imagem decorativa com texto alternativo

  Validado que existem imagens decorativas que não possuem o atributo alt no código, este deve ser inserido mesmo que seja nulo. Por exemplo: alt=""

  

  Figura 2 - Imagem decorativa sem atributo alt

  

  Figura 3 - Imagem decorativa sem atributo alt

  Imagens de sucesso e erro na pesquisa também não possuem atributo alt.

  

  Figura 4 - Imagem pesquisa sem atributo alt

  URL a verificar

  https://cinemasaojorge.pt/
  https://cinemasaojorge.pt/noticias/
  https://cinemasaojorge.pt/project/afim-de-filmes-projeto-educativo/
  https://cinemasaojorge.pt/noticias/sangue-ai-e-censura-vem-ai-o-motelx/
  https://cinemasaojorge.pt/project/afim-de-filmes-projeto-educativo/
  https://cinemasaojorge.pt/historia/
  https://cinemasaojorge.pt/politica-privacidade/

  Sugestão de correção

  Embora o uso do atributo <aria-hidden> esteja correto, recomenda-se aplicar <alt=""> para imagens decorativas.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #38 R 5.2 - 10 Aspetos- Imagem/gráfico não é acompanhado de uma descrição longa

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 5.2

  Foi identificado que a imagem complexa presente na página não é acompanhado por uma descrição longa que transmita a informação apresentada visualmente. O texto apresentado não descreve as informações presentes na imagem, o que impede utilizadores de tecnologias de apoio de acederem a informação.

  

  Figura 1 - Imagem com descrição insuficiente

  URL a verificar

  https://cinemasaojorge.pt/festival/bobines-ao-alto-vem-ai-a-rentree/

  Sugestão de correção

  • Ao utilizar o atributo <aria-describedby> para fornecer uma descrição complementar de uma imagem em texto, o atributo <alt> não pode ser nulo. A imagem deve sempre possuir um alt com uma descrição concisa do seu conteúdo. Por exemplo alt="Bobines ao alto: vem aí a rentrée"

  • O <aria-describedby> deve ser utilizado como complemento, referenciando o texto com um id que contenha uma descrição mais detalhada, e deve sempre estar acessível às tecnologias de apoio (podendo ou não estar visível visualmente).

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #40 Imagens-link apresentam um equivalente alternativo em texto incorreto

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 5.3

  O link associado à imagem do mapa apresenta um nome acessível genérico (“Ver no mapa”), não identificando a localização específica representada. A descrição deve transmitir claramente o destino ou finalidade do link.

  

  Figura 1 - nome acessível do link é genérico e não identifica a localização apresentada no mapa

  URL a verificar

  https://cinemasaojorge.pt/contactos/

  Sugestão de correção

  • A descrição deve transmitir claramente o destino ou finalidade do link. Por exemplo: aria-label= "Ver localização do Cinema São Jorge no Google maps (abre uma nova página)"

etiqueta: NOK

Lista de evidências recolhidas:

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

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

  Verifica-se que após fazer o efeito hover no header, o texto "pesquisa" não tem o contraste mínimo de 4,5:1.

  

  URL a verificar:

  https://cinemasaojorge.pt/

  Recomendação:

  Escurecer a cor do texto com o efeito hover, para que respeite o contraste mínimo de 4,5:1.

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

Lista de evidências recolhidas:

• evidência: issue #56 Foi possivel ativar os botões de controlo do leitor quer com o rato quer com o teclado

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

  Verifica-se que não é possível interagir de forma adequada com os controlos do vídeo. Por exemplo, ao iniciar a reprodução, os controlos ficam ocultos e, para os tornar novamente visíveis, é necessário ativar uma opção localizada no canto do vídeo. A identificação dessa opção só é possível com o indicador de foco do navegador. Com o teclado, não é apresentada qualquer informação visível que permita compreender a sua função. Esta situação não é recomendada, uma vez que o utilizador pode não perceber que se trata de um elemento que permite aceder aos controlos do vídeo.

  Evidências:

  

  URL a verificar:

  https://cinemasaojorge.pt/evento/mock-fest-festival-internacional-de-comedia/

  Sugestão de correção

  É necessário garantir que os controles do vídeo apresentem um ícone ou texto visível da sua função, além do indicador de foco visível, assegurando que o utilizador consegue identificar claramente a ação disponível.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #57 As legendas do player não são audiodescritivas

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 7.2

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

  As legendas utilizadas no player são as automáticas do youtube, sendo que grande parte do video é musical e as legendas não descrevem o que se está a passar no vídeo.

  Evidências:

  

  Figura 1 - Legendas automáticas do youtube.

  

  Figura 2 - As legendas deveriam dizer "Worten Mock Fest, e não "Ven Mfest".

  URLs a verificar:

  https://cinemasaojorge.pt/evento/mock-fest-festival-internacional-de-comedia/

  Recomendações:

  Substituir as legendas automáticas do youtube com legendas audiodescritivas.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #55 Conteúdo duplicado e mensagens ocultas são anunciadas incorretamente

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.2

  O leitor de ecrã está a anunciar mensagens de estado (ex.: confirmação de envio “A sua mensagem foi enviada com sucesso”) sem que estas estejam visivelmente apresentadas ao utilizador ou sem que tenha sido realizada a ação correspondente (submissão do formulário).

  

  Figura 1 - Leitor de ecrã navega por mensagens que não estão sendo apresentadas visualmente

  Conteúdo repetido lido duas vezes pelo leitor

  O campo apresenta duplicação no nome acessível, originando leitura redundante por leitores de ecrã.

  

  Figura 2 - Descrição de campos lida duas vezes pelo leitor de ecrã

  URL a verificar

  (validar no site todo)

  https://cinemasaojorge.pt/contactos/
  https://cinemasaojorge.pt/noticias/
  https://cinemasaojorge.pt/project/afim-de-filmes-projeto-educativo/

  Sugestão de correção

  • A informação não deve aparecer duplicada na leitura por ferramentas de apoio, garantindo que é apresentada apenas uma vez de forma clara e consistente.
  • Garantir que o conteúdo da mensagem não está disponível de forma ativa antes da ação (ex.: ocultar com hidden, ou aria-hidden="true");

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #71 Existem modais que não estão sendo anunciadas apropriadamente

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.3

  A modal apresentada na submissão da newsletter encontra-se implementada de forma apropriada. No entanto verifica-se que elas não possuem uma identificação/nomeação apropriada, o que impede os leitores de ecrã de anunciar a sua descrição:

  

  Leitor de ecrã não anuncia a descrição da modal

  URLs a verificar

  • https://cinemasaojorge.pt/contactos/
  • https://cinemasaojorge.pt/ - newsletter e pesquisa

  Sugestão de correção

  • As modais podem ser nomeadas com o atributo aria-labelledby.

• evidência: issue #65 Existem conteúdos que não estão estruturados como lista

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.3

  O conteúdo que apresenta a listagem de eventos (datas e respetivos festivais) está estruturado como texto simples (parágrafos). Esta abordagem não reflete a relação semântica entre os elementos, dificultando a interpretação correta por tecnologias de apoio, que não conseguem identificar o conjunto como uma lista de itens relacionados.

  

  Figura 1 - Listagem de eventos não esta estruturada como lista

  

  Figura 2 - Listagem de eventos encontra-se estruturada com elementos genéricos (div)

  

  Figura 3 - Grupo de botões não está estruturado como lista

  URL a verificar

  https://cinemasaojorge.pt/programacao/
  https://cinemasaojorge.pt/news/noticias-sobre-a-rentree/
  https://cinemasaojorge.pt/noticias/

  Sugestão de correção

  • Deve ser verificado em todo o website.
  • Conteúdo que representa uma lista seja marcado semanticamente como lista. ( ul li)
  • Substituir o role="group" pela semântica de lista ul li. Para mais informações partilhamos o seuguinte link: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/group_role

• evidência: issue #62 Carrossel construído de forma inapropriada

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.3

  Nos carrosséis apresentados na página inicial, é possível identificar os seguintes problemas:

  1. Visualmente é possível perceber o número de opções de cada carrossel, no entanto essa informação não está sendo transmitida para os leitores de ecrã:

  

  Carrossel contém 10 opções e não indica qual a posição atual do slide que está sendo apresentado

  2. O leitor de ecrã identifica as opções que ainda não estão sendo apresentadas no ecrã:

  

  URL a verificar

  https://cinemasaojorge.pt/

  Sugestão de correção

  • Recomenda-se que a posição do utilizador entre as opções do carrossel seja devidamente comunicada, assim como o número total de opções disponíveis.
  • As opções visíveis aos leitores de ecrã devem corresponder aos elementos visíveis no ecrã. As restantes opções deverão ser ocultadas. Para isso, podem utilizar a propriedade display: none ou do atributo hidden do HTML.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #69 Scroll da página fica inativo após fechar a modal

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 9.3

  Utilizando o navegador chrome, verifica-se que ao fechar a modal (subscrever a newsletter) utilizando a tecla ESC, o scroll da página permanece bloqueado, impedindo a navegação normal com o rato. Esta situação compromete a interação e a continuidade da navegação pelo utilizador.

  

  Figura 1 - Scroll ativo antes de subscrever a newsletter

  

  Figura 2 - Scroll inativo após sair da modal de sucesso

  URL a verificar

  https://cinemasaojorge.pt/

  Sugestão de correção

  • Deve ser garantido que, ao fechar a modal (incluindo através da tecla ESC), o estado da página é corretamente restaurado, nomeadamente reativando o scroll.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #70 Quando fecha a modal o foco (cursor do Browser) não volta ao elemento interativo que o invocou

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 9.4

  Utilizando o navegador chrome, verifica-se que ao fechar a modal (subscrever a newsletter) o foco não é devolvido ao elemento que a acionou (botão Subscrever). Ao avançar com a navegação o foco é direcionado para o inicio da página.

  

  Figura 1 - Foco não retorna para o elemento que acionou a modal

  

  URL a verificar

  https://cinemasaojorge.pt/

  Sugestão de correção

  • Recomenda-se que, ao fechar a modal, o foco seja devolvido ao elemento que a acionou.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #60 Não foi possível extrair o texto do documento PDF

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

  Não foi possível extrair o texto dos documentos PDF para que se possa passar o respetivo conteúdo para um processador de texto sem perda de informação. No caso de documentos digitalizados, ou que contém apenas imagens, é possível converter os documentos para texto através do Reconhecimento Óptico de Caracteres (OCR) da Adobe.

  Evidências:

  

  URLs a verificar:

  https://cinemasaojorge.pt/wp-content/uploads/2025/05/Rider-Tecnico-2025.pdf
  https://cinemasaojorge.pt/wp-content/uploads/2025/05/Medidas-materiais-divulgacao-2025.pdf

  Recomendação:

  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 #2 Falta de um resumo na página principal

  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:

  Na página inicial do Cinema de São Jorge, https://cinemasaojorge.pt/, não aparece presente um resumo breve do próposito do site.

  

  Ecrã da página inicial sem dar scroll não inclui resumo a explicar o próposito do site

  Recomendações:

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

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

  

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #3 Ausência de glossário para termos complexos

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

  Durante a navegação no website, foram identificados diversos termos técnicos e complexos que podem dificultar a compreensão por parte de utilizadores menos familiarizados com a área. No entanto, não é disponibilizado qualquer glossário, definição contextual ou mecanismo de apoio que facilite a interpretação desses termos.

  Como exemplo nas imagens abaixo foi descoberto estes termos complexos nos seguintes URL's:

  • https://cinemasaojorge.pt/ : Na secção de Projeto Educativo.

  • https://cinemasaojorge.pt/historia/ : Na secção do ano 1946 e do ano 1949.

  

  Imagens de 3 exemplos onde existe o uso de termos complexos pelo website.

  Outras Evidências (NOK):

  • AI e MOTELX, não é descrito o significado das siglas: https://cinemasaojorge.pt/noticias/sangue-ai-e-censura-vem-ai-o-motelx/

  • "Sessões Marsupiais", termo complexo sem explicação: https://cinemasaojorge.pt/project/sessoes-marsupiais/

  • LEFFEST, é apenas mencionado uma vez a descrição da sigla, porém é mencionado múltiplas vezes em parágrafos diferentes: https://cinemasaojorge.pt/noticias/leffest/

  Recomendações:

  Recomenda-se a inclusão de um glossário, tooltips explicativos ou ligações para definições, de forma a garantir que o conteúdo seja mais claro, acessível e compreensível para todos os utilizadores, em conformidade com as diretrizes de acessibilidade.

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #8 Informações primárias não possuem tamanho mínimo recomendado

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

  • De forma a assegurar a boa legibilidade do texto para todos os utilizadores, o tamanho de letra do texto que compõe o corpo do documento deverá ser, no mínimo, de 12 pontos(equivale a 16px), assegurando sempre que os mesmos são escaláveis para tamanhos superiores, sempre que o utilizador considere necessário.

  O website possui informações primárias com tamanho inferior a 12pontos(16px). Como na página Notícias o menu, os textos das opções de primeiro e segundo nível são considerados informações primárias e possuem tamanho inferior ao recomendado (Figura 1)



  

  Figura 1 - Demonstração da fonte do menu principal com tamanho inferior ao recomendado

  Ainda na página "Notícias" observamos que os botões “Ler notícia”, “Ver mais notícias” assim como os filtros apresentam textos com 14px uma dimensão inferior ao mínimo recomendado para garantir a legibilidade. Esta redução compromete a acessibilidade, sobretudo para pessoas com baixa visão ou dificuldades de leitura. (Figura 2) 


  

  Figura 2- Botões e tags dos filtros considerados informações primárias possuem valor inferior ao recomendado

  Na página HIstória, o corpo de texto apresenta dimensão de 14px. (Figura 3)


  

  


  Figura 3- Verificação do tamanho do texto, com valor inferior ao recomendado

  O mesmo acontece em outras páginas:

  • https://cinemasaojorge.pt/historia/#anos-1970-1979
  • https://cinemasaojorge.pt/historia/#anos-1980-1989
  • https://cinemasaojorge.pt/historia/#anos-1990-1999
  • https://cinemasaojorge.pt/historia/#anos-2000-2009
  • https://cinemasaojorge.pt/historia/#anos-2010-2019
  • https://cinemasaojorge.pt/historia/#anos-2020-hoje
  • https://cinemasaojorge.pt/project/luzes-telefone-acao-oficina-de-cinema/
  • https://cinemasaojorge.pt/project/afim-de-filmes-projeto-educativo/
  • https://cinemasaojorge.pt/evento/la-vita-da-grandi/

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #9 As informações secundárias têm um tamanho de letra inferior ao recomendado

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 2.2

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

  Notas Gerais

  A informação secundária, como os autores de textos ou de imagens, as datas de publicação ou outros tipos de meta-informação, podem usar tamanhos de letra mais pequenos, mas, no mínimo, com 10 pontos, assegurando sempre que os mesmos são escaláveis para tamanhos superiores, sempre que o utilizador considere necessário.

  Durante a análise foram identificadas informações secundárias apresentadas com um tamanho de letra inferior ao mínimo recomendado.

  Os textos com as datas de atualização e publicação das páginas com valor 12px não cumpre o presente critério. Por exemplo, na página Contactos, esta dimensão reduzida compromete a legibilidade e cria barreiras para utilizadores com baixa visão ou que necessitem de ampliar o conteúdo. (Figura 1)

  

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

  Outras páginas que precisam de correção:

  • https://cinemasaojorge.pt/acessibilidade-do-cinema/
  • https://cinemasaojorge.pt/project/afim-de-filmes-projeto-educativo/
  • https://cinemasaojorge.pt/project/luzes-telefone-acao-oficina-de-cinema/

  



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

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 2.3

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

  Notas Gerais

  • Para assegurar uma boa leitura, as linhas de texto devem ter até 80 caracteres (incluindo espaços). No limite, podem ir até aos 100 caracteres (incluindo espaços).

  Identificamos blocos de texto no website que possuem largura superior ao recomendado. Por exemplo, na página Afim de Filmes Projeto Educativo há 102 caracteres por linha. (Figura 1)

  

  Figura 1 - Análise de bloco de texto com ferramenta WordCounter

  Exemplos de outras páginas com a mesma problemática:

  • https://cinemasaojorge.pt/project/luzes-telefone-acao-oficina-de-cinema/
  • https://cinemasaojorge.pt/project/sessoes-marsupiais/
  • https://cinemasaojorge.pt/project/6116/
  • https://cinemasaojorge.pt/project/cinema-na-palma-da-mao/

  Recomendação
  Revisar blocos de textos para garantir que não é ultrapassado o número máximo de caracteres por linha. Rcomendamos que seja definida uma largura máxima para as caixas de texto (max-width, em CSS), com unidades relativas ao tamanho de fonte (unidades em ou rem).

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #19 Não é percetível qual a posição atual do utilizador através do menu

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 3.2

  A navegação principal está sempre visível e sempre no mesmo local.
  – ver requisito 3.2 na lista Conteúdo

  Notas Gerais

  A opção do menu selecionada deve ser visualmente diferente das restantes opções para evidenciar a página onde o utilizador se encontra na arquitetura de informação. Em alternativa, a posição do utilizador pode ser transmitida através das breadcrumbs, desde que estas transmitam claramente o percurso feito até à página atual.

  Problema específico
  Enquanto o utilizador navega dentro de um submenu, todas as opções desse submenu são anunciadas pelo leitor de ecrã como sendo o link atual. Por exemplo, se o utilizador estiver na página “História”, dentro do menu “Cinema”, todas as subopções de “Cinema” são identificadas como link atual pelo leitor de ecrã, devido ao atributo aria-current estar definido como true em todos os itens.

  

  Nesta imagem percebe-se que todas as opções se encontram como true em link atual.

  

  Imagem que demonstra a visualização do leitor do ecrã quando passa pelas opções de segundo nível do menu todas descritas como "link atual"

  Recomendação
  Para o requisito ser cumprido, devem garantir que a posição atual do utilizador é evidenciada por pelo menos uma destas duas opções: no menu ou breadcrumbs. No menu, é necessário adicionar o atributo aria-current para que seja percetível também pelas tecnologias de apoio.

  Sugere-se a consulta do exemplo de navegação com disclosure da W3C (disponível em: https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/examples/disclosure-navigation/#mythical-page-content
  ) para compreender melhor o problema e identificar uma solução adequada.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #24 Hiperligações não identificáveis como clicáveis no website

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 3.3

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

  Evidências:

  Nos exemplos destacados (contacto telefónico, email, links de rodapé e navegação “Início • Notícias”), os elementos são apresentados como hiperligações, mas:

  • Não são claramente distinguíveis como links (ex.: ausência de sublinhado, cor diferenciada ou outro indicador visual consistente);

  • Parecem texto comum, o que dificulta ao utilizador perceber que são interativos;

  • Não existe indicação adicional de contexto ou ação, especialmente relevante para contactos (ex.: “ligar para”, “enviar email para”);

  • No caso do breadcrumb (“Início • Notícias”), a separação por pontos não é suficientemente clara como estrutura de navegação clicável.

  Na secção de Links úteis do rodapé, as opções devem estar devidamente sublinhadas.

  

  Imagem dos breadcrumbs na página: https://cinemasaojorge.pt/noticias/cinema-sao-jorge-recebeu-162-411-espectadores-em-2024/

  

  Imagem da página de contactos: https://cinemasaojorge.pt/contactos/

  

  Imagem do rodapé

  Recomendações:

  Recomenda-se que todas as hiperligações no website sigam um padrão visual consistente e facilmente reconhecível, de modo a que os utilizadores consigam identificá-las intuitivamente como elementos clicáveis. Esse padrão deve ser claro, uniforme em todas as páginas e não depender exclusivamente da cor, garantindo assim uma melhor compreensão e acessibilidade para todos os utilizadores.

  Como exemplo, o website Acessibilidade.gov.pt mantém um padrão consistente para todas as hiperligações. Embora estas não estejam sublinhadas por defeito, ao passar o cursor (hover) surge o sublinhado, destacando visualmente a existência de uma hiperligação. Esta abordagem garante consistência e reforça a perceção de interatividade, contribuindo para uma melhor experiência de utilização e acessibilidade.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #12 Página longa sem índice no topo

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 4.1

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

  Ponto 01
  Páginas:
  https://cinemasaojorge.pt/programacao/
  https://cinemasaojorge.pt/cedencia-de-espacos/
  https://cinemasaojorge.pt/evento/festa-do-cinema-italiano-4/

  A página é bastante longa (ultrapassa 3 ecrãs de altura) e apresenta uma grande quantidade de conteúdos listados de forma contínua.
  No entanto, não existe um índice no topo com ligações internas que permita navegar diretamente para as diferentes secções.
  Isto obriga o utilizador a percorrer a página manualmente, o que pode dificultar o acesso rápido a conteúdos específicos.

  Recomendação:
  Adicionar um índice no topo da página com ligações internas para as diferentes secções.
  -Reduzir a quantidade de conteúdos apresentados por página;
  -Agrupar os conteúdos por categorias;
  -Substituir o botão “Ver mais eventos” por um sistema de paginação.

  

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #4 Layout não adaptado a dispositivos móveis (conteúdo cortado lateralmente)

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 4.2

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

  Ponto 01:
  Em dispositivos móveis, o layout não se adapta corretamente à largura do ecrã, verificando-se a presença de conteúdo cortado lateralmente. Alguns elementos ultrapassam os limites visíveis, não sendo totalmente apresentados nem existindo uma forma clara e utilizável de navegação horizontal.

  Situação observada através de visualização em ecrã de dimensões reduzidas (mobile), onde parte do conteúdo fica fora da área visível.

  Página: https://cinemasaojorge.pt/

  Recomendação:
  Ajustar o layout para garantir que todos os elementos se adaptam à largura do ecrã, assegurando que o conteúdo é totalmente visível sem necessidade de varrimento horizontal.

  

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #6 Elementos interativos com dimensão inferior ao mínimo recomendado

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: 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ágina: https://cinemasaojorge.pt/

  Foram identificados vários elementos interativos com dimensões inferiores ao mínimo recomendado de 44x44 px, nomeadamente:
  Indicadores do carrossel (aprox. 8x8 px)
  Ícones de redes sociais (aprox. 24x24 px)
  Separadores “Próximos eventos”, “Hoje” e “Amanhã” (aprox. 28px)

  Recomendação:
  Garantir que todos os elementos interativos apresentam uma dimensão mínima de 44x44 px, assegurando facilidade de interação em diferentes dispositivos.

  

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #21 Múltiplos botões sem hierarquia clara de ação principal

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 5.3

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

  Ponto 01
  Página: https://cinemasaojorge.pt/
  Não foi identificado uma ação principal claramente consistente ao longo da página.

  Apesar de existirem botões com algum destaque visual (ex.: “Saber mais” no banner principal), nas restantes secções da página são apresentados múltiplos botões com estilos semelhantes (ex.: “Ver detalhe”, “Saber mais”, “Iniciar visita virtual”), sem uma hierarquia clara entre ação principal e secundárias.

  Recomendação:
  Definir uma ação principal por página e garantir que esta se destaca de forma consistente (ex.: cor, tamanho ou estilo diferenciado), mantendo uma hierarquia visual clara entre ações principais e secundárias.

  

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #7 Elementos interativos não aparentam ser clicáveis ou não funcionam corretamente

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: 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://cinemasaojorge.pt/

  Os indicadores do carrossel (bolinhas) apresentam-se visualmente como elementos interativos, sugerindo que permitem navegação direta entre conteúdos. No entanto, ao serem acionados através de clique, não respondem, ao contrário das setas de navegação que funcionam corretamente.

  Reocmendação:
  Garantir que os indicadores do carrossel são funcionais e permitem navegação direta entre conteúdos, ou, em alternativa, ajustar o seu aspeto visual para que não aparentem ser elementos interativos.

  

  Ponto 02
  Página: https://cinemasaojorge.pt/noticias/
  Foram identificadas etiquetas (ex.: “75 anos”, “cinema são jorge”) que apresentam o mesmo aspeto visual de etiquetas interativas utilizadas noutras páginas (como na programação), mas que não possuem qualquer comportamento ao clique.

  Recomendação:
  Garantir consistência no comportamento e aparência dos elementos:

  • Diferenciar visualmente etiquetas não interativas, ou
  • Tornar todas as etiquetas clicáveis com comportamento consistente.

  

  Ponto 03
  Página: https://cinemasaojorge.pt/

  Página: https://cinemasaojorge.pt/programacao/

  Alguns botões (ex.: “Ver detalhe”, “Saber mais”) apresentam baixo contraste em relação ao fundo, não se destacando de forma clara como elementos interativos.

  Esta situação pode dificultar a sua identificação, sobretudo em contextos de leitura rápida ou para utilizadores com dificuldades visuais.

  Recomendação:
  Reforçar o contraste visual destes botões, garantindo que são facilmente identificáveis como elementos clicáveis.

  

etiqueta: N/A

Lista de evidências recolhidas:

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

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

  Os formulários com mais de 2 ecrãs de altura devem ser distribuídos por várias páginas.
  – ver requisito 1.2 na lista Transação

  Não foram encontrados formulários com mais de 2 ecrãs de altura no site do Cinema São Jorge. Desta forma, este requisito é avaliado como "Não aplicável".

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #17 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 no site do Cinema São Jorge. Assim, este requisito é avaliado como "Não aplicável".

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

Lista de evidências recolhidas:

• evidência: issue #25 Não existem restrições do número de caracteres a inserir nos campos

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

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

  Os campos de formulário, que têm um limite máximo de números (ex: número de telefone, código postal…), devem limitar a quantidade de caracteres a inserir. Desta forma, garantimos que não são inseridos mais caracteres do que o necessário, evitando possíveis erros.

  Nos campos “Nome”, “Email” e “Mensagem” do formulário “Fale connosco” da página Contactos, verificámos que o número de caracteres de input é ilimitado.

  O mesmo acontece no campo “Subscrever Newsletter”, do formulário para subscrição de Newsletter no rodapé do site.
  Recomendamos a revisão dos campos de escrita para limitar o número máximo de caracteres que é possível inserir.

  Para campos muito grandes, como campos de mensagem de escrita livre, pode ainda ser dada a visibilidade do número máximo de caracteres que é possível inserir.

  

  Figura 1 - Análise do campo "Email", no formulário "Fale connosco" da página Contactos, através do Google Inspector.

  

  Figura 2 - Análise do campo "Subscrever Newsletter", no rodapé do site, através do Google Inspector.

• evidência: issue #23 Não existem restrições do tipo de caracteres a inserir nos campos

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

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

  Os campos de formulário que aceitam caracteres específicos, por exemplo, apenas números ou apenas letras, devem impedir a inserção de determinados tipos de caracteres. Desta forma, garantimos que não são inseridos caracteres errados, evitando possíveis erros.

  No campo "Nome" do formulário "Fale Connosco" da página Contactos, verificou-se que é possível inserir números e caracteres especiais, quando o campo deveria apenas aceitar letras.

  Recomendamos que o campo Nome seja ajustado para aceitar apenas letras — incluindo letras acentuadas e o caractere ç — além de espaços, permitindo escrever primeiro e último nome, por exemplo, e evitando a inserção de números ou símbolos especiais.

  

  Figura - Campo "Nome" do formulário "Fale Connosco" da página Contactos está a aceitar números e caracteres especiais.

etiqueta: N/A

Lista de evidências recolhidas:

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

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

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

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #28 Existem campos de 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.

  No formulário de subscrição da newsletter, o campo destinado ao email utiliza o rótulo “Subscrever Newsletter”, o que não é claro quanto à informação que deve ser inserida pelo utilizador.

  A legenda do campo deve ser alterada para deixar mais claro o que deve ser feito. Neste caso, uma solução adequada seria alterar a legenda para “Email”.

  

  Figura - Análise do formulário para subscrever a newsletter, no rodapé do site, através do Google Inspector.

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

Lista de evidências recolhidas:

• evidência: issue #49 Campo de pesquisa marcado incorretamente como 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 o campo de pesquisa geral do site — apresentado numa janela modal após selecionar a opção de 1.º nível “Pesquisa” no menu principal — está definido como um campo de preenchimento obrigatório. Isto ocorre devido à utilização do atributo required no elemento input da pesquisa.

  Recomendamos que este campo não seja marcado como obrigatório, uma vez que a pesquisa é uma funcionalidade opcional. Além disso, marcar um campo de pesquisa como obrigatório pode gerar confusão ou fricção desnecessária especialmente para utilizadores de tecnologias de apoio.

  Posto isto, recomendamos que o campo seja tratado como opcional e que o atributo required seja removido do elemento input.

  

  Figura - Análise do campo de pesquisa geral do site através do Google Inspector. Atributo required está destacado através de um retângulo de borda preta.

• evidência: issue #33 Indicação visual em falta para campo 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

  No formulário para subscrever a newsletter, no rodapé do site, o campo para inserir o email é de preenchimento obrigatório. Apesar de esta informação estar a ser passada para os leitores de ecrã, visualmente este campo não aparece marcado como obrigatório.

  Recomendamos que seja adicionada uma indicação visual de obrigatoriedade, como “(Campo obrigatório)”, “(Obrigatório)” ou um asterisco * junto ao rótulo do campo. Neste último caso, deve também ser incluída no início do formulário, uma legenda que explique claramente o significado do símbolo * utilizado.

  

  Figura - Análise do campo para inserção do email, no formulário para subscrição de newletter no rodapé do site, através do Google Inspector.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #61 Feedback de carregamento pouco claro na página de Programação

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

  Verificou-se que, ao navegar entre as secções da página de Programação, o leitor de ecrã anuncia apenas de forma genérica que algo está a carregar, sem indicar o tipo de conteúdo que está a ser atualizado.

  Na interface gráfica, a mensagem de carregamento também não é clara quanto ao conteúdo que está a ser carregado. Esta situação pode causar confusão para utilizadores de tecnologias de apoio, dificultando a perceção do estado da ação.

  Recomenda-se que a mensagem do leitor de ecrã e a mensagem visual sejam mais específicas, refletindo claramente o tipo de conteúdo que está a carregar, por exemplo “A carregar sessões de Stand-Up Comedy…”.

  URL a verificar:
  https://cinemasaojorge.pt/programacao/

  

  Exemplo de carregamento da secção de Programação sem indicação clara do tipo de conteúdo

• evidência: issue #54 Ausência de indicação de processamento na funcionalidade de pesquisa

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

  Verificou-se que, ao efetuar uma pesquisa no site, o sistema demora alguns segundos a apresentar resultados sem fornecer qualquer indicação de que a ação está em curso.

  Durante este período, não é apresentado qualquer feedback visual ou textual que informe o utilizador de que a pesquisa está a ser processada.

  Esta situação pode gerar incerteza quanto ao estado da ação, podendo levar o utilizador a repetir a interação ou assumir que o sistema não está a responder.

  Posto isto, recomenda-se a apresentação de um indicador de processamento (ex.: mensagem “A pesquisar...”, spinner ou barra de progresso), garantindo também que essa informação é comunicada de forma acessível às tecnologias de apoio.

  

  Execução de pesquisa sem indicação de estado de processamento

• evidência: issue #51 Ausência de indicação clara de processamento na subscrição da newsletter

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

  Verificámos que, ao submeter o formulário de subscrição da newsletter, o sistema demora alguns segundos a processar o pedido sem apresentar uma indicação clara de que a ação está em curso, sendo apenas exibido um ícone de carregamento no botão.

  Esta abordagem pode não ser perceptível para todos os utilizadores, especialmente para pessoas que utilizam tecnologias de apoio, não sendo o estado de processamento comunicado de forma explícita.

  Posto isto, recomendamos que seja fornecido um feedback mais claro e acessível durante o processamento, nomeadamente através de uma mensagem textual.

  

  Figura - Submissão da newsletter sem indicação clara de estado de processamento, sendo apresentado apenas um ícone de carregamento no botão.

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

Lista de evidências recolhidas:

• evidência: issue #74 Mensagem de Sucesso em Inglês

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

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

  Verificámos que, no browser Safari, na versão portuguesa do site, ao submeter o email no formulário de subscrição da Newsletter, a mensagem de confirmação aparece em inglês (“Contact was successfully registered!”). Isto pode gerar confusão, sobretudo para utilizadores que não dominem o inglês.

  Recomendamos que todas as mensagens de confirmação, envio de informação ou erro sejam apresentadas no mesmo idioma do site — neste caso, português.

  

  Figura - No Safari, ao submeter um email no formulário para subscrição da newsletter, a mensagem de sucesso aparece em inglês (“Contact was successfully registered!”).

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #45 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".

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

Lista de evidências recolhidas:

• evidência: issue #43 Existem formulários sem mensagens de erro junto de cada campo

  etiqueta: chk transaçãoetiqueta: melhoriaetiqueta: 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 contactos não apresenta mensagens de erro junto de cada campo.

  

  Como observado na figura, as mensagens de erro são transmitidas pelo browser, e apenas uma de cada vez.
  Se num formulário pequeno como o referido tal situação tem um impacto muito reduzido, o mesmo não se pode dizer no caso de formulários com muitos campos, em que o utilizador não pretenderá submeter o formulário após cada correção. Para identificar os demais erros ainda existentes após cada submissão.
  Para além disso, note-se que os utilizadores de leitores de ecrã só têm acesso às mensagens de erro quando as mesmas são anunciadas, tendo de proceder a nova submissão para lhes serem anunciadas novamente. Isto deve-se ao facto de estas mensagens não se encontrarem no DOM, e de não existir uma forma fácil de lhes aceder via navegação por elementos dos leitores de ecrã.
  O ponto positivo que atenua este problema é que o foco é direcionado para o campo onde ocorre o erro, e cada mensagem é sempre anunciada. No entanto, os utilizadores de leitores de ecrã podem querer rever essa mensagem, e isso não é possível.
  O mesmo problema ocorre no formulário de subscrição de newsletters, presente em todas as páginas do site.

  

  Recomendamos a inserção de mensagens de erro na vizinhança de cada campo de todos os formulários, de forma a que as mensagens sejam apresentadas todas de uma só vez e possam ser acedidas pelos leitores de ecrã quantas vezes for necessário.
  Recomendamos ainda que essas mensagens sejam associadas programaticamente a cada campo, de forma a fornecer uma associação de cada mensagem de erro ao respetivo campo quando se navega com o modo de foco dos leitores de ecrã.
  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">Email não válido</div>
  

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #50 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 “Por favor, preencha este campo” presente no formulário de contactos não ajuda no preenchimento do campo.

  

  Como observado na figura, a mensagem “Por favor, preencha este campo” 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.
  Recomendamos rever todos os formulários do website para garantir que a mensagem de erro apresentada explique para o utilizador como preencher os campos corretamente.

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

Lista de evidências recolhidas:

• evidência: issue #66 Outras violações - Limitação na utilização da ferramenta ANDI

  etiqueta: melhoriaetiqueta: outras violações

  Descrição do problema

  No âmbito da verificação da acessibilidade do site, foi identificado que a ferramenta ANDI não consegue ser utilizada, devido à Content Security Policy (CSP) do site bloquear a execução dos seus scripts.
  Esta restrição impede o uso de uma ferramenta reconhecida de apoio à avaliação de acessibilidade, dificultando a verificação técnica e a identificação de eventuais não conformidades. (Figura 1)

  

  Figura 1 - Demonstração de bloqueio da ferramenta ANDI

  Recomendação de melhoria:
  Recomenda-se a revisão da CSP de acordo com as instruções do ANDI, de forma a permitir os scripts do ANDI através da respetiva lista de permissões.

  A adoção desta medida não compromete a segurança do site e permite que ferramentas reconhecidas de avaliação de acessibilidade sejam utilizadas de forma eficaz, beneficiando tanto os processos internos da entidade gestora do site, como as ações de auditoria e acompanhamento externo.

• evidência: issue #39 Outras Violações - O website apresenta páginas com conteúdos inacessíveis

  etiqueta: melhoriaetiqueta: outras violações

  Descrição do Problema

  Ao aceder à página de Notícias, verifica‑se que os filtros disponíveis “Tudo”, “Filmes”, "Festivais", “Concertos” e “Especial" não estão a funcionar corretamente. Sempre que o utilizador tenta selecionar qualquer um destes filtros, em vez de os conteúdos serem atualizados como seria esperado, é apresentada inicialmente uma mensagem como “Estamos a projetar o filme... Por favor aguarde um momento” ou “A carregar” (quando utilizado o leitor de ecrã NVDA). (Figura 1)

  

  Figura 1 - Página "Notícias" com filtros "A carregar"

  Contudo, o conteúdo não chega a carregar. Em vez disso, é aberta uma janela modal com a mensagem: “Ups... Ocorreu um erro no seu pedido.” (Figura 2)

  

  Figura 2 - Modal de erro com conteúdo inacessível

  Outro exemplo, na página São Jorge 360º com visita virtual indisponível, conteúdo bloqueado e mensagem de erro "Este conteúdo está bloqueado. Contacte o proprietário do site para corrigir o problema" pouco visível. (Figura 3)

  

  Figura 3 - Página apresenta erro em visita virtual indisponível

  Recomendações
  É necessário rever todas as páginas do website para garantir que todos conteúdos são acessíveis. Recomenda‑se rever a interação dos filtros com os conteúdos, garantindo que endpoints, parâmetros e respostas estão corretos para assegurar o acesso à informação por todos os utilizadores. Sugere‑se também ajustar o feedback apresentado, evitando mensagens genéricas em modais fora de contexto e integrando o erro diretamente na área de conteúdo.

• evidência: issue #27 Outras Violações - Links redundantes na página "Programação"

  etiqueta: melhoriaetiqueta: outras violações

  Descrição do Problema

  • Links redundantes prejudicam a acessibilidade porque criam confusão e esforço desnecessário para pessoas que usam leitores de tela ou navegam apenas pelo teclado. Ao percorrer várias vezes ligações que levam ao mesmo destino. Isso aumenta o esforço, causa ruído na navegação e dificulta encontrar a informação relevante.

  Na página de Programação, foram identificados comportamentos redundantes na navegação entre conteúdos. (Figura 1)

  

  Figura 1 - Análise de links redundantes na pagina "Programação"

  Ao utilizar os filtros da secção “Sessão de festival” apresenta igualmente os mesmos títulos, datas e horários já visíveis na listagem principal. (Figura 2)

  

  Figura 2 - Análise de links redundantes com a utilização dos filtros

  Além disso, ao selecionar algum dos filmes ao clicar numa etiqueta (ex.: “Festa do Cinema Italiano”), o utilizador é encaminhado para a página Festa do Cinema Italino com uma listagem que apresenta os mesmos conteúdos já disponíveis na aba “Tudo” (Figura 3)

  

  Figura 3 - Página da categoria "Festa do Cinema Italiano"

  Esta repetição de conteúdos, sem diferenciação clara, pode induzir o utilizador em erro, criando a perceção de que está a aceder a conteúdos distintos quando, na realidade, são os mesmos.

  Recomendação:
  Garantir que os elementos de navegação apresentam conteúdos distintos e coerentes com a ação do utilizador.
  Evitar repetir destinos idênticos sem valor adicional e duplicação de conteúdos. Assegurar que as etiquetas funcionam efetivamente como filtros, apresentando resultados diferenciados ou claramente contextualizados.

• evidência: issue #22 Outras Violações - Botão “Voltar para os filtros” não visível na navegação com rato

  etiqueta: melhoriaetiqueta: outras violações

  Descrição do problema

  Na página História, verificou-se que o botão “Voltar para os filtros” apenas se torna acessível durante a navegação por teclado. Contudo, este elemento não é visível para utilizadores que navegam com o rato. (Figura 1)

  

  Figura 1 - Botão "Voltar para os filtros" ativos apenas com navegação por teclado e Leitor de ecrã NVDA

  Este botão permite regressar aos filtros de anos, que funcionam como um índice de uma página longa, sendo portanto um elemento importante para a orientação e navegação.

  Recomendação de melhoria

  Tornar o botão visível para todos os utilizadores, independentemente do método de navegação. Desta forma, também quem utiliza scroll poderá beneficiar de um acesso mais rápido aos filtros, melhorando a experiência geral.